[16265] in cryptography@c2.net mail archive
Re: Linux-based wireless mesh suite adds crypto engine support
daemon@ATHENA.MIT.EDU (John Gilmore)
Mon Oct 4 16:57:12 2004
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
To: cryptography@metzdowd.com, gnu@toad.com
In-Reply-To: Message from pgut001@cs.auckland.ac.nz (Peter Gutmann)
of "Thu, 30 Sep 2004 17:05:15 +1200." <E1CCt7z-0005TQ-00@medusa01>
Date: Thu, 30 Sep 2004 15:25:57 -0700
From: John Gilmore <gnu@toad.com>
> >- sufficient documentation and really transparent provable details so that
> >users could trust and verify that the hardware and software were doing what
> >they claimed to be doing and weren't doing anything evil that they didn't
> >admit to, such as including backdoors or bad random number generators.
>
> Tinfoil hat stuff - why trust any crypto hardware then?
I don't -- do you?
Crypto hardware that does algorithms can be tested by periodically
comparing its results to a software implementation. Production
applications should probably be doing this -- maybe 1% of the time.
Crypto hardware that generates "random" numbers can't be tested in
production in many useful ways. My suggestion would be to XOR a
hardware-generated and a software-generated random number stream. If
one fails, whether by accident, malice, or design, the other will
still randomize the resulting stream. Belt AND suspenders will keep
your source of randomness from being your weakest link.
John
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
