Questions about Truecrypt

Hello everyone.

I have some questions about Truecrypt.

1. People say that Serpent is 'slower' than Rijndael. Do they mean that it is slower to initiallly encrypt a drive with Serpent, or that if I use Serpent for system encryption the general performance of my computer will be degraded?

2. Let's say the NSA was after me. How much more secure would it be to use cascaded encryption? I mean, if I only use one password, don't they still only have a single password to crack? Why bother with multiple ciphers?

3. Any information regarding UK key disclosure laws would be much appreciated.

 

2 and 3:
You probably want a hidden truecrypt volume. You don't have to give a password for something that doesn't exist (or does it )

 

While trying not to get too technical the Serpent cipher performs more rounds than Rijndael, this means the cipher has a larger security margin. You could argue Serpent has some clear crypto advantages over the AES winner though speed performance is why Rijndael was picked for AES. Yes if you use Serpent on a low powered machine you will notice a performance hit. TC allows you to benchmark the different ciphers on your system to give you a general idea of the speeds you would be getting with the encrypt/decrypt process. With any encryption setup it comes down to implementation and both ciphers are very strong if properly implemented. In summary AES/Rijndael is faster, Serpent is slower but has advantages if you are willing to sacrifice performance.

If you are attracting the attention of the NSA, proper encryption implementation is the least of your worries. That being said I would recommend sticking with a single primitive. My reasoning goes back to my remark on implementation. Encryption is only as strong as how it’s implemented and adding a cascading cipher increases the chance of a cryptographic attack. Does this mean cascade is inherently broken? No it doesn’t, and if you trust TC to implement it properly and can justify the performance trade off then it can’t hurt to use. Though it is still a question as to how much value a cascade of 3 or more block ciphers really adds to security.

The Regulation of Investigatory Powers Act 2000 (RIPA), requires persons to supply decrypted information and/or keys to government representatives. Failure to disclose carries a maximum penalty of two years in jail. And it does seem to be enforced

 

Security margins are an interesting way to add some conservative cushioning to a design, but they're a tricky metric to work with. During a round, a block cipher's round function is applied; the idea is that after a certain number of rounds, you achieve all of the strong properties that you want from your design. However, you have to keep in mind that different block ciphers have different round functions, and if you assume that a block cipher with 50 rounds has a 25-round security margin advantage over a block cipher with 25 rounds, you're implying that both block ciphers' round functions are comparable, which is certainly not always the case.

For example, I've seen 10-round block ciphers for which the best attacks have only covered 6 rounds, after quite some time; in contrast, and in the same amount of time, I've seen 32-round block ciphers for which attacks on 30 rounds have been found. Before such cryptanalysis, you might have concluded that you have a larger safety net with 32 rounds than you do with 10; it's hard to predict these kinds of things. This isn't an argument against Serpent, of course; it's built like a tank. On the other hand, I wouldn't consider this an argument against the AES, either. Then again, future attacks may teach us all something.

I agree with regards to the NSA; while they do cryptanalysis well, they're well-versed in other techniques that make getting at your data much, much easier. I'll post more about my thoughts on multiple encryption and cascades in the other post dedicated to it, but I'll add that cascades, because they involve more cryptographic fiddling than a single primitive, obviously introduce more code; it's my line of thinking that we shouldn't burden programmers with design decisions that offer little in practice. They're more likely to get the code wrong than someone is to break a single primitive because you didn't use cascades -- magnitudes more likely, at that.

We do know that "three" is the magic number when using cascades, but it's still an open question as to what four or more will achieve. When I say "three" is the magic number, I simply mean that it's not until then that you see a significant increase in security; when you get to four, however, the results aren't a whole lot different than for three.

 

Benchmark



AES Encryption / Decryption 2,4 GB/s

Serpent Encryption / Decryption 232 MB/s

Intel Core i7 with AES-NI here.

http://en.wikipedia.org/wiki/AES_instruction_set

http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni/

http://www.truecrypt.org/docs/?s=hardware-acceleration

They mean both the encryption process for a TrueCrypt volume and system partition. "TrueCrypt does not use any of the AES-NI instructions that perform key generation."

But in general they mean support for hardware-accelerated AES encryption.


It depends on your HDD - is it a new SSD or a old magnetic storage?

The SATA 3 GB/s and 6 GB/s SSD drives (find out what your mainboard chip support) can do a read performance of around 285 MB/s (3 GB/s) up to around 550MB/s (6 GB/s). SSD combined with AES plus AES-NI and you have no single bit speed loss. With Serpent and a SSD SATA 6 GB/s you will feel a speed loss. If you have an old magnetic storage with maximum 80 - 120 MB/s then you have also no speed loss with Serpent.

 

There is also the 'fast enough' scenario. Sure, AES may be the fastest, but if you choose Serpent...and all the stuff you do on your box operates satisfactorily for you...does it matter? I've got a two cipher cascade container operating on a spinning disk, but the programs that are run out of it work perfectly and 'fast enough'. I realize that container .vs full disk encryption is a little different story, but hey, it'll only be a few hours of your time to try them all and pick the best option that is 'fast enough'. I'm leery of the hardware acceleration chips...I have visions of CryptoAG dancing in my head Software encode/decode is 'fast enough', for *me*.

PD