Truecrypt defeats FBI

[Eóin]

Here's an interesting article I've read over at The Register about a Brazilian banker.

Putting particular case aside, I don't actually take much joy in seeing a crooked financial businessman getting away with crime. What interests me is how much this speaks for the credibility of Truecrypt. For starters it pretty much cements the fact that there is no backdoor in the program. Now admittedly being opensource such a door would be hard to find but nonetheless this is most reassuring.

It's also a testament to the quality and robustness of the cryptography within Truecrypt as often when security like this is compromised it's down to bad implementation and not weaknesses in the algorithms

[Josh]

The thing with this article is that Truecrypt "And an unnamed security product" defeated the FBI. Plus, I guarantee there is more to this story.

[Eóin]

Well it says an 'unnamed algorithm' rather than another program. Truecrypt offers a number alternative encryption algorithms as well as cascaded combinations.

Obviously one can't be sure but I'd sooner guess that it was simply one of those, after all rolling your own crypto algorithm is never a good idea.

[Deozaan]

It's also a good thing (for the banker) that he used a strong password. TrueCrypt alone won't help if your password sucks.

[40hz]

Hmm...

One old technique is to intentionally corrupt the encrypted file in a reversible manner. All you need to do is open the encrypted file in a hex editor, change one or more bytes using some arbitrary schema, and save it.

Example: After encrypting, add 1 to the first byte in the first three rows.

Original file



After encryption


After editing hex values


Until these changes are reversed, the file cannot be decrypted even if the password and encryption method are known. Since encryption algorithms depend on every byte in the encrypted file being correct, any change anywhere in the file makes decryption impossible. And because the changes made are completely arbitrary, they don't readily yield to cryptographic analysis and cracking techniques.

Note that many encryption software products also add headers and CRC checksums to their output files, so it's important to test the "corrupted" file to make sure the encryption utility can't repair it. The goal is to have decryption produce gibberish or no output rather than report a file error - which is a dead giveaway that the encrypted file had been tampered with.

Encrypting the same file twice, using two different algorithms and passwords (or even using the same algorithm and password) can also make cracking the file virtually impossible.

And any encryption system that utilizes a properly implemented One-Time Pad technique is still completely unbreakable using analytic methods.

At least according to all the information that is publicly available.    

[Eóin]

I didn't know about that 'purposely corrupting some bytes' trick. But wouldn't you be better off putting that effort into remembering an even stronger password? Seems to me like changing some bytes is like an extension to the password.

Also a question about the effect on the data? I know RSA and probably those like it would succumb to any changed bytes, but wouldn't the like of AES decrypt up to the corrupted portion more or less correctly? Thinking about it, if there is more than one pass over the data then no you probably wouldn't be able to recover anything.

Also - Bruce Schneier says meh to one-time pads

• Bruce found a secure way to reuse a one-time pad.
• Bruce Schneier can crack a one-time pad before it's used.
• At college, Bruce Schneier had his way with so many women that his dorm room was called "The One-Time Pad.".

-http://www.schneierfacts.com/

[Crush]

40hz: An additional encryption-locker would be an interesting idea for some kind of NANY...

[mwb1100]

And any encryption system that utilizes a properly implemented One-Time Pad technique is still completely unbreakable using analytic methods.

-40hz (June 28, 2010, 02:29 PM)

The problem is that there are very few properly implemented one time pad systems, and certainly none for general purpose desktop use. To properly implement it you need a random key that's as long as what you're encrypting, and you can use the key only once (that's what it's a "one time" pad). And a computer's pseudo-random number generator isn't really good enough to generate the keys.

The advantage of the one time pad is that it's provable secure (if you adhere to the requirements) - any output message is just as likely as any other, so there's no way for an attacker to know if they've 'cracked' the right message.

