Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Do I have to mind something specific when using public keys and SSH? Well of course, I have to keep my private key secret (and therefore I should choose a strong pass phrase). But is there something else? When running ssh-keygen is it a good idea to use the default options? The 2048bits are a good choice? I read somewhere that 4096 would be recommendable nowadays. Can I use a better random generator (e.g. user input)? Do I have to renew my key pair regularly just for the case that somebody else stole it without my knowledge? In what cases a validity interval should be used?

These are many questions, but I don think it would be usefull to split them up into several questions. I'm interested in the question what to look for, when dealing with SSH/public keys (also if there are aspects I haven't mentioned yet).

Related questions:

share|improve this question
add comment

1 Answer

up vote 6 down vote accepted

You should trust the default options of ssh-keygen and not try to fiddle with random sources and so on. These are delicate matters. You can rely on the OpenSSH developers for having done things correctly -- you can rely because you already rely on them for having done a proper, leak-free implementation of the OpenSSH protocol, something which is far from easy.

For RSA, DSA, ElGamal, Diffie-Hellman, and similar algorithms, 2048-bit keys are enough. Estimating the strength of such algorithms in a meaningful way is not easy, because the best known attack algorithms rely on an awful lot of raw CPU power but also memory, storage, data bandwidth, and applicability of parallel computing of linear algebra on huge spare matrices. So such estimates must guess how future computing architectures and envisioned specialized circuits will fare against a number of more-or-less orthogonal scales, and the whole thing is more about divination than scientific prediction. Nevertheless, some have tried to establish guidelines, see this site for a compendium of existing rulesets that have been published. For instance, NIST states that 2048-bit RSA or DSA keys are fine until at least year 2030; note that the same NIST says that 1024-bit RSA keys should not be used beyond 2010, and yet we are now in 2012 and nobody still knows how to actually crack a 1024-bit RSA key (current record is for a 768-bit RSA key).

You are right in protecting your private key storage. This does not necessarily calls for a passphrase, though: in some contexts, the private key may reside in a desktop systems which is physically protected, and that could be deemed secure enough. Yet, strong passphrases are a nice reflex to have, and I can only encourage them.

As for key renewal, I would rather advise against it. Key renewal is a relatively complex operation because you have to transport the public keys to all relevant places (the .ssh/authorized_keys on the servers to which you want to connect); if you forget one, then you will have to engage in a recovery procedure later on, and recovery procedures are, by definition, breaches of security. Controlled breaches, but breaches nonetheless. So you should renew your key only insofar as it helps you sleep at night, but key renewal is likely to be overdone. Remember that if an attacker can obtain your private key once, then he can plant his own public key in all the servers himself: changing your key will not stop him. So key renewal has relatively little impact on security anyway.

share|improve this answer
    
Thanks for your detailed and well explained answer! But you didn't convince me to refrain form key renewal. I could just keep my old private key, then there would be no need for a recovery procedure? (if the key is valid forever) But I didn't think about the attacker's possibility to plant his own public key in my system, that's a good hint. It means I'd have to check known_hosts very carefully on key renewal. –  lumbric Jan 12 '12 at 15:53
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.