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

[Anonymous Coward]

The joke is on you, Mjölnir is too short by accident.

Re:Brute force

[Anonymous Coward]

That reminds me of the joke about a guy in a chat room saying his dick is so long, on the keyboard it reaches from a to z.

Re:Brute force

[magarity]

You need to apply brute force to the operator

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

Re:Brute force

[Anonymous Coward]

That sounds good until you're beaten to death because of it.

CAPTCHA: killjoy. I'd swear Slashdot has a system that tries to pick captchas related to the post.

Re:Brute force

[Anonymous Coward]

Shit. Someone just hacked my /. account. Please give it back?

Re:Brute force

[Anonymous Coward]

dvorak?

Re:Brute force

[Anonymous Coward]

French Azerty probably

Re:Brute force

[Anonymous Coward]

I did that once - except the password was "sod off"

"Dave, whats the password?"
"sod off"
"Seriously Dave, I need the password"
"sod off"
"Steve, I've asked Dave the password but he keeps telling me to sod off"
"Have you tried using it as the password?"
"what?"
"The password is "sod off", type it in"

Re:Brute force

[Anonymous Coward]

No, AZERTY! He was French.

Re:Brute force

[Anonymous Coward]

No, he was actually typing with it.

Re:Brute force

[Anonymous Coward]

Sad bastard

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

[Anonymous Coward]

... but wouldn't anything that makes it take *slightly* longer to open also make it take *slightly* longer to brute force? Or put the other way, to be 300x harder to brute force wouldn't that mean it takes 300x as long to open?

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:I'm not an encryption expert by any means...

[Lunix Nutcase]

No, it doesn't mean that.

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

[Anonymous Coward]

... but wouldn't anything that makes it take *slightly* longer to open also make it take *slightly* longer to brute force? Or put the other way, to be 300x harder to brute force wouldn't that mean it takes 300x as long to open?

It depends on what type of brute force is used. There is the standard start with the lowest value and work your way up the string chain, then there are the more favored guessing from a large dictionary of known popular passwords, then brute force properly up from there as a last resort.

