Truecrypt 5.0 Release Date Set - FEBRUARY 4th

You don't have to burn it...
I mounted the rescue disk with the old freeware version of Daemon tools (3.47) and "tricked" it just fine.

 

There is a pdf file included in the install. Please read the instructions for preparing a bootable rescue CD containing a backup of the key from your system install. You can make a CD with a way to recover.

 

My response above was to reparsed. Sorry, should have noted that.

 

here's something i wonder about now that TC 5 can do WDE. in the documentation it talks about those 3 major security risks, pagefile, hibernate file, crash dump. it states that if you use WDE the pagefile is now protected, but for hibernate & crash dump the TC Driver just automatically disables them instead. shouldnt WDE be able to protect all 3 of those areas now?

here is what it states for the hibernate & crash dump

"Note: If your system partition/drive is encrypted by TrueCrypt, the TrueCrypt driver automatically prevents Windows from hibernating the computer (for information on how to encrypt the system partition/drive, see the chapter System Encryption)."

"Note: If your system partition/drive is encrypted by TrueCrypt, the TrueCrypt driver automatically prevents Windows from writing any data to memory dump files (for information on how to encrypt the system partition/drive, see the chapter System Encryption)."

 

Thats going too far. yes the page file is protected, and so should the hibernation dump and crash dumps, they are al on the system partition. I personally suffer from BSODS once in a while, and it is vitally important for me to analyse my crash dump files, to locate my problem. If TC driver bypasses the windows GUI settings, and forces system to not write crashdumps, then thats bad indeed.

 

Disabling the hibernate file and crash dumps on a system where the entire windows partition is encrypted seems sort of backwards, no?

Perhaps hibernating doesn't work with the WDE for some reason. I'll be sacrificing my current install to test it

 

I thought I replied once but must have poofed.

I'm wondering about the hibernation issue myself. As much as I want to do the encryption on my laptop, losing Hibernation isn't an option for me right now. This is a showstopper for me, for WDE, in addition to their forums being closed.

 

Hibernation would bring the disk up for full access to anyone to use. Whats the point in using full disk encryption if your going to hibernate the system?

 

This is much the same as PGP WDE. They claim to allow hibernation, but upon closer inspection you see they really don't. While PGP will allow the hibernation mode to kick in, you can't get out of hibernation mode without rebooting and re-authenticating. What's the difference? Just a comparision thought.

 

Exactly

 

Same issue with the system partition drive memory issue.

 

for people having the "insufficient memory for encrypting" issue i would suggest filling out the bug form, the more people who do the more seriously they will take it. even if it turns out not to be a bug, we might be able to get a better explanation & a possible work around.

https://www.truecrypt.org/bugs/


i've always liked TC's driver cache option, & for those who will use the same password for WDE as they do with their file containers. i wonder if it would be possible to cache the password at WDE bootup so you dont have to enter it again once Windows has started to open file containers. because right now you have to enter the same password twice.

i'm still not quite so sure they should force users to create a rescue disc, i have a feeling that feature will be yanked in the future. if not, others could take it upon themselves to edit the code & release an altered "nag-free" version of TC to the market, thats also malware infected but unknowing people will still D/L it & it could damage TC's reputation. ive had a ton of products offer to make me a rescue disc but none ever forced me too. i realize they are trying to reduce support questions, but it's a free product & they are not required to support it anyways.

i havent rebooted since earlier today, but do they offer a "show keystrokes" option with WDE? i've always hated the current method, grab the mouse > click the box > reclick password area. PGP's approach of just hitting the Tab key works much better.

 

I downloaded the new version and it works just fine. I didn't realize how much a truecrypt folder was like any other folder. I just did some experiments. I was able to email a small truecrypt folder (5MB). I zipped it too. And I created a 150MB folder and split it and rejoined it with HJsplit. It is a really cool program.

 

Hibernation is still desirable, the purpose of WDE is to prevent offline attacks, which are still impossible if the system resumes from hibernation, IE you still have to enter a password to get into windows and still can't just remove the disk to get to the data.

 

While I don't use hibernation much anyway, it was my understanding that the computer was actually "off" during hibernation, but had instructions to load a backup of the last session's system memory from some file on the hard drive. If that's how it actually works, then it doesn't seem like there should be any security issues with hibernation.

