Re: replay field size

Stephen Kent <kent@bbn.com> Thu, 13 February 1997 04:00 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA01858 for ipsec-outgoing; Wed, 12 Feb 1997 23:00:14 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007802af283be65307@[128.33.229.246]>
In-Reply-To: <199702121320.OAA09687@digicash.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 12 Feb 1997 22:37:19 -0500
To: Niels Ferguson <niels@DigiCash.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: replay field size
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

Niels,

	It's true that a shorter hash makes it easier to find a collision,
for a given packet, assuming a brute force search.  However, Hugo's
argument suggests that because of the way we are using the hash, truncation
may make it even harder to work backwards to find the key, which poses the
really significant concern in this environment.  I agree with your
observation that spending another 4 bytes is not so bad in the grand scheme
of things, but we have made similar tradeoffs in IPSEC (look at the
shortened IV techniques) before, so we have to decide why to draw the line
here.

Steve