ietf-smime
[Top] [All Lists]

Re: Triple-DES Key Wrapping

1998-03-30 22:19:20
Dr Henson:

Thanks for looking at the 3DES key wrap proposal.

I looked at PKCS#5.  It seems to me that the password-based-encryption
defined in PKCS#5 is not suitable.

I do not think that the parity bits in the key bytes do not provide
sufficeint integrity.  There is no information to ensure that the bytes are
in the correct order.

Additionally, I defined a key wrap algorithm that is smaller that the
alternative you proposed.  It seems to me that we should not make the
wrapped key any bigger than necessary.

I did not invent the sum-of-sums checksum proposed.  This integrity
function has had quite a bit of analysis, and the result is very small when
compared to a hash function.

Russ


Dr Stephen Henson wrote:
The obvious method (to me at least) is to use triple DES CBC with PKCS#5
padding. On the face of it the parity checks over 24 bytes and padding
gives a better than 1 in 2^32 chance of random data failing the test.

I suppose the only issue is where the inner IV comes from. Any reason
why the outer IV (from the AlgorithmIdentifier) can't be used twice?

Failing that the inner key could be the DER encoding of something
analagous to a DigestInfo structure containing the encryption algorithm,
IV and key. If you do things that way you automatically get something
that should work with all algorithms and doesn't require that the inner
and outer encryption algorithms be the same. You also get a kind of
inbuilt integrity check because any corruption/tampering is likely to
result in an invalid encoding.

In any case why does another checksum need to be devised? We already
have some pretty good checksums and ways of presenting them with digest
algorithms and DigestInfo structures.

Steve.
-- 
************************************************
* Dr Stephen N. Henson.                        *
* Freelance Cryptographic Consultant.          *
* Email: shenson(_at_)bigfoot(_dot_)com                   * 
************************************************


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