Simply put, adding another character to a password makes it exponentially harder to brute force with the systematic guessing (as long as the password isn't in a dictionary). Obfuscating the password with more (possibly unknown number) of iterations does help, but not from a fault in an algorithm approach.

All this said, I have only done some minor study into encryption. I'm sure others here can explain better or where my understanding is wrong.

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

[tdelaney]

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.

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:I'm not an encryption expert by any means...

[Anonymous Coward]

Guess a number between 0-9. Got it? Fair enough chance you might. Now guess one between 0 and 999. I just tripled the digits, but it ain't so easy, eh, fellow? There are now 1000 possibilities instead of just 10.

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

[paulatz]

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.

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

[SuricouRaven]

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.

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

[Anonymous Coward]

It depends on what type of brute force is used. There is the standard start with the lowest value and work your way up the string chain, then there are the more favored guessing from a large dictionary of known popular passwords, then brute force properly up from there as a last resort.

I need to correct you on a couple things here.
First of all, starting with the lowest value and working up is not at all 'Standard', it's a simplistic way to illustrate the concept of 'try all combinations'. In reality a full-on brute force is going to use a more complex methodology.
Second, use of a Dictionary isn't brute force, it's a Dictionary attack. Thus the name. And usually they'll use a permutated dictionary attack in particular.
Finally, in the real world, if you have good reason to suspect the target used a strong key, specifically a cryptographically strong one, then you'll actually use some form of simply generating guesses out of sections of the value space chosen at random. If you have any reason to think that the target used a weaker key (anything which contains ANY real words or word segments, or 'mangled' words) then you'd start by running a permutated Dictionary first.

Simply put, adding another character to a password makes it exponentially harder to brute force with the systematic guessing

Again, only if they are using the Grade School level brute force method. What it does in reality is increase the worst case time to crack (from the point of view of the attacker). Calculating the real-world time to crack is not nearly as simple as people assume- you can't just take the total number of combinations and say "welp, they have a 1 in that chance" because it doesn't really work that way. Instead you have to understand that each time they can validate an incorrect key, their next guess has a worst-case chance of "1 in X minus the number of keys already eliminated".

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

[paulatz]

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.

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

[Anonymous Coward]

I completely disagree with the statement that PBKDF and scrypt are useless. They have the useful property that they greatly slow down the password discovery process. An attacker will need either a vastly larger amount of computing power available, or be willing to spend much more time breaking a password. When you read about criminal cases where the FBI tries to break a password, they'll often spend a few months trying to break it. If you password is reasonably hard, and protected with PBKDF, they may give up before they find it, while if it's only protected by a salted hash, you'll need a much longer password.

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

[Anonymous Coward]

Doubling the number of iterations blindly does *NOT* double the security by necessity.
For example, imagine an operation like exponentiation via some modulus with some secret exponent.
Applying this operation over and over again, only reduces the group size of the result (less numbers in total can be produced by the algorithm). In fact, with enough iterations, the result is identity regardless of the secret key.
It's like doubling the iterations of iterations of ROT13 to be doubly safe.

This is why the specs of the hashing and encryption algorithms include the number of recommended iterations. I do not trust someone who blindly decides to alter specs if they don't present a very good reason for doing so. And "more is better" is not such a reason.

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

[Anonymous Coward]

PBKDF is essentially iterated hash + salt. Why would you say that "PBKDF et al aren't even in the same league as hashing and salting"?

CipherShed

[Anonymous Coward]

So what happened to CipherShed? I thought they were the next TrueCrypt?

Re:CipherShed

[binarylarry]

The NSA did not approve. They love VeraShed however.

Re:CipherShed

[Anonymous Coward]

Fnord, fnord, fnord.

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:CipherShed

[Anonymous Coward]

Yeah, no. Diskcryptor has always been the alternative, even when TrueCrypt was active.

Re:CipherShed

[dargaud]

As long as I can run both on the same computer temporarily so I can copy from old container to new one, it should be OK.

Re:CipherShed

[AmiMoJo]

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.

Re:CipherShed

[Anonymous Coward]

Unfortunately, it's windows only, which makes it quite useless for most people who actually use encryption.

Re:CipherShed

[hodet]

The first line of the article.

"If you're reluctant to continue using TrueCrypt now that the open source encryption project has been abandoned, and you don't want to wait for the CipherShed fork to mature..."

Wow, that's a lot of iterations

[mveloso]

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?

Re:Wow, that's a lot of iterations

[Anonymous Coward]

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?

Adding iterations doesn't strengthen encryption per se, but it adds compute-time to any theoretical attacker's brute-force attack. It's pretty standard practice in certain applications. That said, just make sure you iterate your rot-13 an even number of times and you'll have no worries.

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.

Re:Wow, that's a lot of iterations

[Anonymous Coward]

300x harder. Which, to a bitmining rig, isn't.

Re:Wow, that's a lot of iterations

[Anonymous Coward]

Each iteration adds a little more time (milliseconds) to the decryption process, so adding the cost of time to each guess of a brute force attack will make such an attack impractical.

Re:Wow, that's a lot of iterations

[thegarbz]

rot-13 would be far more secure if you did it 1000001 times.

Re:Wow, that's a lot of iterations

[bobbied]

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?

No, it actually helps, but you have to understand what they are doing before it makes sense.

Usually they use an encryption technique that takes a fixed sized key, usually multiples of 8 bits or so. This means you can optimize the software (or hardware) to encrypt using say 16 bits. You want 160 bits in your key, so you run 10 times though, using up 16 bits of your key each time. However, with 160 bits, you can now change how you rotate the bits in the key. Say you advance only 2 bits each time, then you run though your ~80 iterations. Therr are a whole bunch of options on how you use your keys with the same encryption technique. Now, there is also some gain from encrypting multiple times using the same key too. It means you have to know how many iterations to try which adds to the complexity of the code breaker's task.

Now I have simplified all this by leaving some important details out, but as you can see, multiple trips though the encryption process can be helpful, especially if it includes making use of more bits worth of key, rotating the key bits and the decrypter doesn't know how many encryption passes you used or what key rotation process you used.

Re:Wow, that's a lot of iterations

[dbraden]

Haha, nice, I was thinking the same thing.

Re:Wow, that's a lot of iterations

[Anonymous Coward]

+1 Funny

Re:Wow, that's a lot of iterations

[Anonymous Coward]

Does that actually add any value, or is that like doing rot-13 a million times?

It does ROT-13 999999 times and then adds the value of 13.

Re:Wow, that's a lot of iterations

[kualla]

If there is some way to dramatically speed up the decryption that is discovered later on(or discovered and not publicly known), the increase of iterations could be next to meaningless. It is best to use 2 or more forms of encryption than a single form and adding multiple times more iterations to. I am not familiar with the PBKDF2-RIPEMD160 that is used in VeraCrypt, it could already be using multiple forms of proven-strong encryption standards... I do believe TrueCrypt allowed you to select from multiple different forms of encryption as well as using more than one, I would imagine and hope the same with VeraCrypt.

Re:Wow, that's a lot of iterations

[swillden]

Umm, no. The iteration count change has nothing to do with encryption or key scheduling.

This is about how the encryption is is produced. What's needed is a mechanism for turning the password you type in into a key that can be used with a block cipher (in some appropriate mode). Any cryptographic hash will do that, so let's suppose that you use SHA256. You hash the password, then use the resulting bits as a key to encrypt data with AES128. Even though the hash is strong and the encryption is strong, the system is almost certainly weak because the password is probably not very strong. Suppose it has 30 bits of entropy. This means there are 2^30 possible hashes and 2^30 possible encryption keys.

The best solution is to pick a stronger password, but we can do better even without requiring the user to get a better memory and type more.

The reason the system is weak is that SHA256 is fast. An attacker can try all 2^30 possible passwords fairly quickly, because a common desktop machine can perform millions of operations per second. Let's assume it's only a million per second. 2^30/1000000/60/2 = ~9 minutes, on average (the division by 2 is because on average the attacker only has to search half of the space).

Suppose instead that you iterate SHA256 a million times and use the result of that as the AES key. That means on your machine it takes you one second to compute the key before you can start decrypting. Assuming there's no defect in SHA256 that allows the attacker to shortcut those iterations, he has to do the same thing when trying to search the password space. Now instead of being able to test a million passwords per second, he can only test one per second, so brute forcing your password takes about 9 million minutes, which is about 17 years.

Well, assuming the attacker uses only one computer, and assuming that it's no more powerful than yours. In reality, the attacker is going to use a big stack of GPUs, each of which can perform SHA256 thousands of times faster than a desktop machine because they're vector machines. And, given the scheme described, he's going to store the results of those password hashing attempts, constructing a table so he can skip the hashing step when he attacks someone else's data.

To address the first problem, the solution is to use an iterated function that also uses a lot of RAM (to increase hardware costs for the attacker), and perhaps to increase the iteration count some more. To address the second problem, add salt.

It's worth pointing out that the PBKDF2 password hash used by both TrueCrypt and VeraCrypt does not use a lot of RAM. You need to upgrade to scrypt or newer hashing functions for that. I'm not sure why VeraCrypt didn't do that, since they were breaking compatibility anyway.

Oblig xkcd

[PPH]

http://xkcd.com/538/

Re:Oblig xkcd

[Archangel Michael]

The Real "Brute Force" approach.

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

[PPH]

you can look up US case law on this.

This is an international website. I can also look up this.

Re:Oblig xkcd

[Anonymous Coward]

STFU.

Re:Oblig xkcd

[Anonymous Coward]

Torture is not effective.

Torture is not [always] effective.

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

[c6gunner]

This is an international website. I can also look up this [wikipedia.org].

Key disclosure laws, huh? Ok, my key is ABC123.

What do you mean it didn't work. Shit. Ok, try QWERTY1234567890.

Still nothing? Dammit. Sorry guys. Ok, I'll need access to a writing pad and a random number generator ....

Re:Oblig xkcd

[Jane Q. Public]

Utter nonsense. You can get security at least as random with modern cryptography software, and still remember the password (unlike 50 ordered dollar bills).

And you don't have to let them pick up the bills. You just hit the "off" switch, and all is done. Let them ask all they want. You don't have to tell them. (At least in the U.S.)

With decent modern cryptography, YOU get to keep the password in memory, while they thrash around in the dark. The beauty being, of course, that they will never figure it out, but the information is still there when you get everything back later.

Here, the law says they can't compel you to produce an encryption key, except under very particular, special circumstances. And that is the way the law should be.

As a distraction from the real password, your idea is not a bad one. But it's poorly implemented. You could accomplish exactly the same with some of those fortunes from fortune cookies that have lottery numbers on them. Or some other cheaper method. All you really need is slips of paper or card with numbers.

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

[davester666]

except, now, the President has decided he has the right to [or somebody he delegates this stuff to], without having to present any evidence to anyone, capture you, fly you out of the country, and hold you indefinitely, and apply "enhanced interrogation techniques" to you. And neither notify anyone that the gov't has done this, nor admit to having done it after the fact.

you are just 'gone', because the President believes you are a bad person.

Re:Oblig xkcd

[Anonymous Coward]

That's why I keep all my files translated into aUI - I'll be happy to decrypt them for you, but I'll be damned if you can make me translate them back into English!

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:Oblig xkcd

[Anonymous Coward]

You did not understand what Will_Malverson was explaining at all. With the concept he explained, you could actually tell the truth about your encryption key.

Also, as you stated, you don't have to divulge your encryption key, but be aware, you will have plenty of time to think about your decision to lie and not divulge your encryption key while you are sitting in prison for contempt of court. So ultimately, you do need to tell the truth and divulge your key. With the concept Will_Malverson explained, you can tell the truth and still not divulge the key.

Re:Oblig xkcd

[Anonymous Coward]

Having said that, I've now realized it would be easy to figure out if the money was also confiscated and held as evidence by law enforcement.

Re:Oblig xkcd

[Anonymous Coward]

You are wrong about it being poorly implemented. The "encryption key" being printed on bills is the key here,
The acual password would naturally have nothing to do with the seriel numbers that would just make it needlessly complicated.

You could have only 45 bills and claim that originally there was 50. That would give you the chance to claim
corrupt investigators who ripped off the five $20 bills you had mixed in with your $1 bills. Not only
would it allow you to keep the password secret but also cast the investigating team in a bad light.
Tampering with the evidence and all that, the case might actually get thrown out of the court.

No one would steal your fortune cookies you know.

Re:Oblig xkcd

[halfgaar]

Seeing as how I remembered my Win95 (20 chars) and Win98 (25 chars) serial keys just from reinstalling every two months, I think I would remember that password quite quickly, having to type it every day. I actually still know those serials...

Re:Oblig xkcd

[SuricouRaven]

Police do have access to tools for countering the off switch. Devices that connect via firewire DMA to dump the contents of RAM and thus any keys within, or warm boot attack tools. But such things are specialised and expensive, and will not be deployed to the arrest of a run-of-the-mill criminal. They would have to have reason to suspect you of a serious technology-related crime before going to the trouble of sending a digital forensics specialist and their toolbox to the scene.

Stopping you hitting the 'off' switch is a long established issue - destruction of evidence has been an issue for decades, with people burning papers and flushing their drugs stash down the toilet as soon as they see the police coming. The counter-strategy is popular, but effective: Speed. If the police have reason to believe you may destroy evidence (Which is really common practice in all drugs related crimes) they get a no-knock warrant which allows them to smash your door down at four in the morning while everyone is in bed, charge into the house and force everyone to the ground at gunpoint. Done properly it means they can get their arrests done before anyone has the chance to destroy evidence, though many critics claim the method is heavily overused in the US, and there have been many incidents where people have mistaken the police assault for a robbery, grabbed for their gun and been swiftly killed in self defence by police officers.

Re:Oblig xkcd

[Anonymous Coward]

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.

It works both ways.

Do you think someone resorting to the rubber hose just say "Oh, that's unfortunate, you can go, we are sorry about the inconvenience."?
No, you'd better make user that the password is your dog's name, because they are going to keep beating you with the hose until you tell them the password, regardless of if you know it or not.

Well, actually the more likely scenario is that the judge will be angry with you for obstructing the justice and put you in jail until you tell the court what the key is.

Re:Oblig xkcd

[AmiMoJo]

The number of possible passwords using such a scheme is too low. The police could easily employ someone to write a little app that tries them all in a reasonable period of time.

Re:Oblig xkcd

[Anonymous Coward]

... just get your information without you finding out ...

That would be the key-logger method. So the rubber hose is not needed.

They count on surprise ...

No, they count on their tazer and handcuffs enforcing obedience; that's why the police carry them.

... don't either have the political will to beat you for your password ...

You're saying that government can't overpower one person: No, the person will spend 6 months in prison automatically according to some law (see UK) or 6 months in court paying lawyer's fees and losing his job.

... accused of something fairly bad ...

Have you seen politicians demanding unlimited search and seizure powers? It's a worldwide phenomenon now. That makes "something fairly bad" as easy as "prove you're not a terrorist".

... Torture is not effective.

That's because the torturer doesn't know who has the answer. When a HDD has your data or name on it, the torturer will gladly assume you have the keys to the encrypted data.

... your adversary might not be the entire government ...

How many government employees does it take to say "disobedience means torture or imprisonment"? This is the second time you've used "the government can't stop me" meme. I disagree and I think those people on no-fly lists disagree too.

... the system cares ...

In the USA, the system is tough on crime and criminals. If you've been arrested, then you are the criminal: That's all that matters.

Re:Oblig xkcd

[Anonymous Coward]

they get a no-knock warrant which allows them to smash your door down at four in the morning while everyone is in bed, charge into the house and force everyone to the ground at gunpoint. Done properly it means they can get their arrests done before anyone has the chance to destroy evidence

It also ensures that they do it at a time when my computer is off.

Re:Oblig xkcd

[Anonymous Coward]

Yeah, there's only 50! = 30414093201713378043612608166064768844377641568960512000000000000 possible combinations.
That's only slightly over 2**214 ...

Re:Oblig xkcd

[u38cg]

Erm, that's 10^100 possibilities. At 1000 guesses per second, that's 3.2e89 years to try them all, so about 1.6e89 years on average.

I guess it depends what you consider reasonable, though.

Re:Oblig xkcd

[risom]

Meanwhile, they let you rot in prison. Thats what key disclosure laws are about.

Re:Oblig xkcd

[Anonymous Coward]

More than the number of particles in the universe.

Re:Oblig xkcd

[Lumpy]

"Devices that connect via firewire DMA to dump the contents of RAM and thus any keys" -- I live this CSI fantasy crap.

If this is not done within 30 seconds then it's a waste of time as they will get nothing useful at all, it's only useful in a lab on a specific computer and has NEVER been used in law enforcement. I would love to see this work on my Toughbook that does not even have firewire.

Re:Oblig xkcd

[Gavagai80]

The money would likely not be held in evidence in the correct order.

Re:Oblig xkcd

[BlackDesign]

Step 4 isn't quite correct... Keep the old stack together, fill in the old password, then reshuffle and fill in the new... If you shuffle first, you might end up not being able to change your password since you don't remember the old one ;-)

