OpenSSH Keys: A Walkthrough(kyleisom.net)
kyleisom.net
OpenSSH Keys: A Walkthrough
https://kyleisom.net/articles/ssh_keys.html
7 comments
When most people think of SSH keys, they probably think of RSA if they’re aware of the underlying cryptography. Until recently, they would be right: RSA has been a mainstay of public key cryptography for some time now, and although it’s on the way out for new protocols and systems, it will be around for quite some time.
Why is RSA on the way out? This is news for me. Are there any (potential) weaknesses that have been discovered recently in the RSA? I know that elliptic curve cryptography has shorter (and hence somewhat more convenient) keys, but that fact alone hardly makes RSA obsolete. Are there anything else?
Why is RSA on the way out? This is news for me. Are there any (potential) weaknesses that have been discovered recently in the RSA? I know that elliptic curve cryptography has shorter (and hence somewhat more convenient) keys, but that fact alone hardly makes RSA obsolete. Are there anything else?
RSA is still secure with a few caveats.
1. It isn't secure against quantum computing attacks. Granted neither are elliptical curve based cryptosystems, so this isn't the motivation for switching.
2. It requires complicated padding schemes to prevent certain classes of attacks. The padding schemes do succeed at solving this problem, but they add a layer of complexity, and are often done incorrectly by inexperienced crypto users.
3. It is speculated that there are additional attacks based on math that hasn't yet been discovered. There is some speculation that the NSA has/is/will break RSA using these types of attacks.
4. There are a huge number of potential side channel attacks based on weirdness with how RSA key's affect the computation performed during encryption/decryption. Like with #2, there are ways around it, but it can still cause problems.
That said, if you use reasonable sized keys (2048 bit or larger), use libraries implemented by professionals with the correct options enabled, and you are worried about garden variety attacks, not the NSA, you are probably fine with RSA. Some people are starting to think that they are a little to much to bear, particularly when elliptic curves solve a lot of the problems and have smaller key sizes and faster computation.
Side note: But for a few exceptions, any processor on the market today (including mobile/embedded) could easily establish an SSH session using RSA without it being a significant cost. RSA (and Elliptic curve cryptography) is only used at the beginning of the session to establish a symmetric session key.
1. It isn't secure against quantum computing attacks. Granted neither are elliptical curve based cryptosystems, so this isn't the motivation for switching.
2. It requires complicated padding schemes to prevent certain classes of attacks. The padding schemes do succeed at solving this problem, but they add a layer of complexity, and are often done incorrectly by inexperienced crypto users.
3. It is speculated that there are additional attacks based on math that hasn't yet been discovered. There is some speculation that the NSA has/is/will break RSA using these types of attacks.
4. There are a huge number of potential side channel attacks based on weirdness with how RSA key's affect the computation performed during encryption/decryption. Like with #2, there are ways around it, but it can still cause problems.
That said, if you use reasonable sized keys (2048 bit or larger), use libraries implemented by professionals with the correct options enabled, and you are worried about garden variety attacks, not the NSA, you are probably fine with RSA. Some people are starting to think that they are a little to much to bear, particularly when elliptic curves solve a lot of the problems and have smaller key sizes and faster computation.
Side note: But for a few exceptions, any processor on the market today (including mobile/embedded) could easily establish an SSH session using RSA without it being a significant cost. RSA (and Elliptic curve cryptography) is only used at the beginning of the session to establish a symmetric session key.
#2 is often done incorrectly even by experienced users. After a padding error, it's really hard to keep going forward long enough without returning an early error.
How is this relevant in the context of setting up a connection protected by DH and RSA? Yes, it would be a problem any time you decrypt RSA. So pgp is tricky, but setting up a ssh or tls connection without DH is beyond foolish. For signature verification, there is no way that an adversary can gain anything by inserting a padding violation.
Assuming properly authenticated data, then decrypting without checking padding is no problem. For RSA encryption, padding only protects the sender. By itself RSA encryted data cannot be trusted, you need separate integrity protection for that.
Assuming properly authenticated data, then decrypting without checking padding is no problem. For RSA encryption, padding only protects the sender. By itself RSA encryted data cannot be trusted, you need separate integrity protection for that.
There are attacks against RSA signatures when padding is omittted.
Obviously. But for checking the padding on a signature you only need the public key. So you cannot leak any sensitive RSA key material while checking the padding.
Padding attacks don't leak key material; they leak plaintext.
RSA is very difficult to implement correctly and has a great number of caveats there. Generating keys is a very complex process, which is very slow compared to (some) ECC systems.
RSA is an asymmetric system that gives you: 1.) eternal signatures 2.) encryption. But today we often don't want that anymore (eg. in instant messaging), instead we want:
- Forward secrecy, necessitating ephemeral keys and DH: but RSA keys can't be feasibly generated for each message or connection. Compared to eg. 25519-based ECC, where generating a key pair is 1.) generate 32 random bytes 2.) curve multiplication, meaning that you can generate many thousand keys/second/core.
- Authenticity, not signatures, hence again DH + MACs, not RSA signatures.
RSA is an asymmetric system that gives you: 1.) eternal signatures 2.) encryption. But today we often don't want that anymore (eg. in instant messaging), instead we want:
- Forward secrecy, necessitating ephemeral keys and DH: but RSA keys can't be feasibly generated for each message or connection. Compared to eg. 25519-based ECC, where generating a key pair is 1.) generate 32 random bytes 2.) curve multiplication, meaning that you can generate many thousand keys/second/core.
- Authenticity, not signatures, hence again DH + MACs, not RSA signatures.
This isn't really accurate. It is true that ECDSA key generation is faster than RSA, but particularly in the context of SSH this doesn't matter. Also, I think you may be confusing ECDH and ECDSA. ECDSA (which is what the article is recommending) is the directly analogous to RSA in the sense that it provides eternal signatures. ECDH provides for generating individual session keys, but you can do that with classic Diffie Hellman as well, it is a completely separate issue from RSA vs EC.
Also, this line doesn't make any sense: "Authenticity, not signatures, hence again DH + MACs, not RSA signatures."
You need an signature to have authenticity. The only alternative to this is pre-exchanging symmetric keys which isn't viable in the context of SSH.
Also, this line doesn't make any sense: "Authenticity, not signatures, hence again DH + MACs, not RSA signatures."
You need an signature to have authenticity. The only alternative to this is pre-exchanging symmetric keys which isn't viable in the context of SSH.
You're correct, I'm not referring to SSH specifically, but speaking generally about the application of asymmetric crypto. The quote in GP, and GP's question, both seemed to indicate this broader context to me.
Even in a broader context, Symmetric keys based MACs vs signatures is a completely separate question from RSA vs EC.
(Also, obviously RSA does not do DH or a similar mechanism for establishing a shared secret. The workaround is to generate ephemeral keys and sign their public keys with RSA, then generating a shared secret from the ephemeral keys. This is what eg. TLS does in principle, but also shows that RSA still has it's uses: RSA signatures for long-term proofs of identity, ECC for forward-secure communication.)
There are also other caveats. Eg. EC keys tend to be tiny, just like symmetric keys, so one can much more easily distribute them through eg. QR codes, or even read them out loud. RSA keys, not so much.
If ECC fits the application well then using eg. Curve25519-based crypto over RSA or other EC is pretty much a no-brainer: it's, by a large margin, the asymmetric crypto systems with the fewest caveats both in implementation and application, and it's also very fast for any operation.
There are also other caveats. Eg. EC keys tend to be tiny, just like symmetric keys, so one can much more easily distribute them through eg. QR codes, or even read them out loud. RSA keys, not so much.
If ECC fits the application well then using eg. Curve25519-based crypto over RSA or other EC is pretty much a no-brainer: it's, by a large margin, the asymmetric crypto systems with the fewest caveats both in implementation and application, and it's also very fast for any operation.
RSA signatures are valuable in TLS because the installed base uses RSA, not because you need RSA to solve the problem RSA solves in TLS. There are better ECC constructions for signing and verifying.
RSA is safe. You should keep using it. Modern crypto is starting to use ECDSA because smaller key size means faster computation, but you wouldn't notice the difference in SSH anyway.
More info: https://wiki.mozilla.org/Security/Guidelines/OpenSSH
More info: https://wiki.mozilla.org/Security/Guidelines/OpenSSH
The link prefers Ed25519 over RSA and uses ECDSA last where possible. It's faster and some also trust djb's work on curves over that from NIST.
(edit: this is wrong, see below.)
> Modern crypto is starting to use ECDSA because smaller key size means faster computation, but you wouldn't notice the difference in SSH anyway.
If you're using SSH for tiny bits of text (eg: bash) you won't.
If you're using SSH to move gigabytes of binary data (eg: rsync) you might.
> Modern crypto is starting to use ECDSA because smaller key size means faster computation, but you wouldn't notice the difference in SSH anyway.
If you're using SSH for tiny bits of text (eg: bash) you won't.
If you're using SSH to move gigabytes of binary data (eg: rsync) you might.
> If you're using SSH to move gigabytes of binary data (eg: rsync) you might.
No.
RSA or other asymmetric crypto is only used during connection establishment for authentication. Then symmetric key is established using DH and you use symmetric encryption to encrypt the data.
No.
RSA or other asymmetric crypto is only used during connection establishment for authentication. Then symmetric key is established using DH and you use symmetric encryption to encrypt the data.
That makes perfect sense. Apologies for spreading incorrect information, and thanks for correcting me.
I remember changing around my ssh config a while back and seeing lower speeds when rsync'ing from an older laptop. But that makes sense, I recall cranking up my DH group to 16, 4096-bit, and that was probably why it was struggling.
I remember changing around my ssh config a while back and seeing lower speeds when rsync'ing from an older laptop. But that makes sense, I recall cranking up my DH group to 16, 4096-bit, and that was probably why it was struggling.
No, not at all.
What you do notice is using ciphers that are apt for the machine. If both ends are modern x86, for example, then you'd want to use [email protected] or [email protected] for best performance. Otherwise stick to [email protected], which is the default of recent versions.
What you do notice is using ciphers that are apt for the machine. If both ends are modern x86, for example, then you'd want to use [email protected] or [email protected] for best performance. Otherwise stick to [email protected], which is the default of recent versions.
[deleted]
dqv(1)
Very clear and informative!
I got lost at this part, if anyone could clarify that would be great:
3. The key uses the PKCS#5 padding scheme: the last byte contains the number of padding bytes; e.g. if there are 5 bytes of padding, it contains 0x05. The last five bytes of the plaintext should then be 0x05 (something you should validate if you are decrypting the key yourself). If you decrypt the key above, you’ll see the last eight bytes are, in fact, 0x08.
The key is the MD5 of the combination of IV+pass, so how could the last byte of the key be controllable? The last two bytes shown are 532b, which is not 0x08? I must be missing some step that happens between getting the MD5 and this padding scheme.
I got lost at this part, if anyone could clarify that would be great:
3. The key uses the PKCS#5 padding scheme: the last byte contains the number of padding bytes; e.g. if there are 5 bytes of padding, it contains 0x05. The last five bytes of the plaintext should then be 0x05 (something you should validate if you are decrypting the key yourself). If you decrypt the key above, you’ll see the last eight bytes are, in fact, 0x08.
The key is the MD5 of the combination of IV+pass, so how could the last byte of the key be controllable? The last two bytes shown are 532b, which is not 0x08? I must be missing some step that happens between getting the MD5 and this padding scheme.
> One of the ideas I’ve also been tossing around is using Github’s public key API to provide a way to sign PGP keys using Github SSH keys. I have much of the groundwork laid out, but I need to actually code everything up.
If you didn't know: you can use a gpg key as an ssh key. You configure gpg-agent to act as an ssh-agent. This is quite popular for those that use yubikeys.
If you didn't know: you can use a gpg key as an ssh key. You configure gpg-agent to act as an ssh-agent. This is quite popular for those that use yubikeys.
Howdy, just a FYI here - your site doesn't display properly on mobile devices, it's all squashed into a tiny column in the middle of the page and the text wrapping is warped in places, additional if you're using Safari the 'reader view' is not available to clean the page and make it more readable.
on Firefox-mobile, if you request the desktop site and double-tap on the first paragraph, it displays fine (not ideal)
Hmm, what I've always wondered: why can't I have the SSH public key of the server signed/certified the same way as a SSL public key?
That could e.g. allow me to specify "mark all SSH keys certified by company-internal CA as trusted" or putting the expected certificate into DNS...
That could e.g. allow me to specify "mark all SSH keys certified by company-internal CA as trusted" or putting the expected certificate into DNS...
This exists - http://man7.org/linux/man-pages/man1/ssh-keygen.1.html#CERTI... - though the tooling is a bit bare-bones. There are some tools written to use certificates though, such as Netflix's BLESS (https://github.com/Netflix/bless), Gravitational Teleport (https://github.com/gravitational/teleport) and my own (https://github.com/nsheridan/cashier)
This has actually been a feature in OpenSSH since 5.4, see https://blog.habets.se/2011/07/OpenSSH-certificates.html or the CERTIFICATES section of `ssh-keygen(1)`.
similarly, x.509 is supported in a variant[0] of OpenSSH. For certain kinds of devices, this may be preferable.
[0]http://roumenpetrov.info/secsh/
[0]http://roumenpetrov.info/secsh/
Facebook does something similar with SSH-access to their infrastructure.
https://code.facebook.com/posts/365787980419535/scalable-and...
https://code.facebook.com/posts/365787980419535/scalable-and...
We can tell from the length field that we need to read 0x00000101 (or 257) bytes; 257 8 = 2056 bytes, which is in the range for a 2048-byte RSA key (with some of the bits going unused).
That's backwards - 65537 is a common public exponent. The modulus is the 2048-bit long thing.
Also, the writer says "2048-byte" RSA key when it's really 2048-bits.