Would be interesting to see some numbers for some (actually) low powered hardware. An i5 from a year ago taking almost a quarter of a second doesn't sound to great in my book.
A couple years ago I ran tests on an embedded Broadcom platform (7413, clocked at 400MHz IIRC) because I wasn't sure what was reasonable for SSL certificates when a box like that was involved.
I ended up using 2048 for both the client and server certificates. 4096 on the client would have taken several seconds to negotiate, and 4096 on the server was too expensive for the number of clients I wanted to pack onto a single server. (Also, I didn't have proper control of the entire client software stack, and the behavior of part of it with regard to session management and keepalive was extremely non-optimal.)
Based on that experience, I don't think I'd really want to use a 16384-bit key on a low-resource system anytime soon. Right now, 2048 ought to be plenty for any information that doesn't have to be kept secret over a very long time horizon (decades, at least), and anything over 4096 is getting pretty paranoid. 16384 seems obscene.
Yes can imagine some digital archaeologist in a few hundred years time thinking they have hit Indiana Jones payday only to get his mom's receipe for flapjacks.
This may be one way in curtailing bring your own device mentalities but beyond that any security system is always a compromise in one way or another. Also it is only as strong as the weakest link and if your the only user logged onto the box via ssh and others have weaker keys then you start to see the flaws.
But if everybody who logs on uses the same level of security, then it is that secure, otherwise it realy is down to the weakest link and even a home box can be taken out by a house cat who can't even use the vi editor.
This is a valid point however unfortunately is limited to systems running recent versions of OpenSSH; ECSDA is relatively new. If you connect to a large amount of boxes (as do I), your ECDSA simply will not work on older pre-ECDSA versions of OpenSSH.
That said, nothing preventing you having a mixture of keys for different hosts and modifying your ssh_config to use the correct key dependant on the domain.
I would like to point out that you can not future-proof anything that's security-related. You must have a plan to be able to upgrade or replace any security measures you have today, because the chance they'll be broken in your lifetime is extremely high.
21 comments
[ 3.1 ms ] story [ 65.5 ms ] threadI ended up using 2048 for both the client and server certificates. 4096 on the client would have taken several seconds to negotiate, and 4096 on the server was too expensive for the number of clients I wanted to pack onto a single server. (Also, I didn't have proper control of the entire client software stack, and the behavior of part of it with regard to session management and keepalive was extremely non-optimal.)
Based on that experience, I don't think I'd really want to use a 16384-bit key on a low-resource system anytime soon. Right now, 2048 ought to be plenty for any information that doesn't have to be kept secret over a very long time horizon (decades, at least), and anything over 4096 is getting pretty paranoid. 16384 seems obscene.
/s
But if everybody who logs on uses the same level of security, then it is that secure, otherwise it realy is down to the weakest link and even a home box can be taken out by a house cat who can't even use the vi editor.
Though the cat was there for grammatic effect I will admit.
Use this: ssh-keygen -b 521 -t ecdsa
That's (a lot) faster than RSA 16384 bit keys. A 200bit ECDSA key is +- (there's many factors involved) equivalent to a 2048bit RSA key.
Also the 521bit ECDSA not only verifies faster, it generates instantly (on current hardware), instead of taking a few coffess with the 16K RSA.
Finally, remember that, by the time we've enough computer power to brute force either of the above, one of these will probably happen:
- RSA or ECDSA may be logically broken
- you will be dead
- the hardware and software will not run anymore
- a new computer power breakthrough will make the choice of strength and cipher irrelevant (one can hope)
That said, nothing preventing you having a mixture of keys for different hosts and modifying your ssh_config to use the correct key dependant on the domain.
Both are very secure, but ECDSA will not have the long negotation times. Problem solved?