[14017] in cryptography@c2.net mail archive
Re: PRNG design document?
daemon@ATHENA.MIT.EDU (Joshua Hill)
Wed Sep 3 12:36:08 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Wed, 3 Sep 2003 08:25:54 -0700
From: Joshua Hill <josh-crypto@untruth.org>
To: Thor Lancelot Simon <tls@rek.tjls.com>
Cc: cryptography@metzdowd.com
In-Reply-To: <20030829194550.GA2214@rek.tjls.com>; from tls@rek.tjls.com on Fri, Aug 29, 2003 at 03:45:50PM -0400
On Fri, Aug 29, 2003 at 03:45:50PM -0400, Thor Lancelot Simon wrote:
> I think there's some confusion of terminology here. A "time", Ti for each
> iteration of the algorithm, is one of the inputs to the X9.17 generator
> (otherwise, you might as well just use DES/3DES in any chaining or feedback
> mode, for all practical purposes).
Indeed. One of the problems with ANSI X9.17's description of this PRNG
is that it isn't obvious that the implementation needs to re-sample DT
(it's date/time vector; NIST requires that this changes every round) and
re-encrypt it every round. (This error in interpretation is prevalent
enough that it is depicted incorrectly in the HAC and Counterpane's PRNG
attack paper).
ANSI X9.31 does a better job of specifying it.
> However, it has always been permitted
> to use a free-running counter instead of the time, and indeed the current
> interpretation by NIST *requires* that a counter, not the time, be used.
"always" is a strong term, but they have allowed it for the last 4 years
or so, anyway. I don't think that I've seen any guidance from NIST that
disallows an actual clock, but they do want the value to change every
round, so it would have to be a fast clock or a slow implementation to
fulfill the requirement in this way.
Josh
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
