[8079] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: Lots of random numbers

daemon@ATHENA.MIT.EDU (Paul Crowley)
Sat Nov 18 14:24:18 2000

To: sommerfeld@orchard.arlington.ma.us
Cc: Don Davis <dtd@world.std.com>, Rich Salz <rsalz@caveosystems.com>,
        cryptography@c2.net
From: Paul Crowley <paul@cluefactory.org.uk>
Date: 17 Nov 2000 17:23:51 +0000
In-Reply-To: Bill Sommerfeld's message of "Fri, 17 Nov 2000 11:37:23 -0500"
Message-ID: <87em0aseag.fsf@hedonism.subnet.hedonism.cluefactory.org.uk>

Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> writes:

> > Eh?  You should *never* need to encrypt information before shoving
> > it in the pool.  If you've got a secret you could use for such
> > encryption, shove it in the pool and then forget about it - it will do 
> > precisely as much good.
> 
> I'm inclined to agree with Don here, from principles of conservative
> cryptographic engineering.  By using a keyed one-way function before
> adding data to the pool, you add an additional layer of defense
> against an attacker guessing the pool contents.

If you want to design a new kind of pool based on encrypting the
incoming data, that could be an effective way to do it, but it will be 
part of the pool.  If you start doing that sort of thing outside the
pool, you're just building a bigger pool around the pool you've
already got.  If the pool is Yarrow, then you will be very hard
pressed to build a better pool than the Yarrow designers, by this
strategy or any other.

Conservative cryptographic engineering says complexity is the enemy of
security.  Once you've chosen your components, trust them to do the
job they're designed for - don't pre-encrypt your encrypted data, and
don't build a randomness pool around your randomness pool.
-- 
  __
\/ o\ paul@cluefactory.org.uk
/\__/ http://www.cluefactory.org.uk/paul/


home help back first fref pref prev next nref lref last post