[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: replay field size

To: Ran Atkinson <rja@inner.net>, Steven Bellovin <smb@research.att.com>
Subject: Re: replay field size
From: Ran Atkinson <rja@inet.org>
Date: Fri, 14 Feb 97 16:13:10 GMT Standard Time
Cc: ipsec@tis.com, Robert Glenn <glenn@snad.ncsl.nist.gov>, Stephen Kent <kent@bbn.com>
References: <199702131637.LAA02391@raptor.research.att.com>
Sender: owner-ipsec@ex.tis.com


Steve,

  For the case where the algorithm is DES, I have no problems with
your analysis.

  For the case where the algorithm is something new that appears in
future that might be significantly stronger, then the limit of 2^^32
might well be a significant issue.  With negotiable counter sizes or
per-algorithm counter sizes, this would not be an issue.  With a fixed
size counter, using 2^^32 for all time is an issue IMHO.  However,
a 2^^64 counter space would not have that issue and would still be
a fixed size counter.

  As to the 64-bit math, I'm not very concerned -- based on my work on
several different IPv6 implementations and the currently 128-bit
addresses (and the routing calculations that go along with that address
size).  This was NOT a problem on an Intel Pentium.

Ran
rja@inet.org

Follow-Ups:

Re: replay field size

From: Jim Thompson <jim@hosaka.smallworks.com>

References:

Re: replay field size

From: Steven Bellovin <smb@research.att.com>

Prev by Date: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News
Next by Date: Re: replay field size
Prev by thread: Re: replay field size
Next by thread: Re: replay field size
Index(es):
- Main
- Thread