|
|
|
|
|
by tialaramex
2125 days ago
|
|
Three of these four algorithms are only for signing and although you can use RSA to do either, in SecSH (and thus modern SSH) it is only used for signing. So it's a red flag when articles like this start jabbering about using these signature algorithms for encryption: > This is what is meant by asymmetric encryption. [Figure 2] If Bob encrypts a message with Alice’s public key, only Alice’s private key can decrypt the message. This principle is what allows the SSH protocol to authenticate identity. If Alice (client) can decrypt Bob’s (server) message, then it proves Alice is in possession of the paired private key. This is, in theory, how SSH keys authentication should work. No. This isn't how SSH works, and it's confusing to me that people prefer to imagine how it could work rather than just read the specification. RFC4252 explains exactly how public key authentication is performed. Alice signs a standard message bound to this SSH session using her private key, and Bob can verify that this signature is correct using her public key. |
|
This part is also confusing. I feel like it is important to clarify that identity is not "established" using cryptography, rather verified. When Bob claims to be the Bob, you don't know and can't know just from this claim if Bob is indeed the Bob. To verify that this Bob is indeed the Bob, you have him certify from someone else that you trust that he is indeed the Bob (or you just certify it yourself when your computer asks you to trust a new fingerprint).