Welome to the Internet, here's your private key

[Bill Stewart]

At 05:12 PM 02/08/2002 +0100, Jaap-Henk Hoepman wrote:
>I think there _are_ good business reasons for them not wanting the users to
>generate the keys all by themselves. Weak keys, and subsequent 
>compromises, may
>give the CA really bad press and resulting loss of reputation (and this
>business is built on reputation anyway). So: there are good reasons not to
>let the CA generate the private key, but also good reasons to not let the user
>generate the keys all by himself.
>
>So the question is: are there key generation protocols for mutually 
>distrustful
>parties, that would give the CA the assurance that the key is generated using
>some good randomness (coming from the CA) and would give the user the 
>guarantee
>that his private key is truly private. Also, the CA should be able to verify
>later that the random data he supplied was actually used, but this should not
>give him (too much) advantage to find the private key.

There are three different cases
- Active malicious tampering by the user
- Inadequate key generation capabilities on the user's machine,
         e.g. weak randomness, too little memory, too slow CPU
- User's machine is compromised by some untrustable third party.

In the third case, you were toast anyway.
In the first case, what can malice accomplish that's different for a
         user-generated key as opposed to a CA-generated key?
         The malicious user could already give away his private key,
         and giving the CA a key generated by someone else to certify
         is pretty much equivalent to giving away the key.

The second case appears to be the interesting one.  There may be limited
         environments where the user's system doesn't have enough CPU or RAM
         (though someone else replied that even smartcards are often smart 
enough),
         but certainly for anything as smart as a Palm3,
         it's basically just a one-time startup delay.

         The way to fix inadequate randomness is not to have the CA 
generate the key,
         it's to have the CA generate a bunch of randomness and
         send it to the user's system to input it in the key generation 
program.
         If you're worried that the user might not bother to enter the
         randomness into the CA-supplied key generation program,
         have the program check that the user entered enough characters,
         or even use a checksum on the user-entered characters.

         If you're worried about Man In The Middle attacks on the
         CA-supplied randomness, you could digitally sign it, though
         that's a bit long-winded for user-typed strings
         unless you use Elliptic Curves or some similar short-signature
         method or use an HMAC or something.

Are there any other cases in which the CA needs to generate the key
for legitimate reasons, as opposed to because the CA wants access to
the user's private key for later purposes?


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com