Russ,
Here are some thoughts.
1. Use of HMAC (using SHA-1) versus simple SHA-1 of the key may give
security properties that are easier to show and be more conforming to
existing stds. It can also grow easier, one never knows how these things
might grow.
2. You need to indicate if the parity bits are checked or not on recovery.
I suggest that they should be checked, since they are set. This provides
some more integrity.
3. The use of fixed IV's means that the first block of each encryption is
less protected than the subsequent blocks. This makes analysis more
difficult. If I were going to attack this method, I would concentrate on
the less protected blocks, trying to find a match after less than 2**32
encryptions. This is not a complete idea but may be a start. That is, the
middle 2 blocks seem to collide in 2**32 encryptions, but the end blocks
might collide sooner.
4. I still think you should try to list some goals for this method. For
example, 64 bits of integrity, every bit depends on every other bit,
confidentiality for key, etc.
Don Johnson
Russ Housley <housley(_at_)spyrus(_dot_)com> on 02/20/99 04:17:39 PM
To: ietf-smime(_at_)imc(_dot_)org
cc: 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,
smatyas(_at_)us(_dot_)ibm(_dot_)com, paulv(_at_)entrust(_dot_)com,
merkle(_at_)parc(_dot_)xerox(_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, ams(_at_)terisa(_dot_)com,
ekr(_at_)rtfm(_dot_)com,
Blake(_dot_)greenlee(_at_)greenlee(_dot_)com, cme(_at_)ACM(_dot_)ORG,
bfox(_at_)microsoft(_dot_)com,
acc(_at_)tycho(_dot_)ncsc(_dot_)mil, bschanni(_at_)BayNetworks(_dot_)com,
dickie(_at_)EMPIRE(_dot_)eclipse(_dot_)ncsc(_dot_)mil,
jhs(_at_)tycho(_dot_)ncsc(_dot_)mil, jis(_at_)mit(_dot_)edu,
pcain(_at_)bbn(_dot_)com, kent(_at_)bbn(_dot_)com,
BSnow(_at_)radium(_dot_)ncsc(_dot_)mil,
cjwagne(_at_)missi(_dot_)ncsc(_dot_)mil, balenson(_at_)tis(_dot_)com,
balenson(_at_)tis(_dot_)com,
jlinn(_at_)securitydynamics(_dot_)com,
smid(_at_)csmes(_dot_)ncsl(_dot_)nist(_dot_)gov,
daw(_at_)cs(_dot_)berkeley(_dot_)edu (bcc: Don Johnson/Certicom)
Subject: Re: A New Triple-DES Key Wrap Algorithm
All:
Right now, I am leaning toward the double encryption wrap algorithm. I
think it will be easy to implement, and it yeilds a shorter result that the
OAEP method. To convince myself that it was easy to implement, I did an
implementation. It took me about two hours while watching an old Jimmy
Stewart movie. Of course, I already have SHA-1 and Triple-DES CBC
routines. S/MIME v3 will require these algorithms for other capabilities
besides key wrapping.
If someone else is willing to do an implementation, I would like to compare
results. This will allow a test vector to be included with the algorithm
description.
Does anyone have any strong objections to the double encryption wrap
algorithm being selected?
Russ
WRAP ALOGRITHM #1: DOUBLE ENCRYPTION
Key Checksum
The CMS Checksum Algorithm is used to provide an content-encryption key
integrity check value. The algorithm is:
1. Compute a 20 octet SHA-1 message digest on the
content-encryption key.
2. Use the most significant (first) eight octets of the
message digest value as the checksum value.
Triple-DES Key Wrap
1. Set odd parity for each of the DES key octets comprising
the content-encryption key, call the result CEK.
2. Compute a 8 octet key checksum value on CEK as described above,
call the result ICV.
3. Let CEKICV = CEK || ICV.
4. Encrypt CEKICV in CBC mode using the key-encryption key. Use
an IV of 0xc302e3c1ad8bb738.
5. Reverse the order of the ciphertext octets. That is, the most
significant (first) octet is swapped with the least significant
(last) octet, and so on. Call the result TEMP.
6. Encrypt TEMP in CBC mode using the key-encryption key. Use
an IV of 0x61a197e5b132e196. The ciphertext is 32 octets long.