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.
So what happened to CipherShed? I thought they were the next TrueCrypt?
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.
...it makes the software a minimum of 10 and a maximum of about 300 times harder to brute force."
What an odd sentence. Did you mean "...it makes the software 10 to 300 times harder to brute force"?
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.
No, it doesn't mean that.
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.
If he was going to change it why not go straight to scrypt, which is known to be resistant to GPU decryption?
Nobody was ever going to brute force the original TrueCrypt.
VeraCrypt's website says it's "based on TrueCrypt", but the licence page says it's released under the Microsoft (!) Public licence (which is a free software licence, incompatible with the GPL.)
But TrueCrypt (now unmaintained) was never released under any free software licence, so VeraCrypt can't be both based on TrueCrypt and be under the Microsoft Public Licence. Anyone know which info is accurate and why they make this conflicting claim?
Of course, using Microsoft's codeplex hosting, and Microsoft's licence raises doubts about the software given that Microsoft has already been caught handing data to the NSA and putting in backdoors for the NSA.
Help build the anti-software-patent wiki
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
What's about Somalia law?
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.
When you can't rip off a name in English, do it in Latin!
But hey; at least it's better than CipherShed. My days of not taking FOSS names seriously are certainly coming to a middle.
stealth joke alert
How can I believe you when you tell me what I don't want to hear?
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.
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.
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!!
I don't consider that last part "better." Making up for people stupid enough to choose a weak password is not "stronger" it's actually weaker because it's enabling them. You know what else makes your password 10-300x harder to brute force? Adding 2 characters.
"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.
Cool, they have en_RN as a language choice, like in RedHat 5.x? (Not RHEL... RedHat.)
Thanks coward, I thought that was for other projects not downloading the program it self. They sure went out of their way to hide it from my eyes.
Star Trek, there maybe hope.
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.
A good passphrase (>100 bits of Entropy) will be unbreakable even completely without iteration. For a bad passphrase, iteration adds effort. TrueCrypt was sadly outdated compared to other disk encryption tools, but is not in line with established wisdom again.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
For a given security level more iterations means you can have a shorter password. In this case, if it really is 300 times slower to try a password in a brute force or dictionary attack, you can drop log(2, 300) = 8.2 bits of entropy. According to xkcd 936 typical naive passwords have ~ 28 bits /11 character = 2.55 bits of entropy per character. This means you can drop ~log(2, 300) / (28/11) = 3.2 characters from your password and keep the same security. Alternatively, you could keep the same password and its as good as if it were 3.2 characters longer.
Note: this is just assuming the best case of 300 times harder and a crappy passwords. Realistically it's less effective than that, but you get the idea.
If you use the exiting container, you get its properties and hence its far too low password iteration numbers. It is a valid design decision to not support that.
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.
And that probably only begins to approach the computational power the NSA has at its disposal
It is sure that the NSA has at its disposable a ridiculous amount of computing power, but it is equally evident that they cannot only use it once at a time. I.e. they may well have a billion CPUs, if it takes one billion hours to crack a disk they can only crack a disk an hour. Also, even the best parallel cracking scheme is going to scale less than perfect on a massive parallel setup, let alone a cheap cloud infrastructure.
this post contain no useful information, no need to mod it down
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.
Bitlocker under standard settings uses the TPM for key management. You have only the manufacturer's* word that the TPM is free of backdoors, as it's a hardware component. That's why truecrypt doesn't use it.
*Usually Intel
You are right, but let me rephrase: the algorithm scales perfectly, what does not is the initial distribution of the data; also the operating system poses some limits to scalability, specialized parallel infrastructures use custom operating systems to mitigate this effect.
this post contain no useful information, no need to mod it down
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.
If they were able to send you away for a very long time then they would have sent you away for a very long time. Prosecutor isn't cooperating with your defense, why would you cooperate by slipping the noose around your neck?
Since it hasn't been spammed here enough: never talk to the police.
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.
boatloader beer, of course.
Actually, Microsoft has published details that answer some of your questions, which have then been verified by security researchers. Of course the point still stands that it isn't as trustworthy as TrueCrypt, but it certainly appears to be good enough for many people as so far no law enforcement agency has demonstrated the ability to crack it.
Lack of deniability is a problem, but there are advantages too. It has good enterprise tools and with SSDs that support eDrive can potentially be used without performance penalty. Again, you might not be able to trust it as much as TrueCrypt, but since no commercial or underworld software exists to exploit flaws in BitLocker it seems like a good choice for a company looking to protect its laptops in the field at minimal cost and complexity.
In some ways BitLocker may be even more secure than TrueCrypt, if Microsoft are right about what they say, because it can make use of TPM to store the key. That should thwart cold boot attacks and DMA attacks (via Firewire/Thunderbolt/PC Card), for example.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
yesyesyes, but can it stop the cops reading the sticky notes that ppl use to write down there passwords :P
You have 5 Moderator Points!
Which Helpless Linux zealot/MS basher do you want to mod down today?
Apparently VeraCrypt also solves also many vulnerabilities found in TrueCrypt (bootloader, kernel, string handling...). The author posted a comment explaining this : https://veracrypt.codeplex.com... Any thoughts about this, especially for TrueCrypt users?