
OpenSSH Keys: A Walkthrough - LaFolle
https://kyleisom.net/articles/ssh_keys.html
======
aftbit
"If you’ve seen the low level parts of RSA keys, you’ll immediately recognise
this. Otherwise, convert it to an unsigned integer and you get 65537 – a
common RSA modulus. RSA public keys require two pieces: the modulus and the
public exponent. Let’s take a guess that the next piece is going to be the
public exponent."

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.

------
mkup
_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?

~~~
dom0
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.

~~~
benchaney
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.

~~~
throwawayish
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.

~~~
benchaney
Even in a broader context, Symmetric keys based MACs vs signatures is a
completely separate question from RSA vs EC.

------
hamiltont
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.

~~~
bartbes
The "key" in that sentence, the one that gets padded, is the (RSA) private
key, not the AES key.

~~~
hamiltont
Got it, thanks!

------
daurnimator
> 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.

------
mrmondo
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.

~~~
awqrre
on Firefox-mobile, if you request the desktop site and double-tap on the first
paragraph, it displays fine (not ideal)

------
mschuster91
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...

~~~
lwf
This has actually been a feature in OpenSSH since 5.4, see
[https://blog.habets.se/2011/07/OpenSSH-
certificates.html](https://blog.habets.se/2011/07/OpenSSH-certificates.html)
or the CERTIFICATES section of `ssh-keygen(1)`.

~~~
yusyusyus
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/](http://roumenpetrov.info/secsh/)

------
contras1970
_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). _

