Someone pointed out that the fact that TrueCrypt allows a hidden system gives an attacker the incentive to torture you until you reveal the secondary hidden one. And if you don’t use the option, that’s too bad for you—then the attacker just tortures you until you die, since they don’t believe you when you deny the existence of it.
Someone pointed out that the fact that TrueCrypt allows a hidden system gives an attacker the incentive to torture you until you reveal the secondary hidden one.
If you’re really paranoid you can implement a nesting-doll system with as many levels of depth as you want.
But that argument applies just as well to anything at all: the existence of flash drives (or, say, treasure chests filled with gold) gives the attacker an incentive to torture you until you reveal the location of your hidden data (or treasure).
One possible way around that, would be to allow a potentially infinite number of hidden systems each with their own passcode.
There are a few issues with this though:
Depending on the size of the message, this could get big, fast.
The content of any decoy messages would likely leak contextual clues as to their veracity, unless all decoy messages sounded equally plausible.
Once you extract one password, the length of the message compared to the size of the encrypted payload would leak information about the number of hidden systems.
With all that said, you could address these security concerns by only having the “hidden system” apply to the truly sensitive parts of the message. In other words, you would start with the main message that has been sanitized of any relevant information, and then encrypted. Then, for each piece of sanitized information, you’d provide several plausible answers, which are each encrypted with their own key.
So for example you would have is a master message:
Master: “The plan to [1] the [2] is confirmed at [3]”
And then the possible answers:
attack, vandalize, have lunch at, prank call
enemy headquarters, subway platform, the local diner, your ex girlfriend
noon, midnight, 17:00, tonight
So the “full” password would basically be:
Master Password + Password for Blank 1 + Password for Blank 2 + Password for Blank 3
So for this example there would be 64 different combinations of possible answers ranging from the correct one: “The plan to attack the enemy headquarters is confirmed at noon.” to the incorrect but plausible “The plan to attack the enemy headquarters is confirmed at midnight” etc.
This would address the issues of #1 and #2. However it still would be possible for the attacker to guess based on the size of the message how many different combinations there may be. This can be circumvented one of several ways:
Have so many options that the knowledge of their quantity would be useless.
Pad the message with garbage data.
Of course this does present the logistical issue of how you exchange the correct password for such a message. Functionally the password exchange process would be no different than any other, this would simply require a longer password.
Someone pointed out that the fact that TrueCrypt allows a hidden system gives an attacker the incentive to torture you until you reveal the secondary hidden one. And if you don’t use the option, that’s too bad for you—then the attacker just tortures you until you die, since they don’t believe you when you deny the existence of it.
If you’re really paranoid you can implement a nesting-doll system with as many levels of depth as you want.
But that argument applies just as well to anything at all: the existence of flash drives (or, say, treasure chests filled with gold) gives the attacker an incentive to torture you until you reveal the location of your hidden data (or treasure).
One possible way around that, would be to allow a potentially infinite number of hidden systems each with their own passcode.
There are a few issues with this though:
Depending on the size of the message, this could get big, fast.
The content of any decoy messages would likely leak contextual clues as to their veracity, unless all decoy messages sounded equally plausible.
Once you extract one password, the length of the message compared to the size of the encrypted payload would leak information about the number of hidden systems.
With all that said, you could address these security concerns by only having the “hidden system” apply to the truly sensitive parts of the message. In other words, you would start with the main message that has been sanitized of any relevant information, and then encrypted. Then, for each piece of sanitized information, you’d provide several plausible answers, which are each encrypted with their own key.
So for example you would have is a master message: Master: “The plan to [1] the [2] is confirmed at [3]”
And then the possible answers:
attack, vandalize, have lunch at, prank call
enemy headquarters, subway platform, the local diner, your ex girlfriend
noon, midnight, 17:00, tonight
So the “full” password would basically be: Master Password + Password for Blank 1 + Password for Blank 2 + Password for Blank 3
So for this example there would be 64 different combinations of possible answers ranging from the correct one: “The plan to attack the enemy headquarters is confirmed at noon.” to the incorrect but plausible “The plan to attack the enemy headquarters is confirmed at midnight” etc.
This would address the issues of #1 and #2. However it still would be possible for the attacker to guess based on the size of the message how many different combinations there may be. This can be circumvented one of several ways:
Have so many options that the knowledge of their quantity would be useless.
Pad the message with garbage data.
Of course this does present the logistical issue of how you exchange the correct password for such a message. Functionally the password exchange process would be no different than any other, this would simply require a longer password.