Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.txt
Bart Preneel <Bart.Preneel@esat.kuleuven.ac.be> Wed, 12 December 2001 22:35 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 fBCMZ7209819; Wed, 12 Dec 2001 14:35:07 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20473 Wed, 12 Dec 2001 16:52:52 -0500 (EST)
Date: Wed, 12 Dec 2001 23:02:09 +0100
From: Bart Preneel <Bart.Preneel@esat.kuleuven.ac.be>
To: Paul Koning <pkoning@equallogic.com>
cc: ipsec@lists.tislabs.com
Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.txt
In-Reply-To: <15383.48863.893728.721499@pkoning.dev.equallogic.com>
Message-ID: <Pine.GHP.4.33.0112122244540.6259-100000@domein.esat.kuleuven.ac.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
There are 2 conflicting concerns here: 1. having a longer MAC implies that each MAC leaks more information on the MAC key (in an information theoretic sense, but for some weaker MAC functions such information can be exploited - there are no indications that this is the case for HMAC, but it never hurts to be careful). 2. having a shorter MAC means that the MAC string may be easier to predict for a given message (for example, it may be that one can predict the first 80 bits of a MAC easily, but not the full 128 bits). Personally I believe that the first concern is more important, as it deals with key leakage while the second concern is about forging a single MAC. The "optimal" choice from this viewpoint (based on birthday attacks) is that the size of the MAC should be exactly half the size of the hash function output, and that the size of the key should be the size of the hash output. This would lead to choosing a 128-bit output for SHA-256. For obvious reasons, it does not make sense to choose a MAC length longer than the key (the opponent just guesses the key rather than the MAC value). If I remember correctly, 96 bits was chosen over 80 bits because of word alignment issues (and because some people worried more about concern 2). For choosing MAC parameters, one has to take into account the lifetime during which the system will be used (rather than the lifetime of a single key). I believe that 80-bit MACs are sufficient for 20 years or more. A MAC of 96 bits may be chosen for the alignment reasons mentioned above. A MAC of 128 bits is fine but probably too conservative; anything larger is certainly overkill and may even harm security in the long run. Bart Preneel On Wed, 12 Dec 2001, Paul Koning wrote: > >>>>> "Shoichi" == Shoichi Sakane <sakane@kame.net> writes: > > >> Title : The HMAC-SHA-256-96 Algorithm and Its Use With IPsec > >> Author(s) : S. Frankel, S. Kelly Filename : > >> draft-ietf-ipsec-ciph-sha-256-00.txt Pages : 8 Date : 16-Nov-01 > > Shoichi> the section 5 in RFC2104 says, > > > We recommend that the output length t be not less than half > > the length of the hash output (to match the birthday attack > > bound) and not less than 80 bits (a suitable lower bound on > > the number of bits that need to be predicted by an > > attacker). > > Shoichi> is that ok to truncate into 96bit ? > > Applying the text from 2104 says "no" and the length should instead be > 128 or more. > > Which makes me wonder: why was 96 chosen for the original 2 HMACs and > not 80? 80 would be the minimum value that satisfies the guideline > from RFC 2104. Should therefore the SHA-2 based HMAC use a length > greater than 128 bits? > > paul >
- I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.txt Internet-Drafts
- Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.t… Hugo Krawczyk
- Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.t… Shoichi Sakane
- Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.t… Paul Koning
- Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.t… Bart Preneel
- Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.t… Steven M. Bellovin
- Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.t… Bart Preneel