Re: [Cfrg] CCM

-----BEGIN PGP SIGNED MESSAGE-----

"Housley, Russ" wrote:
> The proof is now available.  I sent it to you.  I have also sent it to
> NIST, so hopefully it will be put on their web site for everyone to fetch.

OK, here are my comments:

 - the security proof depends on the fact that the nonce N is independent
   of any previous ciphertext. The draft only says that it must be
   unique. Actually, it's not sufficient that it be unique: it must
   also be impossible for an attacker to influence the choice of nonce.

 - the "additional authenticated data" corresponds to the "label" of a
   Data Encapsulation Method as defined in [Shoup01]. Please mention this
   correspondance.

 - the security proof paper uses different names for some variables
   (a -> H and m -> M), and also refers to the label as the "header".
   The draft and the paper should be consistent (it doesn't matter
   which one is changed). Section 2.3 of the paper should probably
   also fully describe the encoding function in the draft, for
   completeness.

 - the bit numbering convention for the Flags field is not explicitly
   stated (I assume it's that bit k has weight 2^k). Since octet values
   are integers from 0 to 255, it would be clearer to specify how the
   Flags field is encoded as an integer:

     Flags = 64*Adata + 8*M + L  (in section 2.2)
   and
     Flags = 8*M + L             (in section 2.3)

 - the draft assumes that the interface to the block cipher is defined in
   terms of octet strings. The AES FIPS strictly speaking only defines the
   interface to AES in terms of bit strings. The draft should therefore
   specify that when used with AES, the most significant bit of each octet
   corresponds to the first bit of the octet as defined by the AES FIPS.
   (This is in practice what all AES implementations do.)

 - in section 2.4:
   # The final result c consists of the encrypted message m, followed by
   # the encrypted authentication value U.

   U is indeed the encrypted authentication value, but m is the variable
   name for the plaintext message.

 - decryption should be described more explicitly in section 2.5, rather
   than having to be inferred from encryption.

 - in section 2.6:
   # All implementations MUST limit the total amount of data that is
   # encrypted with a single key.  The sender MUST ensure that the total
   # number of block cipher encryption operations in the CBC-MAC and
   # encryption together does not exceed 2^61.

   (2^61 * 16)/2 octets is 16 exabytes (~ 16 million terabytes).
   It's extremely unlikely that this amount of data would (or could)
   be encrypted with a single key, even if an implementation did not
   include an explicit check. However, this paragraph could be
   interpreted as requiring that implementations include an explicit
   check, and that protocols include some mechanism for changing keys
   that will increase the protocol complexity, even though these
   are unlikely to ever be triggered in practice.

 - it might be useful to use this mode with block ciphers (or PRFs) that
   encrypt > 16-octet blocks in future. It would be no more complicated
   to define the mode generically for z-octet blocks (provided that z >= M,
   and z-1-L octets is large enough for the nonce).

 - the draft should informatively reference the security proof paper.

 - before the draft is published as an RFC, someone should write an
   independent implementation and check that it matches the test vectors
   in section 8.

[Shoup01] Victor Shoup,
          "A Proposal for an ISO Standard for Public Key Encryption
           (version 2.1)",
          Revised December 20, 2001.
          <http://www.shoup.net/papers/>

- -- 
David Hopwood <david.hopwood@zetnet.co.uk>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPXVS/TkCAxeYt5gVAQErfwf/c6ozpqihfQkD18p569RewTY7Ix99VY/A
OG9JWTcGHlxS896kfattEk4Jgc6PxDgpmtKlW7TSRD0K2OPAkIqFyeNUbLkyZ6fR
NWwsUhvj+W3o2sVtKLCkZPr8Vhv5DG3CXaya1CTEreQ80LAAfqvpwIAy36x/VSvz
uA4tSEEFBHsQ1CcKixZWQazJUOxXBBHLSz23pOFJMc1PX0hVIct0hb+2ym49cO55
QiqgZkbCHa0veTdnN1XNuOaZetk8L2ETzLJCrWX+0SHGp3/iZZVEkZj9L0uVY37H
IJ7c6mteWOnf470Vlc4Sya+02IcHFeiIfu63M5VWPe8mgPz5pBKdUg==
=pXMP
-----END PGP SIGNATURE-----
_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg