[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.