Ross Ulbricht just got reamed in federal court because a simple physical arrest compromised virtually every secret he had.
But militating in favor of insecure crypto goes a long way towards hiding that possibility from everyone. The fact that your only options today are and does not mean that there is no option possible.
When pressed, you in effect say "yeah, well, name a tool that does that". You've been almost completely unable to explain in technical terms what "UX" you want from sector-level crypto that you couldn't get from filesystem crypto. They've thought about Truecrypt far more rigorously than you have, and for far, far longer. They did not "only get their act together today". And Matthew Green, who coordinates the whole audit project, just wrote that he and his students have been reviewing Truecrypt's crypto for months. The guy leading the actual crypto review work has been looking at Truecrypt for more than a year. Round 1 and Round 2 of the audit share technical members. You're right, security is all that matters here, and folks aren't going to be secure if it remains impossibly difficult to be secure. It's not more secure than anything else, but it presents a workflow that might actually be more secure, due simply to it's ease of implementation. The fact is, people want to move encrypted volumes across platforms. What you wrote seems to intimate there's no actual need or value in moving encrypted volumes across platforms, and that if folks actually want to do that they should just encrypt individually and at a FS level and do so using PGP, which has existed for years, and whose adoption rate and ease-of-use are both, compared to TrueCrypt, through the floor. What matters here is the security, and the adoption rate of TrueCrypt is/was through the roof, because of how it allowed folks to move encrypted volumes across various platforms without much hassle. "The term "full-disk/on-disk encryption" is often used to signify that everything on a disk is encrypted, including the programs that can encrypt bootable operating system partitions."Īre you going to tell Markus Gattol he's wrong? No? Good, let's move on. Would you suggest a file-level encrypting filesystem instead, similar to eCryptFS? Would you suggest integrating encryption into ext4 (currently being worked on) and other filesystems? But what about a source tree, stored in a git repository, regularly manipulated with git and various command-line utilities, and edited with a variety of editors? How would you store that, securely, other than on a block device encrypted with full-disk encryption?
You could even teach specific tools to understand gpg, such as text editors that can decrypt to memory, edit, and re-encrypt before writing to disk. Sure, if you have a few specific files you want to encrypt, you could run gpg. However, what it doesn't explain is "what should users (developer or otherwise) do to encrypt all the random files on their system?".įull disk encryption has the advantage of being transparent and not application-specific, so you don't have to teach every random application to do application-level crypto. It does a good job of explaining why you don't (just) want full-disk encryption, and explaining why developers might want to use application-level crypto in their own application. So we should be careful about judging filesystem crypto by the standards of the 1990s. It was a unique and weird time, where there was a lot of demand and interest in crypto, but not enough knowledge to supply crypto effectively.
#Truecrypt status how to#
What people who don't spend a lot of time studying crypto should remember is that nobody knew how to encrypt anything in the 1990s. Being message-aware, they can protect files at a better level of granularity than "all or nothing", which for instance is the security failure that made it so easy for the FBI to convict Ross Ulbricht for Silk Road.Ī lot of concerns about filesystem crypto stem from the fact that filesystem crypto precedes sector-level crypto, and most of it was designed (or has designs tracing to) the 1990s. They're message-aware, so they can apply authentication at meaningful boundaries a block crypto device is essentially a simulated hard disk, and so it doesn't know where files begin and end.ģ. The fact that sector-level crypto can't do this means that the "state of the art" in efficient sector crypto is essentially unauthenticated ECB mode.Ģ. They have storage flexibility, so they can allocate metadata to authenticators and nonces. There are three huge advantages filesystems have over block devices when it comes to encryption:ġ.
0 kommentar(er)