Re:Oblig xkcd

[binarylarry]

Would deleting/destroying your keys be considered destroying evidence?

Re:Oblig xkcd

[Anonymous Coward]

But once the suspect has told you his story it's simple to brute force the key using your informed knowledge. It doesn't need many guesses at all.

Re:Oblig xkcd

[AmiMoJo]

1000 guesses per second is way below what modern hardware is capable of. Have a look here: http://golubev.com/gpuest.htm

Even older GPUs can manage tens of millions of guesses per second.

Re:Oblig xkcd

[Anonymous Coward]

Meanwhile, they let you rot in prison. Thats what key disclosure laws are about.

Know what happens next? More Snowedens, more Anonymous, and more fat guys simply killing police officers rather than letting themselves get arrested.

Followed up by additional guys showing up to shoot the police at the stand off in the back and then turning on politicians that hired them.

Somehow, I am not too worried about the disclosure laws going on very long. There'll be no pigs left to enforce them after a while.

Re:Oblig xkcd

[Anonymous Coward]

At 1 trillion guesses per second that would take approx. 3.2e80 years to bruteforce. 10^100 is *big*

Re: Oblig xkcd

[Anonymous Coward]

Depending on how many duplicate digit pairs are in your stack, your adversary could be looking at brute forcing 50! keys. Which could take some time...

