[149178] in cryptography@c2.net mail archive
Re: [Cryptography] Auditing rngs
daemon@ATHENA.MIT.EDU (Thierry Moreau)
Tue Jan 21 16:57:14 2014
X-Original-To: cryptography@metzdowd.com
Date: Tue, 21 Jan 2014 16:18:58 -0500
From: Thierry Moreau <thierry.moreau@connotech.com>
To: John Kelsey <crypto.jmk@gmail.com>
In-Reply-To: <936A06C8-2200-42FC-97B8-41FA4C01261D@gmail.com>
Cc: Philip Shaw <wahspilihp@gmail.com>, Tom Mitchell <mitch@niftyegg.com>,
"cryptography@metzdowd.com" <cryptography@metzdowd.com>,
Bill Frantz <frantz@pwpconsult.com>, Kent Borg <kentborg@borg.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
John Kelsey wrote:
> It seems like it should be relatively straightforward to do a cut and choose style audit on a random bit generator. However, the functionality you would need for this would also be a hell of an attack point, so it's a mixed bag.
>
> Imagine you have an HSM that has its own entropy source. We want to have it do something that requires randomness, say generate an RSA key. So we do the following:
>
> HSM:
>
> a. Generate two entropy strings from its hardware entropy source, each estimated to have 512 bits of entropy. Call these E1 and E2.
>
> b. Output the SHA256 hash of each, call them H1 = hash(E1) and H2 = hash(E2).
>
> c. Input two additional input strings, each estimated to have 256 bits of entropy--call them A1 and A2.
>
> d. Using HMAC DRBG, instantiate drbg1 from E1 with personalization string A1, and drbg2 from E2 with personalization string A2.
>
> e. Use each drbg to generate its own new RSA keypair. Output keypair1 (from drbg1) and keypair2 (from drbg2).
>
> f. The user now knows H1, H2, A1, A2, keypair1, keypair2. He challenges either keypair1 or keypair2. Suppose he challenges keypair1. Then the HSM reveals E1, and the user can redo all the computations needed to derive keypair1. If he gets the same answer, he has some reason to trust keypair2.
>
> You can imagine redoing this process many times to get more assurance. However, it requires building a "leak the entropy input of my drbg" functionality into your HSM, which has some pretty obvious bad potential uses. (Lots of security proofs have a call the attacker can make to compromise the secret state to model leakage, but normally you don't actually build that functionality into your module!)
>
> Comments
>
You did not prove anything about the 512 bits entropy estimate. You
merely postulated it. The deterministic process from (Ex,Ax) to keypairx
may be audited like any other software logic implementation.
Regards,
--
- Thierry Moreau
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
