ietf-smime
[Top] [All Lists]

Re: Comments on draft-ietf-smime-cms-aes-cmc-and-gcm-00.txt

2007-03-20 09:14:31

Jim:

1.  Pointer to GCM is out of date.  Should be
http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/gcm-revised-spec.pdf

They are compatible, but I'll change the reference. I hope that the NIST SP comes out before this document is published as an RFC.

2.  I don't see CCM as having two outputs, the text appears to imply that
the authentication code is emitted as part of the encrypted message stream
rather than separately [RFC 3610 section 2.4].  This contradicts what is
stated in section 1.4 of this document.

RFC 3610 says that the final result consists of the encrypted message followed by the encrypted authentication value. This is a result of the packet-oriented description that we use in that document. Section 2.5 talks about the inputs to the decrypt and authentication checking function, and this section says: "Decryption starts by recomputing the key stream to recover the message m and the MAC value T." In the AuthEnvelopedData syntax, these two things are carried in two different fields, but the key stream is used as described in CCM to perform the decryption. In fact, the counters that are used makes this simple and straightforward. Counter value 0 is used for the MAC, and counter values 1 .. n are used for the content.

3.  Neither of the algorithms discusses what is needed for padding.

Due to the ASN.1 encoding, all inputs are guaranteed to be multiples of octets. No padding of the inputs is needed.

Russ

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Comments on draft-ietf-smime-cms-aes-cmc-and-gcm-00.txt, Russ Housley <=