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."

Comments

Brute force

[Anonymous Coward]

Brute force via software? No, no. You're going about it wrong. You need to apply brute force to the operator.

Re:Brute force

[magarity]

You need to apply brute force to the operator

That's why my password is "I'll never tell!"

Oblig xkcd

[PPH]

http://xkcd.com/538/

Re:Oblig xkcd

[davydagger]

thats somewhat bullshit, because rubber hose cryptography is almost as much fantasy as what they critize. What is depicted is likely mabey %1 of all scenarios where encryption would help you.

Beating the password out of someone is more an act of romantic fiction, than standard practice, just about anywhere in the world. While XKCD recognizes that most nerds obviously aren't James Bonds, what they miss is most digital adversaries aren't James Bond Villans either.

1. Most of the time, the person is simply going to either steal, or subversively copy your encrypted disk, so you don't even know they are looking for it. Read: what the NSA or any other wiretap is doing. They count on suprise that you don't know your being monitored. Hence they can't hit you, and expect that you remain unaware they are after your data. If they can't break the cipher, they can't break it. More likely, its not going to be a three letter agency, and just a common theif, who, will not have the resources or ability to try beat you for the password, and certainly does not want to confront you, just get your information without you finding out and changing your passwords.

2. Another situation is where they do confront you, but they simply don't either have the political will to beat you for your password. More common than you'd think, because, well, simply put, beating people doesn't make a regime popular with its constituents. Your going to have to be accused of something fairly bad before it becomes acceptable. If you have a hidden encryption scheme like TC does, and they don't know if its there for sure, they could beat you all day long and they'd never know if you were telling the truth or not. Torture is not effective. This has been known for centuries. Despite what the defeatists will tell you. Torture in war is done more to break the spirit, will and emotions of the enemy than it is for information. Or just for the kicks or emotional benefit of really pissed off angry people.

you can look up US case law on this.

3. If your adversary is in the government, your adversary might not be the entire government or entire system. Encryption that police cannot recover on their own, might help you, if the cops are crooked as shit, but the DA, Judge, or someone else in the system cares. Encryption that can last long enough to make it into the court room, can save your otherwise wild and henious accusations against police misbehavior. Don't give the cops the opperuntity to tamper with the evidence, or force them to hand you a subopena or warrant, or hold out on giving up your keys until talking with a lawyer will give you many more options.

Re:Oblig xkcd

[davydagger]

Even with "manditory key disclosure" durring criminal trials, you have the benefit of needing to go to trial to give up your keys. The police can't randomly search your data, which encryption the police cannot break becomes a major lever against police abusing their power. Thats the point. They need a warrant, which means they need a judge, and probable cause, and a paper trail you can fight in court.

Even if thats all bogus, it becomes public record, so the public can have an informed debate over who the police are searching and why.

As opposed to breakable crypto, where the cops can just crack anyone's setup, without the need for justification.

Re:Oblig xkcd

[Will_Malverson]

I've posted this before, but I want to get this idea out there:

Here's how to make your password truly secure, if you really have something you want to hide:

1) Get fifty dollar bills. Maybe get some fives and tens mixed in with them. Total cost less than $100.

2) Shuffle them into a random order.

3) Set your Truecrypt (or Veracrypt, or whatever) password to be the hundred-digit number formed by taking the two least significant digits of the bills' serial numbers, in order.

4) Keep the stack of cash next to your computer, and make sure you don't let it get out of order. If you lose - or even just drop - the stack, it's game over. If/when you find yourself starting to remember the password and able to enter it without referring to the stack, shuffle the stack and change your password.

5) If an adversary raids your house, chances are that the stack of cash will simply vanish into a pocket. And if that doesn't happen, odds are pretty good that the stack will be scrambled, especially if there are different denominations mixed in.

6) At this point, your password is well and truly gone. No amount of rubber hose cryptography can bring it back.

7) The best part about this plan is you don't have to actually do it. Your password can be your dog's name, as long as you're willing to stick to your story - and it helps if you actually keep a stack of cash next to your computer - that you did steps 1-4.

Re:Oblig xkcd

[hairyfeet]

"Torture is not effective"...sure it is, you are just doing it wrong. What you have to do is the way the cops do it which is NOT to torture and threaten the subject but instead go after their families and you'll get whatever you want quite easily.

The cops do this kind of shit all the time and the reason why is because it often works without even having to do the deed, just the threat of the action is enough. You tell a parent you are gonna send their kids to the nightmare that is the foster care system, if they have a relative in trouble threaten to bury them in charges, and of course if they are on any kind of aid its quite easily to threaten them with homelessness.

Rubber hoses are 1950s tech Daddy-o, mental anguish works a LOT better and doesn't leave any marks that will come back to bite you in the ass.

Re:Oblig xkcd

[Anonymous Coward]

You really missed the point of his process.
You should read his post again without the idea of being a dick about it.

Re:I'm not an encryption expert by any means...

[exploder]

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.

Re:I'm not an encryption expert by any means...

[Anonymous Coward]

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.

Re:Wow, that's a lot of iterations

[exploder]

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?

Any idiot knows you have to do it a million and one times.

Just goto the codeplex site and verify the commits

[BrookHarty]

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.

You'll give them the password

[ourlovecanlastforeve]

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.

Re:You'll give them the password

[GrahamCox]

So given that, the right thing is not to give them the password. Without it they cannot prove anything, however much pressure they apply. There may be the assumption that you have something to hide, but without proof, you're innocent, right?

Re:You'll give them the password

[Boronx]

Never make a deal with a prosecutor without a judge approved plea bargain.

A coworker was in a car accident with her sister driving. The prosecutor told her sister: "We're charing you with reckless driving. Just plead guilty and you'll get off with a small fine. I'll ask the judge to be lenient."

They charged her with assault on her own sister. Confused, she pled guilty anyway, like she said she would. The prosecutor asked for the maximum penalty which includes jail time, and got it.

Nope not suspicious at all

[ourlovecanlastforeve]

New submitter poseur writes:

hey guyz get this new crypto for your puterz!!

-TOTALLY NOT DHS

Re:Nope not suspicious at all

[joe_frisch]

That is EXACTLY the problem. Determining a chain of trust is tricky. Producing a chain of trust that a non-expert can trust is almost impossible. Most users cannot verify the algorithms themselves so they have to rely on the evaluation of other people. But, how to trust those other people?

Government organizations have the resources to flood discussion groups like this with reasonable-sounding statements about how well something has been verified, while discrediting anyone who posts an message disagreeing.

If someone posts that I am wrong, how can I, or any non-expert know if the arguments against this post are valid?

Re:I'm not an encryption expert by any means...

[Anonymous Coward]

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.

Re:CipherShed

[unrtst]

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.

Re:Conflicting info on licence and relation to TC

[fnj]

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.

Re:why use this instead of say dm-crypt?

[plover]

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.