The problem with one time pad is key management - storing the key securely is as much a problem as storing the data you want secured. Add to that the problem of creating the key properly.  When used incorrectly (if you don't produce, secure and use the key properly), the one-time pad is probably about the easiest encryption scheme to break.

So one time pads are generally only useful for short messages between 2 parties, no so much for storing data securely (since you have to store the key securely as well).

So anyone looking at encryption software that claims to use one-time pad would be wise to steer clear.

[40hz]

@mwb1100 - All good points, although since there are many publicly available resources for obtaining true random numbers, that part isn't really a problem.

Note: I'm not advocating one-time pad cryptography. It's basically unworkable for anything other than short messages, as you pointed out. I was just mentioning it as the one cryptographic system that is mathematically known to be 100% unbreakable if implemented properly. At least as far as our current mathematics can determine.

40hz: An additional encryption-locker would be an interesting idea for some kind of NANY...

-Crush (June 28, 2010, 04:01 PM)

Would be. If I could code worth a penny, I might be tempted to try writing something like that. Unfortunately, many things have taught me that application coding is not where my talents lie. 

[Crush]

40hz: I´ll do it. Tell me your wishes for such a program.
mwb1100: I made a file-encryptor with implemented OTP that has a hardware radioactivity as a source for pure randomness: Crush Cryptonizer

[lanux128]

The files were encrypted using Truecrypt and an unnamed algorithm, reportedly based on the 256-bit AES standard. In the UK, Dantas would be compelled to reveal his passphrase under threat of imprisonment, but no such law exists in Brazil.

a probable fallout from this case will be a change in the Brazilian method of extracting information.

[40hz]

40hz: I´ll do it. Tell me your wishes for such a program.
mwb1100: I made a file-encryptor with implemented OTP that has a hardware radioactivity as a source for pure randomness: Crush Cryptonizer

-Crush (June 28, 2010, 07:32 PM)

Not trying to make work for you, but if you're looking for a NANY project here goes...

Tell me if this makes any sense:

The biggest problem with most people is their passwords. They're too short, too simple, and lack sufficient randomness.

What if there were an encryption package that took a relatively easy to remember password and used that as a seed to produce a very complex, very long password that got used to do the actual encryption?

That way, you could know your file was encrypted using AES or Blowfish or whatever; and you could know that the password you used to do the encryption was something like  i<399ntyRNs. ("I love 99 naughty nurses!") - but what you wouldn't know is the real password used for the encryption because the app used your i<399ntyRNs to generate something like this to do the actual encryption:

9frB&SNSYWlbN?TRZ+X6M&s)Sxt;2}wSL6OhAUG,`B&P|[.-O^*m%R`%JM7An`:
ge?NP2:t'%KM_Ih'!<$n+'5FnvVPGg\amea~I3,(-M~gC0;&fw:ejL3(,GJt`t<
4~B'>#4[IRb4G=)#b5o<NR)gQp=_/0QqZV~mOawt|%.HEEA=-@PLoS[CI;1?}C"
cUU+xoO0!>/wqq`VhY/H81?)`TgXLq''YCq{Zl?1BX|fAyo6X:(Kq;$-_q':<7%

It might also be cool to use the user password in conjunction with something like the filename for the seed so that each generated password would be different for each file, even though the same user password got repeatedly used.

So now, the 'real' password for FILE01.TXT would be totally different than that for FILE02.TXT - despite user password: i<399ntyRNs being the same on both.

This offers three advantages:

1. The file is encrypted using a highly long and complex password that has a good degree of randomness. And even though it's not genuinely random, it's still more random than most people could come up with. (Our minds are so full of subconscious associations that it's next to impossible for us to be random.) Now those 256 or 512+ character passwords become viable even though the user doesn't know what they are or ever have to remember them.

2. In order to decrypt the file, you'd also need to use the same app that generated the complex password. So having the file and knowing what the encryption algorithm and user password was wouldn't help you decode it unless you knew the internally used password - or knew how to generate it.

3. Each generated password is different for each differently named file even if the same user selected password gets used repeatedly because the file name is also part of the seed. So now there's less of an issue reusing an easily remembered user password so long as each filename is different.

Note: rather than screw around with a hex editor and binaries, you could get a similar result by manually renaming the file after encryption. Since the name is part of the seed, doing something as simple as adding a digit to the end of the file name (i.e. FILE123 becomes FILE1230) would break decryption even if you had the app and the user selected password.

Sorry... it's late, I'm exhausted - and I'm probably rambling and repeating myself by now...

[Crush]

What if there were an encryption package that took a relatively easy to remember password and used that as a seed to produce a very complex, very long password that got used to do the actual encryption?
-> Crush Cryptonizer does it
It might also be cool to use the user password in conjunction with something like the filename for the seed so that each generated password would be different for each file, even though the same user  password got repeatedly used.
-> Crush Cryptonizer doesn´t uses the filename, but random salt is generated or can be loaded by a hardware random number generator. I started Crytonizer 2.0 that also can handle hardware informations for encoding/decoding and I´ll also include the destination filename.
The One Time Pad can be used to generate a very long filename - it uses the complete content of a selected file in full length. In Cryptonizer 2.0 it will be combined with the password.

[Eóin]

In order to decrypt the file, you'd also need to use the same app that generated the complex password. So having the file and knowing what the encryption algorithm and user password was wouldn't help you decode it unless you knew the internally used password - or knew how to generate it.

-40hz (June 29, 2010, 01:17 AM)

My question would be, how likely is it that someone would know how to generate your password? A good security system is one that can stand up to an attack even if every detail of it's implementation is known by the attacker.

[Crush]

I have a new idea how to make passwords for encryption more secure: http://www.youtube.c.../watch?v=YzVZbgpHJYg
Even if others know it they cannot login if they are not you!

[Eóin]

I'd heard of that before. If it works then it's quite cool. But I wonder of tolerant or intolerant it really is? I also wonder how well it'd work in the real world. Wouldn't different keyboard affect your typing profile? How about if you're sluggish from a flu or hangover? Can you still access you're account then?

[Crush]

I don´t think so. Doing such an analysis shouldn´t be too complicate. I´ll start some tests.

[CWuestefeld]

I may be misunderstanding something -- I'm not an expert on cryptography. But from what I understand, I believe that

Since encryption algorithms depend on every byte in the encrypted file being correct, any change anywhere in the file makes decryption impossible.

-40hz (June 28, 2010, 02:29 PM)

Is not true. I believe that the cypher's block size describes chunks of data for which this is true, but corrupting one block won't affect the decryption of the others.

Indeed, something at least similar to this must be true for SSL to work: you can decrypt the beginning of the stream without knowing the end (since it hasn't been received yet), and a transmission error early on doesn't force the connection to be discarded and reestablished because it's become corrupt.

However, trashing the header of your truecrypt archive may make it so that truecrypt is unable to open and mount the file.

That said, it still doesn't ensure your security in the most extreme conditions. Just because TC itself can't open it doesn't mean that the spooks can't accomplish the same thing. If they can access every other block successfully, then what they've got probably looks like a (virtual) disk with a corrupt MBR, which isn't going to be too much of an impediment.

Really, what you're proposing is only a simple additional layer of security that, once the bad guys discover, offers you no protection at all. Your accomplice could rat you out and you'd never know it. You could probably more easily achieve the same effect just by storing your data in some non-traditional way (say, using SoftMaker or KingSoft native file formats rather than Microsoft's), so that the bad guys don't recognize it. It's not much protection, but makes it a bit harder for them.

[mwb1100]

What if there were an encryption package that took a relatively easy to remember password and used that as a seed to produce a very complex, very long password that got used to do the actual encryption?

-40hz (June 29, 2010, 01:17 AM)

I believe that most crypto packages do something along these lines by running your password through a hash algorithm (like SHA or MD5 or similar) and use the hash as the key to the cipher.  Serious crypto packages will combine the password with a random 'salt' value before performing the hash so that the same password being used for different objects or sessions will generate a different set of key bits for the cipher.

None of this helps with 'guessable' passwords, but it does help map the entropy of the password to the number of bits used in a cipher's key and the salt value helps prevent detecting that a password is being used more than once (for example, if a file is encrypted with the same password, but using different salt values, the resulting encrypted files will be completely different).

I'm certain that truecrypt performs the hash operation, and I believe that it also salts the password, but there are probably modes or configurations where it doesn't or can't because the salt has to be stored somewhere so it can retrieve it and use it to recreate the hash when you type in the password to decrypt a volume. There might be situations where that's not acceptable for some reason.

[Eóin]

CWuestefeld - I think there is a stage input from one block to the next, so a corrupted byte in one block would probably also corrupt the blocks that follow it. At least that's the SSL approach I believe. Truecrypt supports random access so probably does thing differently.

mwb1100 - The salt isn't added to the password, otherwise the same password would have numerous key associated with it and you couldn't decrypt anything. The salt is added to the data to be encrypted. That way the same key and same data look different after encryption. When you decrypt the cipher you simply ignore the salt bits.

I should stress I don't really know what I'm talking about here, just recounting what little bits of info I've collected over the years.

[mwb1100]

The salt isn't added to the password, otherwise the same password would have numerous key associated with it and you couldn't decrypt anything. The salt is added to the data to be encrypted. That way the same key and same data look different after encryption. When you decrypt the cipher you simply ignore the salt bits.

-Eóin (June 29, 2010, 12:23 PM)

That's one way to do it, another way is to add the salt to the password before hashing it and to store the salt in some sort of header (or somewhere else retrievable) so the operation can be reproduced when it's time to decrypt. The salt is just random bits and is not considered a secret, so storing it doesn't detract from the security of the cipher.  I know that this is the way that password authentication schemes generally work, but truecrypt and other data encryption schemes might very well handle the salt as you described.

[joby_toss]

How about a password card?

[Deozaan]

How about a password card?

-joby_toss (June 29, 2010, 01:28 PM)

Cool! There's an Android app for that!

EDIT: By the way, for anyone else who might have trouble like I did understanding how to use the password card: I found it a bit difficult to follow how to use it while reading all the paragraphs meant to explain how to use it. The bulleted list of instructions, on the other hand, cleared things right up.

Basically you decide before hand that all your passwords are going to be a certain number of characters (I'll say 10 for my example) and will read along the card in a specific direction (I'll say diagonally down and left for my example). Then all you have to do for each place you have a password is remember a color and a symbol. Then, using my examples, you start at whatever character is located at that point and use each of the 10 characters diagonally down and left for your password.

One thing I didn't notice right away was that the placement of the symbols at the top are different for each card. So not only are all the characters in different places, but even the symbols at the top are randomized.

[f0dder]

Eóin: salts are prefixed to your passphrase, to make brute-forcing slower, thwart rainbow-table attacks, and make hashes of identical passwords different. Making samedata+samekey look different is handled by an Initialization Vector (nonsecret, just as salt is).

40hz: as others have mentioned, changing a few bytes won't corrupt the entire encrypted data stream... depending on the encryption mode employed. For ECB mode, you ruin up to the Cipher's block size (128 bits for AES), for CBC mode you ruin more... potentially the whole stream, but systems supporting random access (like TrueCrypt) cuts the stream into chunks - so you only ruin a single chunk. TC doesn't use CBC mode, btw, but XTS - which I know nothing about. Also, I ran into a paper about error propagation in CBC mode a while ago, and it turns out it's not as effective as you might think; don't have an URL handy, I'll let somebody with better google-fu hunt it down