German BSI withholds Truecrypt security report (opens in new tab)

Can I just point out that this is just one vivid example of why tying setuid permissions to a file is a terrible design to begin with? Permissions should be derived from the execution context at run time. (People might hate me for saying this, but this is one of those design decisions Windows fundamentally gets right.)

This surprised me the most―never thought about this before. Aren't all permission-supporting filesystems vulnerable to this if mounting by a user is permitted? I presume filesystems don't go through the files and downgrade root ownership.

Isn't Veracrypt just a container, like a hard disk? Why should Veracrypt care about what filesystem you store inside of a container, and whatever you do with its permissions?

... if you have sudo.

Ouch.

> since this information would be relevant to the developers and many state entities that use the software and its successor.

The BSI actually did communicate the findings of the report to the TrueCrypt developers in 2010, which the developers ignored:

> The results were communicated to the Truecrypt foundation, however the Truecrypt developers didn't consider them to be relevant. BSI furthermore says that the results were not intended to be published.

(From page 2 of the article)

Open-records requests can be a huge amount of work, even if the records aren't secret - it's common for requesters to have an axe to grind, so you might want to know what that is (and whether you should be honoring the request, and whether that's actually optional, all of which isn't necessarily trivial); and it typically means you need to review all those documents - and understand them. Even if the examination is just cursory, although I have no firsthand experience, I can well imagine that for technical documents that were secret in a secretive organization this is going to be a time consuming process nobody really wants to do. As such, I don't think it's weird or even really all that sad when a request hits some speedbumps. It's kind of inevitable; it's work, it's specialized, it's not all too rewarding for the institution, it's thankless for the specific employee... It's a testament to the solidity of bureaucratic institutions that it gets done at all. Frankly, this all sounds like the process worked about as perfectly as you can expect - they actually got the data, all of it, and they could distribute it literally, too.

It would be nice if it were easier to achieve transparency; but the flipside is that overzealous transparency laws can be abused too; at least here in the Netherlands there have been several cases where... creative... citizens decided to cash in on the fines imposed for non-compliance with such requests by spamming (iirc) municipalities with requests which had been phrased to be hard to deal with quickly, and hundreds of which submitted simultaneously. I believe the law has changed, but even so - requests like this aren't free. Somebody else is paying; and that's fine - but to expect them to furthermore go above and beyond and push for excellent service and quick turnaround is perhaps a little unreasonable.

When the developers of a product pay for a third-party security assessment, the results are usually confidential - after all, who'd pay to have their product publicly badmouthed?

Perhaps BSI was merely attempting to provide such a service for free.

Jail any government worker who hinders an open records request - like Georgia is trying to do today:

https://www.ajc.com/news/local-govt--politics/trial-start-mo...

Truecrypt has been abandoned for ~seven years or so.

You should no longer use TrueCrypt, if you want an alternative I suggest https://www.veracrypt.fr

But did the VeraCrypt developers know about it?

The documents seem to be available here: https://fragdenstaat.de/anfrage/untersuchungen-zum-verschlus...

They all have "geschwärzt" (blackened) in the file name, but it looks like only some author's name (and maybe working group name) have been removed -- I've scrolled through a few of these files, and didn't find anything else that might have been removed.

This AP7 (work package 7) document seemed the most relevant, although most of it reads like generic test results and conceptual stuff. Not sure why they would try to hold that back. A non-malicious view would be that they simply are a part of German bureaucracy and subsequently slow.

Non-Google translation of the summary (AP7, page 70) for those interested:

"5 Summary

This work package first describes the basic building blocks that are utilized to secure the start [boot?] process, as well as ones that might be necessary and helpful to realize hard dism encryption via full-disk-encryption .

Beyond that existing attacks are described and investigated if the solutions presented here mitigate against them or not.

In chapter 4 several possible solutions are presented, both online (meaning with network connectivity) as well as offline.

The most promising solutions use the new Trusted-Computing functionality based on a Trusted Platform Module (TPM) and a Boot of Trust (CRTM/SRTM/DRTM).

The most desirable solutions are the Secure Boot procedure from chapters 4.4 and 4.5. These do however require either the development of new hardware or need to be based on special hardware extensions, e.g. Intel's TXT technology.

A large-scale deployment in an existing, heterogenous area is therefore improbable.

At the moment solutions that combine Trusted Boot with the attestation functionality seem to be the most sensible. This solution can be combined with: - Sealing: Storing a secret on the platform configuration. - NVRAM: Storing a secret in an area of the Trusted Storage, inside the TPM, that is only readable/writable given a valid configuration. - Attestation: Proof of platform integrity towards an external party. As "external parties", multiple counterparts could be realized: - Online, e.g. a central server. - Offline: e.g. a smart card or a smart phone application that takes on the verification for the server. All three variants (sealing, NVRAM, attestation) are reliant on the correctness of the PCRs."

The rest is potential use cases and an impact matrix of the attacks described in the document.

Either they had to do that, or they had to be ready for the barrage of incoming requests for the documents.

Since you're uploading them to the cloud do keep in mind that given 60 years of computer advancement, today's encryption standards will be unlikely to withstand tomorrow's hardware...

Burn everything and flee to the woods. Can't be too careful.

Somehow I didn't notice the article was paginated. Thanks for pointing that out.

As per the guidelines:

> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."

Who cares about the TFA. The comments is the content. Especially here! braces for downvotes

True, but not by outright cracking the encryption.

They will get your password instead, by implanting your keyboard, putting a camera behind you on the wall, or grabbing you just after you've entered your password.

Because there weren't any real zero days in the report in the first place. The article mentions that it's mainly minor things like failing to clear memory, which is only helpful in rare circumstances.

They did not publish publicly but did report their findings to the true crypt foundation so that it could be fixed (but they in return didn't agree that those were flaws worth thinking)

>The casual user stumbling on this article is going to think that TrueCrypt or VeraCrypt has been broken.

And why should the casual user use TrueCrypt/VeraCrypt when Bitlocker/Filevault works out of the box and is built into the operating system? I feel like that most people using veracrypt do so because it's open source, and they're distrustful of the software vendors. For that threat model, you need to have protections against evil maid attacks, which TrueCrypt/VeraCrypt does not have.