Re: the case for separate comms keys

Death rays from Mars made Adam Back <aba@dcs.ex.ac.uk> write:
You can also acheive the same flexibility with an extra indirection with symmetric storage keys (optionally held in escrow). In fact I think this is what later versions of Peter Gutmann's SFS do. The reason he uses for this is that it allows you to change your passphrase without re-encrypting the whole disk, because the _actual_ disk encryption key is encrypted itself with the hash of your passphrase, rather than using the hash of the passphrase directly as the key.
There are also a few other reasons for doing this, and I've extended the idea used in SFS for use with my cryptlib encryption toolkit. Instead of encrypting just the key, you also encrypt the algorithm details, ie: E ( algorithm, algorithmInfo, key ) passphrase E ( data ) algorithm, algorithmInfo, key This makes the job of an attacker somewhat harder because even if they have some means of performing a reasonable attack on the second encryption step, they won't know exactly what it is, so even if it only has a 40-bit key they might need to search half a dozen algorithms before finding the right one. This makes it a lot harder to just brute-force everything going past in the hope of finding something useful. This is especially entertaining for algorithms like RC5 and Safer, where you can produce dozens of variations by playing with algorithm parameters, in effect adding extra bits to the key length. As Adam mentions, you can also escrow[0] the second key (which SFS does using a threshold scheme with the parameters controlled by the user). In this way the user can change their password without destroying the ability of the escrow to access the data. Finally, using the session-key mechanism means you never encrypt two lots of data using the same key, and means you can encrypt a single message for multiple recipients just like the public-key equivalent. Peter. [0] This is "escrow" used in the true sense, not the GAK euphemism. It's completely under the control of the user, it's optional, and it's intended for recovery of stored data when you forget the passphrase.
participants (1)
-
pgut001@cs.auckland.ac.nz