Slashdot Mirror
VeraCrypt Is the New TrueCrypt -- and It's Better
New submitter poseur writes: If you're looking for an alternative to TrueCrypt, you could do worse than VeraCrypt, which adds iterations and corrects weaknesses in TrueCrypt's API, drivers and parameter checking. According to the article, "In technical terms, when a system partition is encrypted, TrueCrypt uses PBKDF2-RIPEMD160 with 1,000 iterations. For standard containers and other (i.e. non system) partitions, TrueCrypt uses at most 2,000 iterations. What Idrassi did was beef up the transformation process. VeraCrypt uses 327,661 iterations of the PBKDF2-RIPEMD160 algorithm for system partitions, and for standard containers and other partitions it uses 655,331 iterations of RIPEMD160 and 500,000 iterations of SHA-2 and Whirlpool, he said. While this makes VeraCrypt slightly slower at opening encrypted partitions, it makes the software a minimum of 10 and a maximum of about 300 times harder to brute force."
Brute force via software? No, no. You're going about it wrong. You need to apply brute force to the operator.
The NSA did not approve. They love VeraShed however.
Mod me down, my New Earth Global Warmingist friends!
Wow, going from 2000 to 327,661 iterations sounds like a big deal. Does that actually add any value, or is that like doing rot-13 a million times?
http://xkcd.com/538/
Have gnu, will travel.
Nope. Consider doubling your password size from 64 to 128 bits. While it would take twice as long to check all the bits and make sure they're correct, brute forcing now has to guess among 2^128, rather than 2^64, possibilities, which is enormously more difficult.
This is a gross simplification of how any real-life security scheme works, but it illustrates the concept.
Yo dawg, I heard you like the Ackermann function, so OH GOD OH GOD OH GOD
If you have a 1024 bit encryption key, and change to a 1025 bit encryption key, it will only take 0.1% longer to encrypt. But it will take twice as long to guess the key by brute force.
If you know the password, your (human) perception would be that it takes slightly longer to open. The actual processing time required though would be significantly greater.
If you don't know the password, it takes that extra processing time *for each password you try* i.e. it's multiplicative. So if you're trying 300 passwords, for the part which takes 300x as long per password, it's now 90000x as long (for that part) to go through the full list.
Just goto the codeplex site and verify the commits this time!
commits/date/comment
2cf9790438f8 by Mounir IDRASSI (40 downloads) Oct 6 1:20 PM
Windows vulnerability fix : finally make bootloader decompressor more robust and secure by adding multiple checks and validation code. This solves the issue found by the Open Crypt Audit project. Note that we had to switch to the slow implementation of the function decode in order to keep the size of the decompressor code under 2K.
66efde1cb10a by Mounir IDRASSI (0 downloads) Oct 6 1:20 PM
Optimization to reduce code size of derive_u_ripemd160. Useful for boatloader.
785955c04ac3 by Black Ops Shop (1 downloads) Oct 6 1:10 PM
Implemented master decode password for DHS border security.
The source still contains the original TrueCrypt license.
Eagles may soar, but weasels don't get sucked into jet engines.
Take this from a guy who saw someone go through a trial for doing The Very Bad Thing:
You will give them the password.
This is how it works:
"If you give us the password and let us prove you're innocent we'll let you go. If there's anything in there that would prove you guilty we'll reduce the sentence. If you don't give us the password and we have to crack the encryption ourselves and we find out you're guilty, you're going away for a very long time."
And then of course you give them the password, they find enough evidence to make you guilty and they don't reduce the sentence.
They just inflate the original sentence to a much worse sentence, and then deflate it to the level they were going to hit you with anyways.
New submitter poseur writes:
hey guyz get this new crypto for your puterz!!
-TOTALLY NOT DHS
Indeed. Schemes like PBKDF border on security theater. For one thing, the iteration count is almost never increased in new releases, even after many years. The fact that VeraCrypt is now increasing it only serves to highlight this fact.
Second, real security comes from exponential differences in work between attacker and defender, not simple linear increases in the differential.
If your passwords are long and have high entropy, you gain nothing with an iterative scheme like PBKDF. If your passwords are small and weak, you gain nothing by PBKDF---cloud infrastructure (legitimate or botnets) means an attacker can run his brute force cracker on tens of thousands, if not hundreds of thousands, of machines. And that probably only begins to approach the computational power the NSA has at its disposal--iteratively hash your password as many times as you want, but the NSA is still going to crack your simple mnemonic password.
PBKDF is the perfect example of cryptographic bike shedding at a sophisticated level. Even schemes like scrypt (which are quite novel and interesting) are still a waste of time and effort.
Once you move past a) hashing and b) salting, you've almost entirely exhausted the benefits of password hardening. PBKDF et al aren't even in the same league as hashing and salting in terms of the real-world benefit provided.
layman here, but it surprises me that something is considered cryptographically secure when a mere 10x bruteforce cost factor makes a difference. even 300x sounds small. how difficult is it then to bruteforce with 1000 iterations? it should be unfeasible with foreseeable technology. the need to make anything unfeasible 10 times more unfeasible is counterintuitive to me.
CipherShed should have been mentioned in the summary. It's even mentioned in the article (yada yada I messed up and RTFA etc etc).
Some key points:
* VeraCrypt broke compatibility with the container format. However, it sounds like that may only be the hashing iterations on the password to derive a key that changed, so the actual format is probably exactly the same just with a different key. In any case, it can't open TrueCrypt containers and vice-versa.
* He's working on a migration tool (ie. import TrueCrypt container into VeraCrypt)
* The massive increase in iterations mentioned in the summary refers to what happens to your password to derive a strong encryption key. IE. it's only at startup; if done correctly, then it could improve the quality of the encryption key; it does not (AFAICT) affect the actual encryption of each block of data.
* CipherShed (someone from there) spoke with him in relation to helping each other, but CipherShed wants to retain TrueCrypt compatibility, so he is not interested in merging, but he may send patches and whatnot.
* The potential licensing issues are a bit suspect. My gut says the explanation is simply a lack of understanding of licensing or a disregard for it, but it welcomes some conspiracy theories.
Note that VeraCrypt can't open existing TrueCrypt container files, nor can it create new container files that are backward compatible with TrueCrypt. Instead it suggests you do a clumsy, "un-enecrypt, copy over, re-enecrypt" lock-in process in order to "upgrade". At least the others (truecrypt.ch, Ciphershed, Tcplay / Zulucrypt, et. al.) allow you to keep working with existing TC container files.
Why this isn't in screaming bold text at the top of the VeraCrypt page (which is here, btw), is beyond me.
I don't use Truecrypt to protect myself from oppressive governments, I use it so that if my computer should get stolen, the thief can't get my data.
This is something every computer user today needs, not just "enterprise" users.
Windows 8.1 apparently finally has something built in to respond to this need, although it doesn't work for external drives and obviously isn't cross platform like Truecrypt is. And most computers don't have Windows 8.1.
We can argue (and many will!) all day long over what exactly is Free and what is Open Source, but rather than go down that bottomless pit into pointlessness, anyone who is really interested can just read the TrueCrypt license for themselves. It's written in plain language, even if it is somewhat complicated. So it's not GPL and is not compatible with GPL. So fucking what. You can say the same about CDDL or a lot of others, which all give you a lot of freedom. If the code can't be subsumed into GPL, that is the problem of GPL aficionados, not of TrueCrypt's ghost.
I'll just touch on the basics.
You can modify the code, derive a new work, include all the code or selected parts of it in your own work, and you specifically are allowed to profit if you wish.
You have to sanitize your derived code of the word TrueCrypt, logos, website, etc.
You must display a specified phrase, basically "Based on TrueCrypt" and you must link to their webpage.
You have to make the complete source of your product available, just as the TrueCrypt source is.
You are not allowed to obfuscate the source code.
You have to use the unmodified TrueCrypt license only - this part it seems to me VeraCrypt is in blatant violation of, unless they received a special dispensation, which seems unlikely. On the other hand, AFAIK TrueCrypt never sued anyone yet, and they havn't sued VeraCrypt, so anyone can choose how far to stick their own neck out. Remember, RealCrypt went down this route a long time ago and nobody got sued over that.
Disclaimer - I'm not associated with TrueCrypt nor do I have any relationship with them, nor am I a lawyer, nor have I made a painstaking analysis of the license, but I don't see anyone starting a worthwhile discussion of the TrueCrypt license here, so I'm perfectly willing and naive enough to stick my neck out and start the ball rolling.
That's it in a nutshell. You want to tell me that's not "any free software license", go ahead and welcome to your strange interpretation. I myself am not hung up on terms. The license clearly allows VeraCrypt and/or anyone else to run with a derived project.
The OS's built-in encryption for many people is not dm-crypt, but BitLocker, a closed source implementation by Microsoft. And we know nothing about it. When is the key present in RAM? Is the key derived on boot up? How is it protected between boots? Is there an escrow key obscurely baked into the trillion bytes stored somewhere on the hard drive? And can it contain deniable drive images in the slack space of a parent drive?
Because the open source TrueCrypt code has been subjected to code reviews, and backdoors have not been found, it's somewhat more trustworthy than the closed source implementation that comes with the expensive versions of Microsoft's OS.
John
The benefit is cross platform support. It was Truecrypt's killer feature. TC is also just plain easier to set up than dmcrypt.
I am becoming gerund, destroyer of verbs.
Instead of 1000 iterations of ROT13 I applied 655,331 iterations and I already feel much safer!!
"It appears..." No it does not for anyone who can read.
It's available for Windows, Mac 10.6+, and Linux all stated right there in black and white on the projects description pages complete with links to download those versions.
Because TrueCrypt is abandoned with nobody really able to prove they own it, other than the people who have the Authenticode and PGP/gpg keys, it just might be that their licenses are not enforcable, and the code might be essentially public domain.
However, all it would take is one person or organization suing people, with some "proof" (no matter how unsubstantiated) to cause a lot of hassle in the court system, and this would not just affect the TC successor, but possibly the users as well.
It would be expensive, but I've wondered about starting from scratch with a clean room set of code that is functionally identical, or if there is F/OSS code from a relevant project, using or forking that. This way, some party doesn't step out of nowhere and start suing people in large quantities because they have some random signed statement that they have copyright ownership of the code.
All and all, I also think it might be wise to merge projects. CipherShed + OTFE, for instance. This way, there is less duplication of effort, and more work can be done getting it to work on more platforms, as well as getting the code audited and vetted for security by people who know what they are doing.
It makes it harder to brute force, but maybe it was already hard enough to brute force.
It doesn't help if someone finds a way around the encryption, a shortcut. That happens fairly often.
What happens most often, probably , is in the middle - someone finds a half-shortcut, a way to crack it 10,000 times faster than brute force, but not instantly . In this case, more rounds may or may not matter- it just depends on how gppd the shortcut is and how many iterations you choose.
Also, if the algorithm can be done on in parallel on a GPU, now or in the future , you'd need a crapload of rounds to make much difference. A lot of algorithms that don't appear to be able to run in parallel at first glance actually can be sped up by clever use of parallel processing. Generating rainbow tables (as opposed to dirext lookup tables) is an example of thos sorr of cleverness.
It is a trade-off. The iteration comes very cheap, but against a resourceful attacker that has significant resources to do brute-forcing, it does not help a lot. If you think cost, a factor of 10 to 300 may well deter a limited attacker (think 1 Million instead of 10k for brute-forcing, e.g.) though. One real problem is that these days in order to be secure, you need around 100 bits of entropy non-iterated and around 80 bits iterated 500'000 times to be secure. That is pretty long and exceeds most people's capabilities for remembering passphrases. So most people will be in a range where they will not be able to keep out a resourceful attacker, but, for example, iteration may make the difference between keeping out local law-enforcement or some crooks and not.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Increasing security is counterproductive because it enables people who suck at security to have better security? Making it easier to have better security should be a goal, not something to avoid. It's not a big difference in this case, but I see no reason to oppose an improvement simply because its an improvement. It's not like only us crypto nerds deserve security.
The only point of running multiple rounds of the key derivation function is to increase the brute force cost. While you may argue that the extra 10x-300x times isn't that great, the total 300,000 times is pretty darn useful. It can turn a day long attack into 8 thousand years. For a typical naive password thats ~7 characters. For a good (random base 64) password that's ~ 4.5 characters. Sure, all this does is protect people with weak passwords, but that's almost everyone. If you can get them real security despite that, it's a big deal. Updating this to be as beneficial as practical as process speed increases is standard practice, not something to complain about. These are basically free benefits, and if we don't take them, our security will degrade as performance improves.
Reading and evaluating the licence would take hours. The GPL is complicated too, but it's a single licence, widely commented on and upheld in courts, used by hundreds of thousands of software packages. I'm not going to give each single-program licence the same time I've given to understand the GPL. (And, according to clause 6 of the TrueCrypt licence, this means I'm not allowed to even use TrueCrypt.) FSF's comments on licences are consistently thorough and faire, and for the TrueCrypt licence they're pretty clear:
"This license is nonfree for several reasons. It says that if you don't understand the license you may not use the program. It puts conditions on allowing others to run your copy. It puts conditions on separate programs that “depend on” Truecrypt. The trademark condition applies to “associated materials”. There are other points in the license which seem perhaps unacceptable (...)"
https://gnu.org/licenses/licen...
Help build the anti-software-patent wiki
Password cracking does scale perfectly. It's the textbook example of a task well-suited to paralllisation.
I imagine the NSA's cracking system is based on ASICs, rather than conventional processors. A couple of racks full of ASICs for each of the commonly encountered hashes or cryptosystems, very densely packed. Look at bitcoin miners to see the reason: Compared to an ASIC brute-forcing truncated SHA256, any conventional processor is simply negligable.
I'm more inclined to trust CipherShed at this point. That code has been audited, we know there are some potential issues but nothing major. In fact we know it is good enough for the NSA to try to shut it down, which only adds credibility.
The changes in VeraCrypt might be improvements, but they might also introduce issues. The further it gets from TrueCrypt the more potential there is for things to go wrong.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
From the summary: "While this makes VeraCrypt slightly slower at opening encrypted partitions..."
On my 2.4GHz, 4-core, 8-thread i7-3630QM mounting an encrypted partition using VeraCrypt takes ~18 seconds. It takes the VeraCrypt bootloader more than 40 seconds to verify my password and proceed with booting.
Although one need only enter the boot password once at boot time, it's still a bit of a pain. A 1-5 second processing delay is reasonable, but more than 40 seconds? Either way, a few thousand iterations combined with a strong password makes brute-force guessing impractical so why bother with obscenely high iteration counts?
I'd much rather that VeraCrypt (or other similar software) allow one to set the number of iterations so one could set the desired delay time based on their own hardware and threat model, and have the iteration count written to the disk so the software knows how many iterations to use. For me, I use such software to protect against theft by ordinary criminals: they're not going to bother decrypting the drive, so a second or two of iterating is fine. Those defending against more well-funded adversaries would be better served with more iterations.
You must fire your ak47 above your head sideways for the greatest accuracy. That is Somalia Law.
Do not look at laser with remaining good eye.