Wish List of Enhancements

[Sabbath]

I am not a crypto coder so my requests may not be possible, or at least very difficult incorporate from a coding perspective. I am certain everyone will understand the security enhancements, so in an effort to keep things brief, I will omit any long winded explanations.

Obviously follow the audits recommendations first and preferably prepare the code and tool chain to facilitate simpler development of TC in the future.

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.

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.

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.


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

[jrombough2009]

Hello,

The organization I work for had been using TrueCrypt to encrypt the entire hard drives of their laptops. Since we are an educational inititution we are forced to use Microsoft for the majority of the client workstations (some MAC too).

My wish list
1. Be able to boot to an encrpyted drive in Windows 8 and 8.1. This means we need to boot from a UEFI device.
2. Complete hard drive encryption for both Linux and MAC.

This would be so I could continue to use new-truecrypt and not be forced into using bitlocker.


Jeff

[Merlin]

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.

I think keyfile support in the bootloader is desirable too, how feasible it is given space constraints, especially when cipher cascades are in use is something only developers can answer.

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.

System encrypted drives don't have backup headers, only non system encrypted ones, I think keyfile support would answer this sufficiently anyway, keyfiles are small and easy to secure delete.

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.

Nice if you're a geek maybe, your typical windows user doesn't really want the extra hassle of picking, and is as apt to choose unwisely as wisely, or set a high count on their shiny new haswell box, then wonder why it takes a month to mount on their old laptop...
Long term I recon memory hard functions are probably a better way to go.

GPT Large drive Support.

I believe this will become increasingly important and frequently requested.

Agreed, it's the only "new feature" I'd actually consider as high priority. After dealing with the audit It'd be my number one request. I think GPT is already supported for non system encryption.
GPT/EFI boot needs sortling, like it or not we're stuck with it becoming the norm.
Support for large drives with 4K native sectors is apparently not difficult to make truecrypt do, according to the cryptsetup wiki, there's some security concern over using XTS mode with large sectors, so support may prove non-trivial.. I'm sure the developers will be seeking some advice from crypto experts, rather than simply enabling it in the code as some others have done.. I hope anyway.

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

I beleive /dev/urandom is considered cryptographically random, perhaps changing the partition type for partition based encryption to a linux one would point the right direction, and also stop Windows constantly prompting you to format a partition it sees as "RAW".. You simply wouldn't beleive how many posts there were on the old TrueCrypt forum begging for a way to recover from the common error of clicking yes for that Windows prompt.

Further down the road perhaps the developers could consider such a wiper, maybe based on AES used in counter mode with a random key, that should be both fast and a secure wipe on modern hardware, and even verifyable that the wipe was completely sucessful.

I'd rather see concentration on the audit than any rush to new features though, but it sounds a good idea for later development.

[Sabbath]

I think keyfile support in the bootloader is desirable too, how feasible it is given space constraints, especially when cipher cascades are in use is something only developers can answer.

My request mentioned a standalone bootloader on a USB drive. Space is not an issue.

System encrypted drives don't have backup headers, only non system encrypted ones, I think keyfile support would answer this sufficiently anyway, keyfiles are small and easy to secure delete.

The request was that the standalone bootloader USB drive also contained the headers. I did mention TrueCrypt WDE, encrypted volumes or containers.

Nice if you're a geek maybe, your typical windows user doesn't really want the extra hassle of picking, and is as apt to choose unwisely as wisely

A simple default option with a minimum iteration count would obviously be available. Other users should be provided a choice to defend against brute force, as explained above. Your assumption about the users abilities would also lead to suggest that a minimum password length and entropy should be enforced for the same reasons.

I beleive /dev/urandom is considered cryptographically random, perhaps changing the partition type for partition based encryption to a linux one would point the right direction

Earlier in you post you suggested that "typical windows users" don't want the hassle or they have the potential to choose unwisely. I understand your concerns about general users abilities, yet in this instance you appear imply that "typical windows users" should know how to use dev/urandom and presumably be able to demonstrate this under stress when faced with an adversary ?

/dev/urandom is a poor substitution for a plausible excuse regarding the average user, when compared to my request.

You simply wouldn't beleive how many posts there were on the old TrueCrypt forum begging for a way to recover from the common error of clicking yes for that Windows prompt.

Yes I am well aware of the content in the previous TrueCrypt forum.

Further down the road perhaps the developers could consider such a wiper

My request is listed under long term goals for that reason.

Thanks for your input

[Merlin]

I'm not in fundamental disagreement with you about lots of this Sabbath, although space for the bootloader is a consideration unleess you plan forcing people to use an external one.. which could be a bad idea. As something optional it's a useful idea. I'm sure I'm not alone in having a low threat model and not wanting to have to worry about losing my bootloader CD/USB or having it go bad.

ntldr's approach with DiskCryptor is interesting, but the TC bootloader has had the code audited, his hasn't, without scrutiny who can say how secure it is? By all means it should be looked at, or good ideas adopted, but don't go forcing us all to carry highly loseable USBs or scratchable CDs, you'll get widespread objections, so the bootloader must fit on drive...

I only mentioned urandom as something interim, combined with a small change that would aid interim plausibility for some and meanwhile help protect data from a common cause of damage for all.

I'm most certainly not trying to argue that later down the road a wipe app wouldn't be a good plan, it's something that sounds sensible, just possibly not high priority, at least I'd personally place it after a simple small protection against accidental data destruction in my own prioritised list. I thought it was sufficiently sensible I even suggested an approach which there's code inside TrueCrypt it could be based off.

[Sabbath]

I'm not in fundamental disagreement with you about lots of this Sabbath

It's ok, I didn't think you were.

space for the bootloader is a consideration unleess you plan forcing people to use an external one.

I was not suggesting forcing anything.

As something optional it's a useful idea.

Thank you.

not wanting to have to worry about losing my bootloader CD/USB or having it go bad.

Backups would prevent any serious issue. I understand your lack of faith in windows users, but I assume most users know the importance of backups. Also the standalone bootloader is an optional feature don't forget.

ntldr's approach with DiskCryptor is interesting, but the TC bootloader has had the code audited, his hasn't, without scrutiny who can say how secure it is?

The moment TrueCrypt is re-branded or recompiled in any way, the current audit is worthless from a security perspective. The standalone bootloader feature is many times better in theory at least, than the present option for reasons explained above.

but don't go forcing us all to carry highly loseable USBs or scratchable CDs

I have not suggested forcing.

I'm most certainly not trying to argue that later down the road a wipe app wouldn't be a good plan, it's something that sounds sensible, just possibly not high priority

I agree, something for the future, which is why this request is listed under long term goals.

Thank you for your comments.

[spiraldancing]

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?)

[compul]

I'm not so familiar with Win. For cryptsetup on my Debian server that seems quite easy, but you ruled out that answer.
KVM should allow you to do something like that though.
http://en.wikipedia.org/wiki/Intel_Acti ... te_control
I'm sure AMD CPU's have similar features to offer.

[Sabbath]

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?)

Diskcryptor allows you to remote boot / authenticate as far as I know.

[compul]

If that is so, we can consider if it seems viable to create a similar solution, maybe based off of DiscCryptor (GPLv3), or to just refer people to KVM.
I must admit that an integrated solution would be much better in terms of usability.