Re:Oblig xkcd

[gurps_npc]

Torture is NOT effective at getting the truth.

It is pretty darn effective at getting people to talk.

Passwords however can be easily verified. As such, you can torture people to get a password, while you can not torture people to find out if they committed the crime.

Re:Oblig xkcd

[Anonymous Coward]

Meanwhile, they let you rot in prison. Thats what key disclosure laws are about.

Know what happens next? More Snowedens, more Anonymous, and more fat guys simply killing police officers rather than letting themselves get arrested.

Followed up by additional guys showing up to shoot the police at the stand off in the back and then turning on politicians that hired them.

Somehow, I am not too worried about the disclosure laws going on very long. There'll be no pigs left to enforce them after a while.

Getting into a shootout with the cops sounds like a great way to wind up in a body bag. Seriously they're good at what they do. They might be assholes and they might be mindless followers of authority but they are good at what they do. You won't last long against a SWAT team. Find a peaceful way to deal with this, like getting your politicians to write better laws.

Re:Oblig xkcd

[Kjella]

Actually if you "stick to the story" there's only 50 dollar bills to choose from and once chosen it's eliminated from the set so 50*49*48*.... = 3*10^64 combinations. Less if any of the bills have identical last digits, which is likely due to the birthday paradox. And if they were just counted and put in an evidence bag most the bills are in the right order. If they count the ones, either in order or reverse order and the only thing you need to figure out is where a few fivers or tens go that's cryptologically pathetically weak. And if it did disappear down some pocket, well there goes your evidence that there actually was a pile of cash making up your password. Worst, the police will probably take this as gloating on your part by showing off your perfect yet obviously constructed get-out-of-jail free card. I think the good old "I don't recall" works better.

Re:Oblig xkcd

[u38cg]

One can generate guesses at any rate, but it depends entirely on the encryption scheme how quickly you can test them. And I would point out that 10^100 is a little bit more entropy than a typical password of ~100^10 characters.

Re:Oblig xkcd

[u38cg]

There are 50! possible passwords formed by the bills, yes. I admit that this makes a massive difference to my analysis: now you're talking on the order of 10^53 years. Ramp it up to a trillion guesses a second and you're down to 10^44 years. As for the practicalities, it's not perfect, but it is at least plausible, and I struggle to see that you're going to prove that the pile is as-found.

Re: Oblig xkcd

[rioki]

In addition to this being a manual process. Brute forcing with automated systems is easy, but recording the endings and trying may actually take a while.

Re:Oblig xkcd

[u38cg]

Oh, and I would invite you to decide on what is a feasible number of guesses per second - let's say a million trillion (10^18). That would reduce the time taken to only 3.2e71 years. Which is, by the way, only a few jillion times longer than the current age of the universe.

Re:Oblig xkcd

[Anonymous Coward]

That's retarded.

Re:Oblig xkcd

[MrNiceguy_KS]

You are wrong about it being poorly implemented. The "encryption key" being printed on bills is the key here,
The acual password would naturally have nothing to do with the seriel numbers that would just make it needlessly complicated.

You could have only 45 bills and claim that originally there was 50. That would give you the chance to claim
corrupt investigators who ripped off the five $20 bills you had mixed in with your $1 bills. Not only
would it allow you to keep the password secret but also cast the investigating team in a bad light.
Tampering with the evidence and all that, the case might actually get thrown out of the court.

No one would steal your fortune cookies you know.

AC here actually gets the point of this method - you have plausible deniability - "I can't produce my password from memory because it was based on the pile of cash. A pile that is suspiciously smaller than it was before the raid."

Re:Oblig xkcd

[Dishevel]

Once you know that they are going to lock you up forever the police have kind of removed the disincentive to kill them.

Re:Oblig xkcd

[Anonymous Coward]

what about duress passwords.

it will give them data, but that data in itself is not very useful.

unless the police assume all data they get is a red herring and if they beat the perp some more, they will eventually get the real answer.

Re:Oblig xkcd

[MrNiceguy_KS]

Actually if you "stick to the story" there's only 50 dollar bills to choose from and once chosen it's eliminated from the set so 50*49*48*.... = 3*10^64 combinations. Less if any of the bills have identical last digits, which is likely due to the birthday paradox. And if they were just counted and put in an evidence bag most the bills are in the right order. If they count the ones, either in order or reverse order and the only thing you need to figure out is where a few fivers or tens go that's cryptologically pathetically weak. And if it did disappear down some pocket, well there goes your evidence that there actually was a pile of cash making up your password. Worst, the police will probably take this as gloating on your part by showing off your perfect yet obviously constructed get-out-of-jail free card. I think the good old "I don't recall" works better.

If the pile of cash disappears down some pocket, then when you are dragged to court to produce the password, you explain the password storage method to the judge, and the fact that no pile of cash was entered into evidence shows that evidence tampering occurred. Assuming you are in a legal jurisdiction where the rule of law holds any sway, this should get the case thrown out.

If you're in a jurisdiction where this doesn't apply, you're pretty much screwed anyway, (and it's all but guaranteed that your pile of cash disappeared into a pocket rather than the evidence locker.) Granted, in a no-rule-of-law jurisdiction, I'd recommend this method only for data you would literally rather die than give up. The Powers That Be aren't going to stop torturing you once you tell them about your password method, they'll keep torturing you hoping that you're lying and you really can produce the password if they push hard enough. At some point, you'll really wish you had a way to give them the password.

An obvious variation of this is to have a pile of cash that contains 48 bills, with a password constructed from the serials as described, plus something extra you have memorized and inserted in specific spots in the sequence. Then when dragged before the judge, you say that the password was from the serials of the 50 bills you had next to the computer. "What, there's only 48 now? Well, you can try the existing sequence and brute force the remaining digits, but since there are 2 bills missing, there's no way to know for certain where in the sequence to insert the missing digits for the brute force attempt, and since the stack was obviously tampered with, there's no guarantee that the remaining bills are in the original order."

Re:Oblig xkcd

[c6gunner]

Meanwhile, they let you rot in prison. Thats what key disclosure laws are about.

No, that's not how it works. Indefinite detention is a violation of human rights. No civilized nation will "hold you forever"; they still have to charge you with something. In most cases key disclosure laws allow charging you under existing obstruction statues, or provide for a specific jail term (eg. 2 years in the UK). And that charge still has to go through the courts, where you get due process and the chance to plead your case.

