From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Wed, 15 Oct 1997 10:46:06 +0800
To: aba@dcs.ex.ac.uk
Subject: Re: the case for separate comms keys
Message-ID: <87688287402369@cs26.cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain




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.