Wish List of Enhancements

[spiraldancing]

Thanks for the feedback. I prefer software to hardware solution. I will try DiskCryptor; quick read of its features does not explicitly mention remote reboot/authentication, but the software is specifically targeted at Windows full-disk encryption ... and, curiously, made by ntldr, one of the original TrueCrypt guys. If that fails, I'll try KVM.

btw, I'm no security expert, but I am a .NET developer, willing to help out. I'll keep an eye on the forum, for anything I might be able to contribute to the effort.

[compul]

btw, I'm no security expert, but I am a .NET developer, willing to help out. I'll keep an eye on the forum, for anything I might be able to contribute to the effort.

Good to hear

[Merlin]

First, thanks for the effort to reincarnate tc.

Long-term (after project stabilisation, switch to FOSS, & implementation of audit recommendations) ... I would like some way to remotely reboot an encrypted Windows system partition. I do a lot of remote work on such a system, and the frequent software patches requiring system reboot require me to regularly visit the machine in person to reboot.

(or is there already an existing tc way around this, of which I'm unaware? ... that is, besides switching OSes?)

Sabbath's suggestion of an optional external bootloader would considerably ease this in all probability, although even with TrueCrypt PXE booting a modified rescue CD has been done to enable it, but it takes quite a lot of hacking and some compiling to embed a hardcoded password in the boot image. I've not done it myself, but I've seen it decribed in detail on the old TC forum.

It would be another "nice to have down the road" feature to be able to PXE boot bypassing pre boot authentication for remote admin, with TC's design it would need a custom boot image specific to each machine, and you'd have to be very sure of keeping those images secure, any adversary who got the custom bootloader image would have full access, no password required. Some might see the ability to make such a custom bootloader as a security problem.

[WaywardGeek]

If you are interested in future requests, once things have been stabilised, then the following is my personal wish list.

Boot Loader

Protection from Evil Maid, Hardware Keylogger, Brute Force of a Stolen Drive, Plausible Deniablity, and Easy Header Backup can be greatly improved with one change in operation.

Entire boot loader, supporting a keyfile option, on a USB Flash drive similar to Diskcryptor. ntldr has demonstrated incredible possibilities with a standalone boot loader.

Very cool idea! Great ideas like this belong on a wish list somewhere. I don't know if/when we can get to this or if it makes the complexity/security feature cut, but it would be high on my list.

Panic Button

Many users request a panic button, which wipes headers and backup headers from TrueCrypt WDE, encrypted volumes or containers.

The panic button would not be required if a standalone boot loader was on a separate USB flash drive, as there would be no headers on the hard drive itself. In this case, the standalone boot loader solves an additional problem and answers many requests.

Sounds like another good feature if it can be implemented securely. This also belongs on a wish list.

Hashing.

User defined number of hashing rounds when creating a WDE disk or container. This allows users to choose an acceptable time delay themselves, on an individual basis.

When trying to decrypt a container or WDE TC will just keep hashing a given password until it works. There must be a "Stop" button provided in case a user inputs the wrong password.

The benefit of this is that it almost defeats the attackers brute force option altogether, should an adversary obtain the standalone loader. An attacker will never know if the password is wrong or if it has just not been hashed enough times.

TrueCrypt's poor password security is the main reason I got involved in password hashing. We should include Scrypt, IMO, in the short term, and the winner of the Password Hashing Competition in the long term. Unfortunately, while the algorithm you propose is brilliant, it's patented. It's called a Halting Password Puzzle. I do not believe the patent is valid, but I think we should avoid this algorithm anyway. It's sad. This is an algorithm the world should be using.

GPT Large drive Support.

I believe this will become increasingly important and frequently requested.


Plausible Deniablity Enhancement

There is still a realistic need for a plausible excuse to explain cryptographic random data on a given hard drive.

The most likely acceptable possibility, is a wiped drive, however few if any wipe programs provide a cryptographically random output and even fewer leave random data without zero'ing it out on a final pass.

I suggest a separate, but linked, development of a hard drive wiping tool which "coincidently" overwrites drives with cryptographically random data

More good ideas! We really need to create a wish list, starting with these. In general, I'm fairly adverse to feature creep, so if it were up to me (which is isn't) it might take a while or forever to add these, but they are some of the best ideas I've heard so far.