Re:Oblig xkcd

[cdrudge]

Tell that to H. Beatty Chadwick. He was jailed for 14 years for contempt of court for not handing over something he claimed he didn't have. He was never actually charged with committing a crime. While 14 years isn't holding you forever, I think many would still classify it as rotting away in prison.

Re:Oblig xkcd

[Anonymous Coward]

I'm not a lawyer, but I think that's pretty clear from recent cases that the judge would consider this destroying evidence.

Re:Oblig xkcd

[SuricouRaven]

The tools exist. The CSI fantasy crap is that you'll ever be on the recieving end, unless you manage to do something that threatens national security or run a criminal empire. But if they were going to be used, they'd be used in conjunction with the no-knock everyone GET ON THE FLOOR NOW! raid in an attempt to get everyone arrested before they can make a dive for the power cord.

Re:Oblig xkcd

[Jane Q. Public]

No, I didn't "miss" his point. MY point was that you can easily achieve exactly the same thing, without losing your data.

GP did mention that you can "claim" that was your system when you didn't actually use it. Fair enough... but also completely unnecessary. A set of cards with numbers on them is a lot cheaper than $100 bills.

Re:Oblig xkcd

[Jane Q. Public]

The tools exist. The CSI fantasy crap is that you'll ever be on the recieving end, unless you manage to do something that threatens national security or run a criminal empire.

They do exist, but apparently you don't understand how they work. GP is correct: the memory dump has to be made before the charge in the capacitors "leaks" away after shutdown. Researchers have managed to extend this period using supercooling ("freezing") techniques, but it still has to be done pretty much immediately. In your typical laptop: not a chance. You won't get one screw of the RAM cover off, much less all of them, by the time it's all gone.

Further, full-disk encryption (which everybody should use) defeats the old Firewire technique. No password, no access. End of story.

Further, you have been watching too much TV. "No-knock" warrants, while they have been issued too often in recent years, are supposed to be special-purpose only: for the rare circumstances when chance of flight, or injury to officers, is likely when they announce themselves. Preservation of evidence is not normally a valid justification for a no-knock warrant. In normal circumstances, they're supposed to knock on the door and READ you the warrant, during daylight no less, before you are obligated to let them in.

Not that I genuinely have anything to hide, but I have remote-controlled outlets. I can shut the power off with the press of a button, from anywhere in the house. I did not do that to protect my data, but I could use it that way if I wanted.

Re:Oblig xkcd

[kualla]

Ya you missed the point...

"Here, the law says they can't compel you to produce an encryption key, except under very particular, special circumstances."

SPECIAL CIRCUMSTANCES is a value of degree that is sadly becoming more and more vague to cover a large amount of people and I wouldn't be surprised if not now, eventually law enforcement will have enough ways to make that include every single person on this planet with their abusive framing tactics.

Imagine if your in China or South Korea, that method could be very useful or even corrupt cops or non-law-enforcement could still use torture on you. You could decide to take that wad and toss it up in the air or not. But at the same time, you could easily loose all your data if anything happened to that stack of bills, making that secret information gone at the cost of having such security system.

I wonder tho, if they beat the method out of you even with the stack of bills all out of order, could they do a combo brute force attack to crack the password??

Re:Oblig xkcd

[kualla]

That is what you would call Plausible Deny-ability I do belive :) Just like what truecrypt has, but this is the non-tech version. Knowing police today, you would get charged with something that amounts to nearly the same crime, like an obstruction of justice along with destruction of evidence, and what not else they have for their plan B when they want to screw someone over.

Re:Oblig xkcd

[c6gunner]

Contempt of court is a whole different animal, but I get your point. I'm surprised it went that long; guy must have had some shit lawyers. I'd have to read up on his case before commenting further.

Re: Oblig xkcd

[kualla]

It could become automated after simply entering the numbers into a password list to then create a combo list from... It would be interesting to calculate this out to see the strength if they can still torture your pw's system out of you. Maybe first bill first digit, second bill is second digit, and so on, maybe last 3 bills you do some math formula, etc.

Re:Oblig xkcd

[SuricouRaven]

The firewire technique is very good against full-disk encryption. If police find the computer turned on and encrypted disk mounted, that means the key must be in RAM. Compromise the RAM, the key will be in there somewhere. It has to be done on site, because the moment you turn the computer off to move it the key will be lost. I still stress that this isn't something that would be available for investigating run-of-the-mill criminals though. Maybe if you're suspected of running Silk Road.

Re:Oblig xkcd

[Jane Q. Public]

SPECIAL CIRCUMSTANCES is a value of degree that is sadly becoming more and more vague to cover a large amount of people and I wouldn't be surprised if not now, eventually law enforcement will have enough ways to make that include every single person on this planet with their abusive framing tactics.

No, it isn't. You don't know what the hell you're talking about.

Re:Oblig xkcd

[Jane Q. Public]

The firewire technique is very good against full-disk encryption. If police find the computer turned on and encrypted disk mounted, that means the key must be in RAM. Compromise the RAM, the key will be in there somewhere. It has to be done on site, because the moment you turn the computer off to move it the key will be lost. I still stress that this isn't something that would be available for investigating run-of-the-mill criminals though. Maybe if you're suspected of running Silk Road.

My whole point, from the beginning, was about turning the power off. So they won't find "the encrypted disk mounted".

Context.

Re:Oblig xkcd

[Anonymous Coward]

Piling fantasy on top of fantasy I see.

I love how guys like you keep adding fantasy to things to try and prop up what you are talking about.

Re:Oblig xkcd

[davydagger]

I have no idea.

but the point is, to force the cops to need a warrant, or the courts to need a subopena, where you have other methods fo defending yourself such as lawyers. We aren't trying to stop all police actions, just police abuse. One of the tell-tale signs is subversive activity, such as the cops not fully disclosing to the public, or even the government they report to the full extent of their activities, making it impossible for any true reform of the police.

When you have strong encryption, you make it harder for the police to be subversive, electronicly.

Re:Oblig xkcd

[davydagger]

When it comes to big scary unknown things like computer hacking, just about all bit of common decency goes out the window.

They held kevin mitnick without charge for a long time before letting him out. That was pre-9/11.

They just have to claim your an "enemy combatant", or some other class that no applying law applies too

Re:Oblig xkcd

[RockDoctor]

Would deleting/destroying your keys be considered destroying evidence?

That varies by jurisdiction. And, of course, if you've gone down the "hidden container route", then they've no way of knowing if you've given them the key to all the data.

You do have key management issues with lots of keys ratting around though.

Re:Oblig xkcd

[Anonymous Coward]

The point about methods like this is, you should actually do it, otherwise they will see, that you're lying, as they have more experience in such situations than you.

Re:Oblig xkcd

