Re: [Cfrg] CCM

David Hopwood <> Tue, 03 September 2002 23:27 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id TAA17110 for <>; Tue, 3 Sep 2002 19:27:48 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id g83NT0l31576 for; Tue, 3 Sep 2002 19:29:00 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id g83NSxo31573 for <>; Tue, 3 Sep 2002 19:28:59 -0400
Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id TAA17093; Tue, 3 Sep 2002 19:27:18 -0400 (EDT)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id g83NSLo31553; Tue, 3 Sep 2002 19:28:21 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id g83NRZo31513 for <>; Tue, 3 Sep 2002 19:27:35 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id TAA17062 for <>; Tue, 3 Sep 2002 19:25:52 -0400 (EDT)
Received: from ([] ident=root) by with esmtp (Exim 3.35 #1 (Debian)) id 17mN4w-0000xq-00 for <>; Wed, 04 Sep 2002 00:27:26 +0100
Received: from ( []) by (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g83NRN813030 for <>; Wed, 4 Sep 2002 00:27:23 +0100
Message-ID: <>
Date: Wed, 04 Sep 2002 00:27:15 +0000
From: David Hopwood <>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
Subject: Re: [Cfrg] CCM
References: <> <>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Crypto Forum Research Group <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


"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

 - 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

 - 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)
     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.

- -- 
David Hopwood <>

Home page & PGP public key:
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

Version: 2.6.3i
Charset: noconv

Cfrg mailing list