[compul]

I will create a locked sticky with a list of potentially accepted & definitely rejected wish-list items. Admins / Mods will be able to write to it. We should compile the ideas into such lists, so we have it all clear, and so that no double requests are made.

WaywardGeek: please go check and see if you have writing permission. You should have.

[Sabbath]

Firstly thank you WaywardGeek for your kinds words and interest in my suggestions.

TrueCrypt's poor password security is the main reason I got involved in password hashing. We should include Scrypt, IMO, in the short term, and the winner of the Password Hashing Competition in the long term. Unfortunately, while the algorithm you propose is brilliant, it's patented. It's called a Halting Password Puzzle. I do not believe the patent is valid, but I think we should avoid this algorithm anyway. It's sad. This is an algorithm the world should be using.

Oh dear, that is embarrassing, I apologise.

It looks as if this idea has already been thought of and discussed, this is something I am finding more and more on the internet. I sit here contemplating ideas only to later discover they are not new.

Without any further research on my part, is there any patient problems with...

Adding a salt. (User input)

Allowing the user to define the number of iterations.(optional)

[Sabbath]

I will create a locked sticky with a list of potentially accepted & definitely rejected wish-list items. Admins / Mods will be able to write to it. We should compile the ideas into such lists, so we have it all clear, and so that no double requests are made.

Thank you.

[WaywardGeek]

An enhancement I suspect a lot of users would enjoy: use the new AES-NI instructions for accelerating AES encryption (128 bit).

I've benchmarked the speed, and it's wicked fast. I suspect we could rival hardware accelerated FDE with new AES code. Basically, these instructions enable an Intel Sandy Bridge, Ivy Bridge, or Haswell processor to decrypt AES data faster than the CPU can read from external memory.

Forgive me for the tin-foil had, but while I really want this for speed, I have some concerns. If I were an NSA plant working for Intel, I might create some hardware in the CPU that could leak the 128-bit key data used by the AES-NI instructions somewhere that a back-door program could find them later. I do not know how to prove Intel has no secret AES key memory, and the instructions make it very clear where the key resides. Still, if users want speed and don't care about the NSA having a possible back-door, it is awesome.

[compul]

An enhancement I suspect a lot of users would enjoy: use the new AES-NI instructions for accelerating AES encryption (128 bit).

I've benchmarked the speed, and it's wicked fast. I suspect we could rival hardware accelerated FDE with new AES code. Basically, these instructions enable an Intel Sandy Bridge, Ivy Bridge, or Haswell processor to decrypt AES data faster than the CPU can read from external memory.

Forgive me for the tin-foil had, but while I really want this for speed, I have some concerns. If I were an NSA plant working for Intel, I might create some hardware in the CPU that could leak the 128-bit key data used by the AES-NI instructions somewhere that a back-door program could find them later. I do not know how to prove Intel has no secret AES key memory, and the instructions make it very clear where the key resides. Still, if users want speed and don't care about the NSA having a possible back-door, it is awesome.

I am too fond of tin-foil hats to condone rely on proprietary instructions for a security-sensitive piece of software I have to say. The speed is nice, but I think we cannot start making little compromises like that, as it will add up.

[Merlin]

An enhancement I suspect a lot of users would enjoy: use the new AES-NI instructions for accelerating AES encryption (128 bit).

I've benchmarked the speed, and it's wicked fast. I suspect we could rival hardware accelerated FDE with new AES code. Basically, these instructions enable an Intel Sandy Bridge, Ivy Bridge, or Haswell processor to decrypt AES data faster than the CPU can read from external memory.

Forgive me for the tin-foil had, but while I really want this for speed, I have some concerns. If I were an NSA plant working for Intel, I might create some hardware in the CPU that could leak the 128-bit key data used by the AES-NI instructions somewhere that a back-door program could find them later. I do not know how to prove Intel has no secret AES key memory, and the instructions make it very clear where the key resides. Still, if users want speed and don't care about the NSA having a possible back-door, it is awesome.

It's great in benchmarks, when it comes to TrueCrypt in real operation, you find you're already bottlenecked by I/O you can saturate the SATA bus as it is, then net effect in use is no benefit.