RE: Counter Mode Security: Analysis and Recommendations
"David A. Mcgrew" <mcgrew@cisco.com> Mon, 18 November 2002 03:26 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAI3QJg27572; Sun, 17 Nov 2002 19:26:20 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA02406 Sun, 17 Nov 2002 21:52:02 -0500 (EST)
From: "David A. Mcgrew" <mcgrew@cisco.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>, ipsec@lists.tislabs.com
Subject: RE: Counter Mode Security: Analysis and Recommendations
Date: Sun, 17 Nov 2002 18:45:58 -0800
Message-ID: <FPELKLHKCBJLMMMNOGDFCEOEEIAA.mcgrew@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <20021117023134.GA753@think.thunk.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Ted, here is a long-winded reply and a suggested direction for the ipsec counter mode draft. First, thanks for your feedback, I realize that I need to be more clear on the point that you brought up. Randomly setting the initial value of the 64-bit explicit IV of draft-ietf-ipsec-ciph-aes-ctr-01 does *not* protect against the precomputation attacks described in the writeup. This is because all values of that IV will be used during the lifetime of a key. So an attacker can pick any value of the IV during its precomputation stage, then wait for the corresponding packet to appear in the data stream protected by a particular key before attacking that key. If the attacker does not store the ciphertext contained by the packets that were sent previous to the IV value used in the precomputation, she will not be able to decipher those packets. However, this does not seriously impair the effectiveness of the attack, since on average 1/2 of the plaintext will be decipherable by the attacker. What I'm suggesting is that there be a distinct field in in the counter which is unpredictable. In principle, counter mode *can* have a 64-bit randomizer because the limitation that no more than 2^64 blocks can be generated implies that 64 bits suffice to index all of those blocks. So the block counter and IV fields together need not occupy more than 64 bits. Here's a concrete proposal: reduce the block counter to 16 bits and the IV to 48 bits, and replace the 'truncated spi' field with a 56-bit field that is set randomly at key setup time. This field should be considered part of the key, so that key setup is easy. This proposal has the following advantages: better security than the current draft, and the independence of the cipher from the SPI allocation. It has the following minor disadvantage: it cannot encrypt ipv6 jumbograms. As an aside, the 8-bit 'flags' field prevents us from making the randomizer field 64 bits long. I'd prefer 64 bits but would happy to get 56. An important point about the current draft is that, while it aims to admit a variety of implementation strategies, it excludes the cryptographically conservative one. In my opinion, that would be a mistake. In the interest of moving the WG forward on the issue, I suggest that we solicit WG input on the following questions: 1) is a security level lower than that recommended for commercial encryption (88 bits) considered acceptable? 2) is a limitation to encrypting packets less than 64kb in length considered acceptable? 3) if you could answer "yes" to only one of the above questions, which would it be? 4) is it acceptable to implement AES-192 or AES-256 and use those ciphers for counter mode? Or is it desirable to use AES-128 for both CBC and counter mode? Knowing the WG sentiment on these topics will enable us to make a dispassionate evaluation. It is late and I'm tired, and I may have missed decision point, so I invite others to propose questions as well. For the record, I am still of the opinion that omitting the explicit IV in order to cut down on the size of the packet is worthwhile. However, I'm neglecting that issue in order to focus the discussion on the security issue, which is certainly more important. David > -----Original Message----- > From: Theodore Ts'o [mailto:tytso@mit.edu] > Sent: Saturday, November 16, 2002 6:32 PM > To: David A. Mcgrew > Cc: Paul Hoffman / VPNC; ipsec@lists.tislabs.com > Subject: Re: Counter Mode Security: Analysis and Recommendations > > > Hi David, > > Barbara and I held off issuing a last call on > draft-ietf-ipsec-ciph-aes-ctr-01 on Friday because Barbara indicated > to me that she had talked to you, and she had told you that you were > about to publish a five-page writeup documenting a security > shortcoming in the current I-D that was about to be published. I assume > that this writeup is the one that you were referring to: > > > http://www.mindspring.com/~dmcgrew/ctr-security.pdf > > Having read your writeup, I'm confused how this applies to > draft-ietf-ipsec-ciph-aes-ctr-01. The basic summary of your writeup > seems to be (1) the IV needs to be 64 bit, (2) it needs to be > unpredictable, and a good way to do this is to generate the IV using a > counter starting at an unpredictable random value. > > The current ID specifies the use of a 64-bit explicit IV, which can be > set by the sender in any fashion which is convenient for the sender, > as long as the requirement that an IV is never reused for a particular > key. There is even text in the security requirements section which > covers the topic of precomputation attacks. > > Perhaps it could be made more explicit in the light of your comments > by adding a recommendation that if the sender is using an incrementing > counter or an LFSR to generate the IV, an unpredictable starting value > for the counter or LFSR would be a good idea. Not starting the IV at > zero would seem to me to be self-evident, but sometimes stating such > things explicitly for the benefit of the college intern implementing > from the RFC is a good thing. > > Did I miss anything from your counter-mode security writeup? > > - Ted
- draft-ietf-ipsec-ciph-aes-ctr-00.txt David A. Mcgrew
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Black_David
- re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Klaus Helbig
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt David A. Mcgrew
- Draft on providing Authentication/Confidentiality… Mukesh Gupta
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Stephen Kent
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt David A. Mcgrew
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt David A. Mcgrew
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Alex Alten
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Scott Fluhrer
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt David A. Mcgrew
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Alex Alten
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Alex Alten
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt David A. Mcgrew
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt David R. Oran
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Uri Blumenthal
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Uri Blumenthal
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Dilkie, Lee
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Alex Alten
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Henry Spencer
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Andrew Krywaniuk
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Paul Koning
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Scott Fluhrer
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Paul Koning
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt David A. Mcgrew
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt David A. Mcgrew
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt David A. Mcgrew
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Stephen Kent
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Jan Vilhuber
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt David A. Mcgrew
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Stephen Kent
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt David A. Mcgrew
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Michael Richardson
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Jan Vilhuber
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Stephen Kent
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Paul Hoffman / VPNC
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt David A. Mcgrew
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt David A. Mcgrew
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Scott Fluhrer
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Waterhouse, Richard
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Steven M. Bellovin
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Waterhouse, Richard
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Stephen Kent
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Henry Spencer
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Michael Richardson
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Alex Alten
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Michael Richardson
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Alex Alten
- hardware vs software (was Re: draft-ietf-ipsec-ci… Henry Spencer
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Waterhouse, Richard
- Re: hardware vs software (was Re: draft-ietf-ipse… Alex Alten
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Stephen Kent
- Re: hardware vs software (was Re: draft-ietf-ipse… Stephen Kent
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Paul Koning
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Arne Ansper
- RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Henry Spencer
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Arne Ansper
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Stephen Kent
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Stephen Kent
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt The Purple Streak, Hilarie Orman
- Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Housley, Russ
- Counter Mode Security: Analysis and Recommendatio… David A. Mcgrew
- Re: Counter Mode Security: Analysis and Recommend… Theodore Ts'o
- RE: Counter Mode Security: Analysis and Recommend… David A. Mcgrew
- RE: Counter Mode Security: Analysis and Recommend… Housley, Russ
- RE: Counter Mode Security: Analysis and Recommend… Paul Koning
- Re: Counter Mode Security: Analysis and Recommend… Bill Sommerfeld
- Re: Counter Mode Security: Analysis and Recommend… Paul Koning
- RE: Counter Mode Security: Analysis and Recommend… The Purple Streak, Hilarie Orman
- RE: Counter Mode Security: Analysis and Recommend… David A. Mcgrew
- RE: Counter Mode Security: Analysis and Recommend… Bob Doud
- Re: Counter Mode Security: Analysis and Recommend… Theodore Ts'o
- RE: Counter Mode Security: Analysis and Recommend… Alex Alten
- Re: Counter Mode Security: Analysis and Recommend… Paul Koning
- RE: Counter Mode Security: Analysis and Recommend… Paul Koning
- RE: Counter Mode Security: Analysis and Recommend… Bob Doud
- RE: Counter Mode Security: Analysis and Recommend… Mukund, Shridhar
- RE: Counter Mode Security: Analysis and Recommend… Michael Thomas
- RE: Counter Mode Security: Analysis and Recommend… David A. Mcgrew
- Re: Counter Mode Security: Analysis and Recommend… Stephen Kent
- Re: Counter Mode Security: Analysis and Recommend… Paul Koning
- Re: Counter Mode Security: Analysis and Recommend… Uri Blumenthal
- Re: Counter Mode Security: Analysis and Recommend… Stephen Kent
- Re: Counter Mode Security: Analysis and Recommend… Stephen Kent
- RE: Counter Mode Security: Analysis and Recommend… David A. Mcgrew
- RE: Counter Mode Security: Analysis and Recommend… Alex Alten
- RE: Counter Mode Security: Analysis and Recommend… Paul Koning
- RE: Counter Mode Security: Analysis and Recommend… Mukund, Shridhar
- RE: Counter Mode Security: Analysis and Recommend… David A. Mcgrew
- RE: Counter Mode Security: Analysis and Recommend… Stephen Kent