>From: John Gilmore <[EMAIL PROTECTED]> >Sent: Sep 30, 2004 6:25 PM >To: [EMAIL PROTECTED], [EMAIL PROTECTED] >Subject: Re: Linux-based wireless mesh suite adds crypto engine support
>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. I think the need for interoperability constrains the ability for a crypto module to implement some weak algorithm in place of AES or 3DES. Unless the designer can know which encrypted messages have to be handled by someone else's non-hacked module, he can't safely do this. >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. I'll note that this is supported two separate ways in the (in progress) X9.82 standard. a. A standard way to produce a random bit generator with a guaranteed fallback to computational security is to XOR the outputs of some good hardware generator with the outputs of a crypto PRNG (aka DRBG in X9.82-ese). b. Any approved random bit generator can always be combined with an unapproved generator by XORing. The only security requirement here is that the unapproved generator be independent of the approved one. All that said, though, it's far from clear how you monitor this in the standard crypto environment, since you usually take great pains to make it hard for anyone to get key material out of the tamper-resistant modules. You provide the random value to XOR into the RNG output, and the module says "Thanks, I XORed it in. Trust me." Or, you demand the random value from its RNG, XOR in your own, but now, you've exposed the key outside the tamper-resistant module, which introduces a whole different set of problems. I'm sure there are some clever crypto protocol ways to address this (basically, do a zero-knowledge proof of the value of the random number you used in deriving the key), but I have a hard time thinking this is at all practical.... > John --John Kelsey --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
