ietf-smime
[Top] [All Lists]

Re: Comments on CMC-09

1998-11-30 17:46:00
Jim Schaad (Exchange) wrote:



15.  Section 12.6.2 - You have not modified the key wrap
algorithm to allow
for arbitrary length RC2 key sources.

Are you suggesting an explicit length field or something else?

We need to either put in an explicit length field or use a known padding
algorithm.  I have no perference on which is used but something along this
lines is absolutely required.


Speaking personally I'd prefer known padding. Known padding at least
adds some consistency with the use of symmetric algorithms: they all use
the "padded" forms.

If an explicit length parameter is included the logical place to put it
is in the EncryptedContentInfo structure because its a property of the
content encryption key. You'd probably then have to make it OPTIONAL for
v2 compatability only include it when at least one recipient used key
agreement.

With known padding the following minor change should suffice:

   1.  Modify the content-encryption key to meet any restrictions on 
       the key. For example, adjust the parity bits for each DES key
       comprising a Triple-DES key.
   2.  Compute a 16-bit key checksum value on the content-encryption key
       as described above.
   3.  Generate a 32-bit random salt value.
   4.  Concatenate the salt, content-encryption key, and key checksum
       value.
   5.  Add one block length of randomly generated pad octets. Then pad
       the result using standard block padding as defined in section
       6.3.
   6.  Encrypt the result with the key-encryption algorithm key.  Use an
       IV with each octet equal to 'A5' hexadecimal.

The unwrap text is OK as it is but a comment could be added that the
key length can be checked:

   5.  If there are restrictions on keys, then check if the
       content-encryption key meets these restrictions.  For example,
       check for odd parity of each octet in each DES key that makes up
       a Triple-DES key and check that the key length is correct.  If 
       any restriction is incorrect, then there is an error.




16.  Section 12.3.1.1 - In the KeyWrapAlgorithm is the IV
present and is its
value the constant 'A5' repeated n time?  The IV was not
present in the
previous versions but would appear to be present now.  We
still have the IV
restriction on the key wrap algorithm however.

There is no field needed to carry the IV as it is always
"A5...A5".  For 3DES,
the parameter is always NULL, and for RC2 the parameter is
the effective key
length.  Where do you see an IV?

OK -- I see where I got confused.  I started with the second paragraph in
section 12.3.1 and made a leap of incorrectness into the fact that the
KeyWrapAlgorithm was going to be rc2-cbc not id-alg-RC2wrap.  I don't see
any clarifications that need to be added to the text, I was just skimming
the changes too fast.


Just to add a little comment of my own since I suggested part of this.
My primary reason for this change is to allow algorithms other than RC2
and 3DES to be used with key agreement. In the case of RC2 and 3DES a
special algorithm identifier form is defined without the IV. In other
cases, such as (single) DES the normal algorithm identifier would be
used which would include an IV: but in this case it would be ignored
and A5 used.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk
PGP key: via homepage.



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