Is there any chance that the "switch" to tell the computer whether it's booting normally or waking up from hibernation is stored on the first track of the hard drive (overwriting the normal boot code until the computer boots back from hibernation)? It doesn't seem like that would be the case, but I can't see why else they'd disable it (unless I'm misunderstanding the mechanism by which hibernation works, which is quite possibly the case).

 

I think that some are confusing Stand-by (Power components off, but not everything. "Restarting" puts you back at the Windows login / Desktop) with Hibernate (Power off, cold system no power required. "Restarting" goes starts at the BIOS POST, and hands off to the boot loader.).

I don't understand why you couldn't request a password as normal to decrypt the drive granting access to hiberfil.sys which contains the contents of RAM at the time of instituting the Hibernation. I don't think hibernation affects the MBR at all, because if it did, hibernation would trigger MBR "Anti-Write" protections offered to prevent MBRs from being infected with viruses in some BIOS.

For those with Laptops, Hibernate is one of the best features available, since power is a commodity, especially when your away from the outlet. Stand-by is good, but it still drains power over time. I do hope this is something that could be fixed. This almost usurps a feature that I think is more important, which is the ability to access containers without having any administrator access and no pre-install. I don't know why it can't be implemented as a program that opens containers similar to say WinZip, allowing you to extract (minimum) or add (would be great) files to a container.

 

Don't sweat it.

Don't be concerned. There's good cryptographic reason behind simply using the AES. Consult this post of mine, to read my thoughts on why you should choose the AES over Twofish or Serpent. If you want more reassurance, consult another post of mine, which references the opinions of David Wagner (co-designer of Twofish) and Ross Anderson (co-designer of Serpent); they both recommend the AES.

Now that TrueCrypt is available for OS X, I'll give it a try. Until then, I'm not sure of the performance overhead associated with TrueCrypt's cascade implementations. Regardless, I think they should be excluded from the implementation altogether, for reasons discussed in other posts; they're unnecessary. Cheers!

 

Single-boot, Multi-boot? Whats the difference in functionality? I know the difference in the systems configuration, but how does truecrypt treat things differently?

 

TechWG: the program makes a distinction between encrypting an entire device (everything but the mbr+bootloader), and only the windows partition. In either case it appears as if TC is trying to protect users, if you select full device encryption and then tell truecrypt you have a non windows OS installed in another partition, it stops you because that other OS cant support system encryption. It also seems to do some checking to ask you if you have grub installed in the MBR at the moment etc. However if you only encrypt the windows partition you can in fact dual boot other OS easily, just make sure you don't write over the MBR or the TC bootloader.

To those of you having the memory problem, it appears as if this error has nothing to do with the system ram available. It seems the bootloader executes in real mode, which has fairly limited memory available for code. It could be that your bios isn't providing enough memory in real mode for the bootloader to do its job.

 

Hibernation Not Supported - Text

Ok, I just fired up a VM, Encrypted it and got this message when attempting to enable Hibernation.

That said, I now understand why its disabled, however it seems like it should still be available if the system is encrypted. Hibernation is available if the system is not encrypted. Is it me, or did the developers do this backwards??

It also appears that there is room for hope as they specifically say "currently not supported".

Also, I forget if it was this thread, but you can fool TrueCrypt by mounting the image, and therefore not burning the CD Image.

 

tried that with alcohol, it did not like it, i burned it.

I had completel success, bootloader works, password works, disc works, encryption speed is good, counterstrike source took maybe twice too 3 times as long to initially load (not suprising) but the game worked flawlessly, and i was owning in a french server. Everything SO FAR works smashingly

 

funny thing is, the PC of mine it doesnt work on is brand new (just a few months old). you would think that all modern PC's would ship with enough BIOS memory.

 

Re: Don't sweat it.

Justin do you recommend using the AES-TWOFISH-SERPENT encryption? Is it unbrakeble ?

 

In another forum I read, that the "insufficient memory" problem has something to do with the AHCI-Mode (native sata-mode) or with the Raid-mode if you are using a Raid.
So I switched it in my Bios from Ahci to Ide and the encryption started working.
The Problem is, that even after the encryption is finished you can't switch back to AHCI.

You might get a blue screen when windows is starting, by switching to AHCI.
If that is the case, you have to change a value in the registry. It worked for me.

 

Heres the relevant error in boot/windows/bootmain.cpp

Code:

// Check memory
	uint16 codeSeg;
	__asm mov codeSeg, cs
	if (codeSeg == TC_BOOT_LOADER_LOWMEM_SEGMENT)
	{
		PrintError ("Insufficient memory for encryption");

And heres where TC defines the memory needed in boot/windows/bootdefs.h:

Code:

// Total memory required (CODE + DATA + BSS + STACK) in KBytes - determined from linker map.
#define TC__BOOT_MEMORY_REQUIRED	60

It seems likely it really is a memory problem, but what triggers it and who will be affected seems to be determined by individual bios differences.