Truecrypt 5.0 Release Date Set - FEBRUARY 4th

No need.

Using code-based game-playing techniques, we have provable results that show cascades composed of at least three block ciphers, with three independent keys, to be the minimum, for a significant gain in security. Triple encryption increases security (significantly) in a way that double encryption cannot (negligibly); triple encryption is the shortest potentially "good" cascade, in this sense. Furthermore, we're not sure if security increases when you increase the number of block ciphers in a cascade beyond four.

Triple encryption is the "sweet spot," if you will, but, as I've said many times, the added complexity of implementing a cascade just isn't warranted, compared to what it gives you, and the implementation risks that come along with it. Either way, if you want to take advantage of the security that cascades are meant to provide, you should be using at least three independently keyed block ciphers. However, fiddling with multiple block ciphers is more likely to cause problems, than provide any noticeable security gain.

At least, that's the trend I've noticed in practice. So, in short, I don't recommend using a cascade of AES, Twofish, and Serpent; it's not that I think it's insecure, though. It very well may be the case that TrueCrypt's cascade implementations are secure; in that case, given what we know about cascades, a cascade of three independently keyed block ciphers should offer a significant gain in security over that of single and double encryption.

I don't want consumers thinking they need to use them and I don't want software vendors thinking they need to implement them. The reality is that the AES is sufficient, and a conservative recommendation for both security reasons (i.e., it receives more cryptanalysis than any other block cipher) and engineering reasons (i.e., it's simple to recycle for encryption, authentication, and a PRF). The latter reason takes advantage of the former reason.

Refer to this post of mine for more, including references to opinions by David Wagner (co-designer of Twofish) and Ross Anderson (co-designer of Serpent), both supporting the use of the AES, over Twofish or Serpent, whenever possible. Cheers!

 

It is like TrueCrypt gets a wrong value from the Bios, when in ahci or another sata-modus or raid, so it thinks that there isn't enough memory.

an I found this:

On some systems, when performing the system encryption pretest, the TrueCrypt Boot Loader reports the following error: Insufficient memory for encryption. This issue will be addressed in the next version of TrueCrypt.

see here: http://www.truecrypt.org/docs/issues-and-limitations.php

 

It's possible that the bios uses extra memory in those modes.

Either way the solution i suppose is to make the bootloader smaller somehow, which they could in fact do.

 

awesome, thx for the news Mich. looks lik my bug report (and whoever else submitted 1) worked! they acknowledged & posted the problem in less than 1 day, what company will do that for you? thats why everybody loves the TC Dev's.

 

The size is not the issue, i have had beautiful GUI based boot loaders before, for different encryption, and boot managers etc. I think its a bug with the handling of the systems memory, not a problem with the memory or the size of the loader.

 

CDburnerXP (the most popular freeware burner) cannot burn the ISO's giving the message "this is not a valid ISO file" just like PowerISO couldnt mount it with the same message. luckily Nero can burn it for me.

i know the TC devs are reading this thread, i have never had a problem mounting or burning ISO's before. if you guys have altered the ISO in order to prevent people form mounting it (which now is even effecting burning it) please rectify the issue. if it's just a bug hopefully it will be addressed.

it would be nice if people would list the apps they are using for mounting/burning & if it worked or not. it might help the TC Dev's figure out whats wrong. so far for me...

Nero 6 - burned successfully (didnt try mounting with it)
PowerISO 3.8 - couldnt mount
CDburnerXP 4 - couldnt burn

about to try Nero 8 for mounting (or burning if mounting doesnt work)

 

I'm wondering if their goal was to prevent people from mounting it, for if it was, why not have TC burn it instead of creating an ISO? I'm sure there would be a way. Personally, I'm glad for the ISO, since I tested using VMWare, and definitely did not want or need to burn a disk.

VMWare v6 - Mounted into system OK, TrueCrypt recognized it as a valid recovery disk.
Nero 7 DriveImage (v3.0.0.12) - Mounted, however Windows reported it as a bad format or corrupted disk.
Nero Burning ROM v7 (v7.10.1.0) - Burned Image to a new image OK.
IZArc v3.7 - Opened image, but didn't show any file structure.

 

Eli997:

I was able to burn the iso using BurnAware Free Edition, available here:
http://www.glorylogic.com/

 

Base Memory 631 was my number when I ran the program they asked to be ran. What did you guys get?

 

for everybody having the "insufficient memory for encryption" message here is your chance to help the TC Devs. they have updated the docs "issues & limitations" section with instructions

http://www.truecrypt.org/docs/?s=issues-and-limitations

 

From reading the issues page, it appears the problem lies in how much memory the bios makes available to truecrypt when the processor is in real mode.

Likely not something that can be worked around easily without making the bootloader smaller. Anyone who has this issue definitely download that ISO and report its findings to the developers.

http://www.truecrypt.org/special-downloads/BootMemoryTest.zip

 

I was able to burn the ISO successfully, but only after using the software recommended by TrueCrypt (ImgBurn worked as well). All of the commercial CD burners I tried only made me a shiny set of coasters. However, even with InfraRecorder and ISORecorder I could not successfully boot off of the disk. I tried many iterations of burning options and with different machines (SATA, IDE), but no luck. I was able to mount and boot off the ISO in VMware 6. However, I could not get a physical Rescue CD to boot a physical machine.

Has anyone successfully booted a Rescue Boot disk outside of VMware?

 

I booted the Rescue CD without a problem.

 

ImgBurn - burned successfully
Daemon tools 3.47 - mounted successfully

Both of the above have yet to fail me in anything to date.
Why do so many people use Nero for burning images? It seems like there is nothing but problems with it... though it worked in your case. And isn't PowerISO designed more for editing and creating images?

 

anybody boot from a True Image/Norton Ghost CD & make an "image" of their C: yet? that way your image is still completely encrypted. then try restoring back?

i am ganna try eventually, problem is though if it doesnt work you have to reinstall.

there are other methods like, some people create images from a running OS which creates an unencrypted image but then store it inside of a TC container.

results will vary depending on the WDE program, imaging program, and method used. i had varying degree's of success with PGP WDE.

 

another bug, a big 1!!!

i can no longer mount volumes over my internal network, i keep getting error messages.


computer A: home server with closed TC file container

computer B: laptop connecting to server via wifi trying to mount file container locally on laptop

 

Hello,

From http://www.truecrypt.org/docs/?s=issues-and-limitations :

Regards,
gkweb.

 

The Truecrypt forums are finally up!

 

Did you have to do anything special in terms of settings to burn? What software did you use? CD or DVD? Obviously, the TC group have done something "extra" to the ISO that makes a lot of the burning and mounting software unable to read the *.iso file. Workaround or specifics would be much appreciated.

 

I used InfraRecorder to burn the TC rescue disc, just used the default settings.

 

Thanks reparsed.

I've traced it to an incompatibility with Dell laptops. I took some of the disks I made yesterday and successfully booted an old HP laptop. So, there must be something breaking between the odd file-system format of the TrueCrypt rescue disk and the Dell CD readers (tested on D600 through D630 with none able to boot.) Unfortunately, there are no BIOS settings to manipulate a CD reader.

Tried to copy the CD contents via Linux, in the hopes of getting a bootable USB flash, but Linux did not see the FS as standard either.

 

Re: No need.

In which way triple cascade is far more secure than double?

I believed that cascades were implemented in case of a vulnerability were discovered in one of the algorithms and to avoid patterns by encrypting pseudo random datas...


Looking forward for your reply,

tx

 

Cascades and such.

A double cipher's effective key length is essentially no more than that of a single cipher, since the upper bound on the advantage hits one (i.e., meet-in-the-middle attack), for the double cipher, at the same point it does for the single cipher (i.e., exhaustive search). To be fair, that doesn't say all there is to say about the security of a double cipher. Rather, we can say that its security, in the Shannon model, is increased. In other words, the success probability of an adversary is much lower in the case of a double cipher than with a single cipher (i.e., it would require more queries to gain the same advantage). All in all, though, the meet-in-the-middle attack severely limits the gain; while you gain something, it is negligible. (By negligible, I mean half a bit of security for an advantage 0.5.)

Take DES, for example. First, we model the block cipher as a family of random permutations - one for each key. The adversary gets oracle access to the block cipher and its inverse. The adversary's job is to distinguish the cascade and its inverse from a random permutation and its inverse, roughly. If the adversary wants an advantage 0.5, he'll have to ask $2^{50}$ queries, $2^{55.5}$ queries, and $2^{78.5}$ queries, for single, double, and triple encryption, respectively. You might notice that the gap between single encryption and double encryption is relatively small, while the gap between double encryption and triple encryption is significantly larger. As such, to approach the security you would expect from a composition of multiple ciphers, the minimum is three; it provides the security that one might naively expect from double encryption. Four has been shown to be no worse than three, regarding maximal advantage, but, to the best of my knowledge, we still don't know if adding more ciphers, beyond three, really increases security.

Triple encryption increases security (significantly) in a way that double encryption cannot (negligibly); it follows that triple encryption, with three independent keys, is the shortest potentially "good" cascade, in this sense. This has been proven under the ideal-cipher model, using code-based game-playing techniques. (Note, I use "Shannon model" and "ideal-cipher model" interchangeably.)

I address the fallacies of the "just in case" mentality, in this post, as well as the reality of security, from an implementation perspective.

We assume that a block cipher, such as the AES, behaves like a PRP; that is, it's "hard" to distinguish the AES from a random permutation. (Read "hard" as "computationally infeasible.") Cascades aren't a necessity in achieving this.

 

Re: Cascades and such.

Thank you for your answer.

 

You're quite welcome.

You're quite welcome. If there are any concepts you'd like me to elaborate on, I'd be more than happy to. Cheers!