[Anonymous Coward]

They (bad cops) who still do this... mostly reserved for the marginalized who can't afford lawyers such as homeless, mentally ill.

Write much?

[superdave80]

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

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.

What's the license?

[Anonymous Psychopath]

The source still contains the original TrueCrypt license.

Re:What's the license?

[tepples]

They have to rewrite everything before they can change the license. Rewriting everything in LAME, for example, took a couple years.

Meh

[godel_56]

If he was going to change it why not go straight to scrypt, which is known to be resistant to GPU decryption?

Re:Meh

[gweihir]

Simple: scrypt is still not very good (linear speed-down for less memory), and there is currently a contest running for getting a better function https://password-hashing.net/

It would be stupid to change things at this time.

Give me a break

[fnj]

Nobody was ever going to brute force the original TrueCrypt.

Re:Give me a break

[gweihir]

With a bad passphrase? Easy! 1000 iterations only add about 10 bits, so passphrases up to something like 40 bits are well in reach for brute-forcing.

Conflicting info on licence and relation to TC

[ciaran2014]

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.

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:Conflicting info on licence and relation to TC

[mlts]

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.

Re:Conflicting info on licence and relation to TC

[ciaran2014]

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

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

[able1234au]

Plenty of innocent people in jail.

Re:You'll give them the password

[thegarbz]

If you don't give us the password and we have to crack the encryption ourselves

Yep I'll take those odds and plead the 5th.

Re:You'll give them the password

[Anonymous Coward]

Them: We'll crack it...$blahblahthreatthreatthreat
      You: Good luck. I can't remember the passphrase.

Re:You'll give them the password

[wiredlogic]

The mistake is letting them think there is something "in there".

"Those files are just a random collection of bits generated by Gnu Shred when the drive was formatted." is the correct response.

Re:You'll give them the password

[i.r.id10t]

Darn near 100% of 'em too, depending on how you do your polling....

Re:You'll give them the password

[Anonymous Coward]

No.
The only correct response is: "talk to my lawyer" or some variation of that.

Re:You'll give them the password

[Anonymous Coward]

not quite. depending on the court if you refuse to provide the password then you can be held in contempt and jailed indefinitely.

Re:You'll give them the password

[NormalVisual]

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

"Additionally, if you don't give us the password, you're going to sit in jail for contempt of court until you change your mind."

Re:You'll give them the password

[Anonymous Coward]

0% if you run the poll at a church

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.

Re:You'll give them the password

[Anonymous Coward]

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?

You will of course be kept in custody until the encryption is cracked or the heat death of the universe, whatever comes first.

Re:You'll give them the password

[SuricouRaven]

And go looking for more crimes to charge you with.

There is no such thing as an innocent person. Everyone, without exception, has committed crimes. Lots of crimes. The only difference between an innocent person and a criminal is that the criminal has done something serious enough to bother prosecuting.

Re:You'll give them the password

[AmiMoJo]

The problem is that there is always something they can get you with, something they can spin into a charge. The real question is will what they can spin without the password be easier to defend than what they can spin with a password, since either way you are going to be charged. At least with encryption you have a choice which bogus charges you want to face.

Re:You'll give them the password

[Anonymous Coward]

Plenty of innocent people in jail.

You can also go to jail for Contempt of Court, where you'll sit and rot until you give up your keys. So with that in mind, unless giving them up gets you either a Death sentence, or Life in a much worse facility, it's probably in your best interests to give them up.

Re:You'll give them the password

[Anonymous Coward]

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.

How on earth did all of this happen without her defense lawyer present?

Re:You'll give them the password

[Anonymous Coward]

I take it these prosecutors don't, as a matter of course, give their plea deal offers in writing? ;)

Re:You'll give them the password

[Anonymous Coward]

At least the time I went through the courts the plea was in writing, and until it was signed off on by the D.A. and the Judge I wasn't even asked to enter a plea.

Always have things in writing.

Re:You'll give them the password

[Anonymous Coward]

While I was pretty sure they could charge you with contempt, it doesn't look like it's a sure thing. At least one of the cases involved files that subsequently became encrypted when the device was turned off, so the police already had seen evidence that the dude had encrypted child pornography. But I don't think it's been entirely decided yet, so I wouldn't say a contempt of court charge would be unlikely. Depending upon what "secret info" you have, you might be far better off going through an appeal process, even if the initial judge doesn't consider encryption keys to be covered by the right against self-incrimination. (i.e. if you're a whistleblower, or you have encrypted evidence of serious drug or abuse crimes that would lead to many many years)

Re:You'll give them the password

[LordLimecat]

1) Dont be guilty.
2) Tell them to get a warrant
3) Profit.

For the record they need a warrant to get an image to crack, and its generally not feasible to do.

They just inflate the original sentence to a much worse sentence,

I get the record that only like 3 people on slashdot actually understands how the justice system works. You do know that the prosecution doesnt get to decide your sentence, regardless of what they tell you, right? You do know theyre not obligated to be your buddy, right?

Trite remarks are good for getting +5 mods, but dont be deceived-- theres nothing informative about your post.

Re:You'll give them the password

[Anonymous Coward]

And that's when you give them the password to the outer volume containing evidence of some rather disturbing but legal fantasies. Not the one for the hidden volume they don't know even exists, that you need not only a password but also a combination of multiple key files to open.

Re:You'll give them the password

[Boronx]

There's a difference between a written plea deal and the prosecutor bamboozling you in person.

Re:You'll give them the password

[Anonymous Coward]

And a whole lot who are guilty of breaking a law based on an a technical definition of the law, when a large majority of people would agree to nothing MORALLY wrong worthy of a punishment.

And then probably a ton more who are sitting locked up with punishments that most people find cruel and unusual punishment for such a crime. Think of marijuana users getting charged as a schedule 1 narcotic when the definition of what makes up a sch. 1 narcotic are widely know to be false for marijuana(defined as drugs with no currently accepted medical use and a high potential for abuse).

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:Nope not suspicious at all

[Anonymous Coward]

> Producing a chain of trust that a non-expert can trust is almost impossible.

Even a non-expert can see that this project is hosted on a Microsoft site. The same Microsoft that cooperated with every 3 letter agency known to man. As far as security and trustworthiness go this project is a joke right from the start.

Projects located in the US are too much of a risk. The fact that Microsoft has direct access to the project is about as hilariously absurd as Truecrypts "go use Bitlocker" message.

Re:Nope not suspicious at all

[Anonymous Coward]

But if it was a valid solution, this is exactly what a government agent would say to insight the tinfoil hat crowd to not trust a great product...

Re:Nope not suspicious at all

[oogoliegoogolie]

Someone has already given it a 5-star rating so you can put your suspicions to rest!

Re:Nope not suspicious at all

[Anonymous Coward]

