ietf-smime
[Top] [All Lists]

Re: Triple-DES Key Wrapping

1998-04-11 01:55:37
[Followup list trimmed somewhat]
 
S/MIME 3 requires a function to encrypt one Triple-DES key in another. Below, 
I propose such a function, and I am writing to request review of that function.

I was unable to find a standard for the encryption of one Triple-DES key in 
another Triple-DES key.  The obvious encryption of the three DES keys in ECB 
mode does not seem sufficient to me.  This method would allow an attacker to 
rearrange the three blocks and the recipient could not detect the problem 
until  the entire message we decrypted.  So, I have proposed a technique that 
provides confidentiality and integrity.
 
I ran into the same problem a few years back, and solved it by treating the 
encrypted key as just another type of PKCS #7 wrapping (well, not literally, 
but logically). 
 
The wrapped data used to communicate the session key is:
 
KeyInformation ::= SEQUENCE {
  algorithm     AlgorithmIdentifier,  
  key           OCTET STRING (SIZE(5..CRYPT_MAX_KEYSIZE)),
  cookie        KeyCookie,              
  padding       OCTET STRING OPTIONAL
  }
 
The algorithm and key specify the algorithm and session key to use for 
encrypting the remaining data.  The cookie is a truncated SHA-1 hash of the 
algorithm and key fields which (1) protects them from modification and (2) 
allows checking that the correct decryption key was used (to generate it you 
encode a KeyInformation without the cookie and padding and hash it).  The 
padding hides the length of the inner content to foil traffic analysis (the 
whole thing is always padded out to a multiple of 64 bytes).
 
The whole thing is then encrypted with the KEK:
 
EncryptedKey ::= SEQUENCE {
  algorithm     AlgorithmIdentifier,  
  iv            OCTET STRING (SIZE(1..CRYPT_MAX_IVSIZE)),
  encryptedKey  ENCRYPTED{KeyInformation}
  }
 
This scheme is independant of algorithm and encryption mode used for both KEK 
and session key, and protects the contents from modification using the 
encrypted hash.  It's also, IMHO, quite a bit simpler than the proposed 
solution and therefore easier to get right for implementors.
 
What makes this useful is that it's completely general-purpose (you can use 
any algorithm to exchange a key for any other algorithm), and has the added 
benefit that since the session key + algorithm used is hidden, you can get a 
little extra security by not using the same algorithm for both types of 
encryption (for example if you randomly choose the session key algorithm from 
{ IDEA, 3DES, Blowfish, CAST-128, and RC5 } it makes things a little harder 
for an attacker, and reduces your exposure if one of these is later broken).
 
Please do not propose improvements that are covered by any issued or pending 
patents.
 
Perish the thought :-).
 
Peter.


<Prev in Thread] Current Thread [Next in Thread>