John Wood asked: Hi all,
I just wanted to ask a question about RSA keys. I'm working on a peer to peer software project where public key cryptography is required to enable peer to peer authentication (at connection time the peers will sign a random challenge string to each other to prove their identity). There is a trusted central node which has all the public keys. We want our software to be really easy to use. To that end, we don't want to make the users have to look after their private keys. Also, since the product relates to data backup, we have to assume they will have lost their hard drive. We also don't want to store the Private Keys on the trusted central node (so we can truthfully say that we don't hold any of user's secrets). So, really all we want is that they have to remember a single password. So, to summarise, the requirements are: * Peers have to authenticate to each other (a trusted third party is available) * Peers must only need to remember a standard password (e.g. "abacus123") * Peers should not need to store RSA private keys anywhere at all (including on the trusted server) What we're proposing is as follows: 1) We initialise the random number generator (RNG) with the user's password (yes it will be a cryptographic RNG) 2) We generate the RSA keys from the primed RNG So, if they have hardware failure, they just need to re-enter their password and they'll get back their RSA private key (by re-priming the RNG and repeating the generation). I have two questions. Question 1 ------------------ What I'd like to know is, how insecure is our proposed scheme? Now, I totally understand that the "theoretical" answer is probably going to be "This is a bad idea because the randomness of your RNG has been compromised". However, what I'd really like to understand is what is the *real world* insecurity is. For example, if you're saying that you'd have to be a crytographic expert to be able to take advantage of this knowlege (i.e. that the RNG was primed with a password), then perhaps we might live with that. What I'm saying is that, I think this may be a trade off between usability and and security and I want to understand how much security we lose doing this. Question 2 ---------------- Can anyone suggest an alternative/better scheme which meets the requirements above? i.e. peers authenticating to each other using just a password? [I'm guessing that using hashes of passwords is a really bad idea because of play-back attacks] Thanks in advance for any help. John ----- My quick answer is that using passwords instead of real cryptography (with real key management) is almost always A Really Bad Idea, and that is true whether you are authenticating users, or authenticating credit cards. (Or, for that mater, doing pre-boot authentication to a FDE disk, where the PBE-protected key is stored on the media being protected, but that's a different discussion.) The ONLY time passwords or PINs should be used is to authenticate a user to a piece of hardware, with hardware enforced access control or timeouts to control how many attempts are allowed before access is blocked or the keys are zeroized. As a second-best solution, you can use a password to gain access to a server, so that offline password-guessing attempts are limited. (This assumes you are using something like SSL to protect the password from interception. Even then, you have to swallow a whole bunch of assumptions about man-in-the-middle attacks.) That's why FIPS 140-2 is generally required as a standard for these kinds of things, to kept people from throwing together bad solutions that look good to the uninitiated, but are trivial to break. Most people can't (or at least won't) remember a password longer than eight characters, and the rule of thumb is that a password of average complexity has about 3 bits of entropy per character. To have adequate protection, you would need on the order of a 35-character password. Good luck trying to impose that as a requirement! Now, is the equivalent of a 24-bit key good enough for your application? Maybe so, if your peer-to-peer network is a bunch of grade school kids trading bathroom jokes, and who don't want the other kids who are not in the "club" to know what they are saying about them. But if any "grown-ups" are involved (like anyone 14 or older with a computer), then no, it's almost hopelessly insecure. In summary, if you CARE about the quality of the authentication, then use a smart card or token to protect the private keys. Otherwise, just send it in the clear and keep the identity of the server a secret, as the chance that it will be intercepted over the internet is probably lower than the probability that your scheme can be broken, and clear text is even cheaper and easier to use! Robert Jueneman SPYRUS, Inc. _______________________________________________ FDE mailing list FDE@www.xml-dev.com http://www.xml-dev.com/mailman/listinfo/fde