"Projects located in the US are too much of a risk. "
Like the initial PGP release?

Re:Nope not suspicious at all

[Boronx]

Undoubtedly somebody much smarter than the low-rent cryptologists they hire at the NSA.

Re:Nope not suspicious at all

[Anonymous Coward]

> But, how to trust those other people?

Find somebody with a reputation to uphold. That doesn't immunize you against the "long con" where a guy has built a reputation intending to eventually use it to mislead about something important, but ultimately there is no such thing as 100% confidence. We just have to go with our own level of acceptable risk.

Re:Nope not suspicious at all

[Anonymous Coward]

Those were simpler times before secret courts and the NSA's infiltration of companies. With the crypto wars potentially making a comeback and the US surveillance apparatus out of control things look very differently.

Re:you can look up US case law on this

[snikulin]

What's about Somalia law?

Vera

[pushing-robot]

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

Re:Vera

[geminidomino]

Nicely played. :D

don't get it

[znrt]

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.

Re:don't get it

[Anonymous Coward]

This is 10x longer for EVERY guess at the password. So to brute force using a dictionary, every word you try takes 10x longer to hash than before. Which means if it used to take 1,000 years on average to brute force with all the computer power available to the NSA, then the update makes this 10,000 years instead.

Re:don't get it

[Anonymous Coward]

You're doing it wrong. It's trivial to set up PBKDF2-RIPEMD160 rainbow tables just as with any other encryption or hashing algorithm. You're still going to try decrypting the same root directory block with the IKs until you get back a valid block, at which time you can decrypt the whole volume with the IK and do a reverse lookup to get the original password as a bonus.

Re:don't get it

[gweihir]

The idea is that the user already has enough entropy in there that and a salted password, hence rainbow-tables are infeasible. Sure, they are still trivial to set-up, but cost and storage size does matter and may even make trivial things infeasible. The thing is though, that with a bad (low Entropy) passphrase, you can still brute-force it. And that effort is driven up.

Re:don't get it

[craigm4980]

You're doing it wrong. It's trivial to set up PBKDF2-RIPEMD160 rainbow tables just as with any other encryption or hashing algorithm. You're still going to try decrypting the same root directory block with the IKs until you get back a valid block, at which time you can decrypt the whole volume with the IK and do a reverse lookup to get the original password as a bonus.

Just use a salt, and that problem is solved. It forces you to incur the full cost for every different drive (making the tables useless). A reverse hash table for all possible 160 bit outputs wouldn't fit in the observable universe, so that's not a real threat.

Re:don't get it

[Anonymous Coward]

If the current brute force cost on the best computer (or network of computers) that can reasonable be expected to be built within my lifetime is ten years, a 10x cost increase would mean a lot to me.

But, more seriously, this is obviously just for publicity. There is no way anyone is even coming close to bruteforcing a TrueCrypt volume (with a decent password) anytime soon, so this improvement is obviously about as useful as translating the data to Navajo before encrypting it.

why use this instead of say dm-crypt?

[Anonymous Coward]

What is the benefit of using something like this over the standard OS encryption like dm-crypt, which can be chained with other block devices as well?

Not saying there aren't any, but my default position would be that the OS built-in encryption is more trustworthy, unless proven otherwise, and likely integrates better with the rest of the system. Plus seems like it has a better chance of being readable 20 years from now.

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.

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

[wiredlogic]

The benefit is cross platform support. It was Truecrypt's killer feature. TC is also just plain easier to set up than dmcrypt.

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

[SuricouRaven]

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

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

[AmiMoJo]

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.

Big Caveat: not a drop-in replacement forTrueCrypt

[Zanadou]

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.

Where is the .deb?

[pjbgravely]

It appears to be Microsoft windows only making it useless for my needs.

Re:Where is the .deb?

[Anonymous Coward]

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

Re:Where is the .deb?

[pjbgravely]

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.

Re:Where is the .deb?

[Anonymous Coward]

Highlighting on their main page = out of their way, hilarious.

Truecrypt is random thief proof

[Anonymous Coward]

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.

Re:Truecrypt is random thief proof

[tepples]

And most computers don't have Windows 8.1.

Which new major-brand laptop computers that aren't made by Apple come by default with anything other than Windows 8.1?

Re:Truecrypt is random thief proof

[Anonymous Coward]

