Generating 16384 Bit SSH Keys(aeg0.com)
aeg0.com
Generating 16384 Bit SSH Keys
http://www.aeg0.com/2012/09/27/generating-16384-bit-ssh-keys/
6 comments
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.
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.
Small ECDSA key by default, 16kbit RSA fallback?
Both are very secure, but ECDSA will not have the long negotation times. Problem solved?
Both are very secure, but ECDSA will not have the long negotation times. Problem solved?
I have the following in my ssh config file.
Host *
IdentityFile ~/.ssh/id_ecdsa
IdentityFile ~/.ssh/id_rsa
HashKnownHosts yes
VisualHostKey yesLooks like it's from OpenSSH 5.7 released on Jan 25, 2011.
Which is unfortunately a very new version compared to most distros. CentOS 6 for example has only 5.3. Debian Squeeze, 5.5. Ubuntu Precise, 5.9.
Even MacOS Lion does not support ECDSA.
[deleted]
Because more = better (obviously), and my keys are going to continue to have privileges on machines several hundred years from now.
/s
/s
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.
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.
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.
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.
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.
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.
How many housecats have you met that can use vi?
It's easier for them to use vi than emacs, because they don't have to use so many paws.
Clever cats press Ctrl with their tail.
anybody or animal can use vi, its the ability to do something meaningful that is the were most fall short.
Though the cat was there for grammatic effect I will admit.
Though the cat was there for grammatic effect I will admit.
github didn't seem to like that. I gave it my 16k pub-key. It gave me a 500 error :(
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)