Russ,
16 bits would be considered very weak for integrity even if it was the
output of a crypto one-way function, which is not what you propose. If you
want strong integrity checking, you should consider going to at least 64
bits, whatever what believed to resist exhaustion attacks. I suppose you
are also counting on the parity bits, parity bits are a very weak integrity
function.
For an example of an attack off the top of my heed, one could merely
replicate one of the encrypted TDES keys 3 times, break the 16 bit checksum
by exhaustion and then break the TDES single length key by exhaustion.
Done 3 times, this totally breaks the TDES key is work essentially
proportional to that of a single length DES key. There might be some other
reason why this attack is not feasible in what you are doing, I cannot say.
You mention use of a 32 bit random salt. This might imply you want the
same key going to different entities to not be able to be determined. Is
this true? Why the salt? If you do not need a salt, then you could extend
the size of the integrity value. If you do need a salt, then you need to
determine what the appropriate size is, for a 32 bit random salt one
expects a collision in 2**16 samples, so one should not use this method to
send to 64 thousand entities and expect a viewer to not be able to tell
that 2 entites were getting the same key.
Typo: hexadecimal.
Don J.
Russ Housley <housley(_at_)spyrus(_dot_)com> on 05/29/98 03:26:46 PM
To: burt(_at_)rsa(_dot_)com, djohnson(_at_)certicom(_dot_)ca,
schneier(_at_)counterpane(_dot_)com,
denny(_at_)tis(_dot_)com,
denning(_at_)cs(_dot_)cosc(_dot_)georgetown(_dot_)edu,
omura(_at_)cylink(_dot_)com,
mhetzel(_at_)bell-labs(_dot_)com, benaloh(_at_)microsoft(_dot_)com,
brickell(_at_)certco(_dot_)com,
mjmarkowitz(_at_)attmail(_dot_)com,
smatyas(_at_)vnet(_dot_)ibm(_dot_)com, paulv(_at_)entrust(_dot_)com,
merkle(_at_)parc(_dot_)xerox(_dot_)com, elgamal(_at_)netscape(_dot_)com,
berson(_at_)anagram(_dot_)com,
desmedt(_at_)uwm(_dot_)edu,
rivest(_at_)theory(_dot_)lcs(_dot_)mit(_dot_)edu,
carlisle(_dot_)adams(_at_)entrust(_dot_)com
cc: ietf-smime(_at_)imc(_dot_)org, ams(_at_)terisa(_dot_)com,
ekr(_at_)terisa(_dot_)com,
Blake(_dot_)greenlee(_at_)greenlee(_dot_)com,
bschanni(_at_)BayNetworks(_dot_)com,
cme(_at_)cybercash(_dot_)com, jhs(_at_)tycho(_dot_)ncsc(_dot_)mil,
jis(_at_)mit(_dot_)edu, pcain(_at_)bbn(_dot_)com,
kent(_at_)bbn(_dot_)com (bcc: Don Johnson/Certicom)
Subject: CMS Key Wrapping
All:
S/MIME 3 requires a function to encrypt one Triple-DES key in another.
I
posted a proposed method several weeks ago, and I got a fair amount of
feedback. The most common concern was the lack of flexibility. may people
prefered a technique that was algorithm independent. Below, I propose an
algorithm independent function, and I am writing to request review of
that function. I propose a function that provides confidentiality and
integrity.
As background, here is refresher about how S/MIME 3 will use the function.
S/MIME 3 locally generates a random content-encryption key. As the name
implies, this key will be used to encrypt the message content. Then,
Diffie-Hellman will be used to generate a pairwise key-encryption key with
each
message recipient, and the content-encryption key will be encrypted under
the
pairwise key-encryption key.
The blocksize of the key-encryption algorithm can be determined from the
CMS
KeyEncryptionAlgorithmIdentifier protocol field. Likewise, the size of the
content-encryption key can be determined from the CMS
ContentEncryptionAlgorithmIdentifier protocol field. Triple-DES may be an
exception here; the same identifer is used for both 2-key and 3-key Triple
DES. This is probably easily handled by always wrapping three keyes, even
if
the first and third keys match.
Please do not propose improvements that are covered by any issued or
pending
patents.
Thanks for your assistance,
Russ
- - - - - - - - - -
KEY CHECKSUM ALGORITHM:
1. Initialize two 16 bit integers, sum1 and sum2, to zero.
2. Loop through the octets of the content-encryption key, most
significant octet to least significant octet.
2a. Create a 16 bit integer, called temp, by concatenating
8 zero bits and the key octet.
2b. sum1 = sum1 + temp.
2c. sum2 = sum2 + sum1.
3. Use sum2 as the checksum value.
KEY WRAP ALGORITHM:
1. Adjust the parity bits on DES and Triple-DES keys.
2. Compute a 16-bit key checksum value on the content-encryption
key as described above.
3. Generate a 4-octet random salt value.
4. Concatenate the salt, content-encryption key, and key
checksum value.
5. Generate the number of pad octets necessary to make the
result a multiple of the key-encryption algorithm block
size, then append them to the result.
6. Encrypt the result with the key-encryption key. If the
algorithm requires an IV, use an IV with each octet equal
to 'A5' hexidecimal.
KEY UNWRAP ALGORITHM:
1. Decrypt the wrapped ciphertext using the key-encryption key.
If the algorithm requires an IV, use an IV with each octet
equal to 'A5' hexidecimal.
2. Check the parity of DES and Triple-DES keys. If any is
incorrect then there is an error.
3. Compute a 16-bit key checksum value on the content-encryption
key as described above.
4. If computed key checksum value does not match the decrypted
key checksum value, then there is an error.