When did the gp ever refer to *new* computers? All the AC said is that "most computer's don't have Windows 8.1," which with Win8.1 having under 10% market share (http://www.cnet.com/news/windows-8-1-continues-to-inch-along/) is a true statement, just like saying "most computers don't have linux."

Re:Truecrypt is random thief proof

[SuricouRaven]

Buy business. Just about all PCs/laptops aimed at business buyers come with Windows 7, because the number of businesses using Windows 8 is negligable.

Most business buyers will immediately wipe the system and install from their own site-licensed image anyway though, which does make the lack of blank systems seem a little suspicious. Doubtless Microsoft is offering some very sweet deals to OEMs if they'll refrain from selling OS-less computers.

Re:Truecrypt is random thief proof

[Anonymous Coward]

And most computers don't have Windows 8.1.

Which new major-brand laptop computers that aren't made by Apple come by default with anything other than Windows 8.1?

Specifically you need 8.1 Pro or Enterprise, for Vista & Win7 you need either Ultimate or Enterprise.
Most laptops (or even desktops) don't ship with the versions which contain Bitlocker, and if you want it that usually comes with a cost to 'upgrade' to the full OS version. So pretty much any way you look at it, BitLocker isn't free to obtain.

Re:Truecrypt is random thief proof

[crtreece]

I'm confused. Bitlocker is available starting with Windows 7, just not in all the consumer oriented releases. I'm not trying to suggest that Win7+bitlocker wouldn't be vulnerable to the problem of MicroSoft having the ability to decrypt the data, with suitable persuasion from a government, but just noting that MS does have encryption options available.

500,000 Iterations of Whirlpool.

[Anonymous Coward]

You unlock it by complaining about your ISP and Telstra. A lot.

Re:500,000 Iterations of Whirlpool.

[Anonymous Coward]

Most people here probably don't visit whingepool all that often mate.

Re:Just goto the codeplex site and verify the comm

[Anonymous Coward]

Useful for boatloader.

I've always wanted a boatloader.

I did the same!

[JoSch1337]

Instead of 1000 iterations of ROT13 I applied 655,331 iterations and I already feel much safer!!

Duh.

[Anonymous Coward]

OF COURSE making the entire process of mounting slower will make it harder to brute force.

wait, what?

[slashmydots]

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.

Re:wait, what?

[gweihir]

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.

Re:Big Caveat: not a drop-in replacement forTrueCr

[Anonymous Coward]

"VeraCrypt storage format is INCOMPATIBLE with TrueCrypt storage format."
---
Sure looks like it's there to me.
https://veracrypt.codeplex.com/

Re:Just goto the codeplex site and verify the comm

[mlts]

Cool, they have en_RN as a language choice, like in RedHat 5.x? (Not RHEL... RedHat.)

It depends. helps brute force-ish, only

[raymorris]

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.

Only relevant if you have a bad passphrase

[gweihir]

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.

Re:Only relevant if you have a bad passphrase

[Anonymous Coward]

Considering that these iterations don't improve the security of already-secure passwords, they always make me a bit fearful of using them. I know the algorithm is supposed to go like this:

key = hash(password + salt);
for (i = 0; i < 1000; i++) {
    key = hash(key + password + salt);
};

However, I always worry that they might be implemented by some moron who doesn't know what they're doing, and so they've instead implemented this:

key = hash(password + salt);
for (i = 0; i < 1000; i++) {
    key = hash(key);
};

And thus, all it's going to do is weaken the security of my password.

Re:Only relevant if you have a bad passphrase

[gweihir]

That is why you use, for example, PBKDF2 that goes even to a bit more effort than your first example to prevent convergence. However, while the key converges to half the bit-length of the hash used in your second version eventually (after a very, very large number of iterations, as this happens only by hash-collisions, and each of these costs you at most 1 bit), it does not otherwise weaken your password and the iteration effort is still added.

Nobody can do brute-forcing on the full key-space. What "brute-forcing" usually refers to these days is either reduced key-space (for example, 6 char password of only printable chars -- your second example leaves that behind after the 1st iteration, so the iteration cannot be bypassed) or "brute-forcing" with keys from a dictionary (again, the iteration cannot be bypassed). Also, putting in the salt once is already enough to cause potential rainbow-tables to explode in size and that is all the salt is good for. Yes, I know that is not the original definition, but actual brute-forcing becomes infeasible somewhere around 80 bits and the original definition is hence not really useful anymore.

So the second thing is not actually that bad, and it still does strengthen the password in practice.

Re:Only relevant if you have a bad passphrase

[Anonymous Coward]

I'd say the second example is quite bad. When I go through the trouble of memorizing a 128 bit password, I don't do so so that some dumbass algorithm designed to help out those who are too stupid to use a good password can whack off 64 of those bits in the process.

The whole idea to me stinks of the "color of the bike shed" problem. There are too many people who want to get involved in encryption but they're not smart enough to understand the math, so instead they invent garbage like these key strengthening algorithms instead. ...or it could be a secret NSA plot. Can't attack the encryption algorithms? Why not attack the way that the password is turned into a key in order to vastly reduce the number of possible keys instead? ...and what better way to get away with it than to do it in the name of increasing the security of poor passwords?

Re:Only relevant if you have a bad passphrase

[Anonymous Coward]

...or it could be a secret NSA plot.

That would explain the unusual choices for the number of iterations, 327,661 for one algorithm, 655,331 for another. Perhaps the NSA has determined that these specific counts lead to particularly easy-to-crack keys.

Re:Only relevant if you have a bad passphrase

[gweihir]

You are very right on the "bike shed". And of course, not using something like PBKDF2 that cryptographers have looked at is a sign of incompetence. I am just pointing out that no "knocking off 64 bits" will happen in practice, so the thing to worry about is developer incompetence, not concrete weakening of your input, because:

1. First, it converges to half the bits of the hash output, not half the bits of what you put in there. For RIPMED160 that means it converges to 80 bits. That is still far, far too large for doing a rainbow-table approach.

2. When I said, "very long time", I meant it. For an 160 bit hash, the probability of a collision (and that is the convergence mechanism) is very, very low. Admittedly, I am too lazy to calculate it, but fortunately, somebody else has done it before: http://preshing.com/20110504/h... (there may be defects in the hash that increase this rate, but not to any significant degree for this application). With that we get that we need 1.42*10^24 hashes for a 50% chance at a collision. Now, a collision costs you one bit (two instead of one passwords can have the same hash). And now I will estimate: Say, on average you lose 1 bit of entropy every 10^24 iterations. These hash algorithms do about 500'000 iterations per second, but lets give them 1'000'000 per second. That means you can do 10^6 per second and hence 10^18 seconds if dumb hash iterations cost you one bit. 10^18 seconds are 30 Million years. Hence the convergence issue is a theoretical one, not a practical one.

Re:Only relevant if you have a bad passphrase

[gweihir]

Actually, my guess would be that somebody installed it and and got these as result of a timed iteration. Depending on CPU, these could be 1 and 2 seconds of hashing, which is what you do, not a fixed count. Otherwise you may end up with extreme unlock-times when doing this on a slow CPU. Good documentation will warn you about this and you may want to increase iteration time on a slow CPU (or not), depending on the threat-model.

More iterations allows shorter passwords.

[craigm4980]

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.

Re:Just goto the codeplex site and verify the comm

[Anonymous Coward]

Useful for boatloader.

I've always wanted a boatloader.

Good news for you, then! They added a boatloader to systemD. Now *everyone* has to have it as a mandatory component, and if anything goes wrong with it your entire system will come to its knees.

It's like Windows 95 all over again!

Re:Big Caveat: not a drop-in replacement forTrueCr

[gweihir]

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.

wait, what?

[craigm4980]

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.

"Slightly slower"?

[heypete]

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.

Re:"Slightly slower"?

[Virtucon]

The sad part really is that I don't think that going through that many iterations is going to anything but drive people away because of the performance impact. While I know RIPEMD160 is considered strong I don't think it's stronger than Keccak which is the SHA-3 winner.

Only if they give you immunity.

[Uberbah]

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

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.

Re:Only if they give you immunity.

[samjam]

There is a point that you have to accept that you are not in control of the situation; when there is nothing you can do,

The poor sister didn't want to believe that there was nothing she could do and so she accepted the lie that there was something she could do to make it better.

And so she spoke when she should have been silent.

Re:you can look up US case law on this

[Lumpy]

You must fire your ak47 above your head sideways for the greatest accuracy. That is Somalia Law.

Re:Just goto the codeplex site and verify the comm

[gbjbaanb]

boatloader beer, of course.

....yes,,..

[sjwt]

yesyesyes, but can it stop the cops reading the sticky notes that ppl use to write down there passwords :P

Re:Big Caveat: not a drop-in replacement forTrueCr

[Anonymous Coward]

That's not a huge problem, assuming you trust VeraCrypt and "know" that your hardware isn't compromised. You'd still be taking a risk anytime you opened the container, so migrating to a new format is more of a headache than anything. I don't know if I can trust VeraCrypt yet, though.

NOPE

[Anonymous Coward]

Sorry, but Truecrypt creators indicated it should not be trusted, so that is the way it will stay in my book.

Not only iterations count

[LakerTone]

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?