Hacker News Reader

Comment by cius | Hacker News Reader

Your docs say: client uses private key to encrypt -> server uses public key to decrypt.

Do you mean: client uses private key to sign -> server uses public key to verify?

My understanding is private keys decrypt/sign and public keys encrypt/verify. Either your usage, your docs, or my understanding seem to be wrong. I think I'll stick with fwknop for now.

View on HN

RSA allows encrypting with the private key, see https://github.com/beac0n/ruroco/blob/ce766751b51c8ff6246a2b...

and decrypt with the public key, see https://github.com/beac0n/ruroco/blob/ce766751b51c8ff6246a2b...

using RSA, one can easily derive the public key from its private key (see https://security.stackexchange.com/questions/172274/can-i-ge...), that's why the private key is kept safely on the client

Also for SSH the public key is also stored on the server, while the private key is kept safely on the client, see https://www.ssh.com/academy/ssh/public-key-authentication#ke...

SSH can also be used with RSA: https://www.ssh.com/academy/ssh/keygen#creating-an-ssh-key-p...

Encrypting with the private key has the name “signing” because it’s convenient. Both are technically correct.

It sounds like my misunderstanding. So is this just a nomenclature mix up? I'll have to do more research, because I am under the impression there is something special about the private key other than the fact it was designated as such at generation time. I have many holes to fill in my knowledge around this.

The special thing about the private key is that if you have the private key you can also derive the public key from it. Meanwhile if you only have the public key you can't derive the private key.

Hence you always use the private key for decrypting or for signing. But other than switching which key to use signing and encrypting are the same thing

I think some of this is starting to come into focus. It appears the way these keys are commonly stored necessitates careful treatment after generation. For instance, if this reference is accurate, an RSA private key in PKCS#1 includes the p and q prime factors on which the whole security of the key pairs depends, so you certainly would not want to mix up the files: https://crypto.stackexchange.com/a/79606

Perhaps this helps: While fundamentally, in theory, they (keys and operations) are symmetric, many higher-level cryptographic protocols and their implementation do have differences (such as the private key also embedding the public key, or encryption being hybrid-symmetric). If the abstraction level is not obvious from context and you are still learning, this can be confusing.

Thank you, I think this helped me understand a bit more how higher level protocols impose further restrictions on use: https://crypto.stackexchange.com/a/71362

I think that's only true if you're using direct asymmetric cryptography. In the real world people use hybrid asymmetric cryptography.

Hybrid asymmetric signing is: hash the payload, then use direct asymmetric encryption/signing to encrypt/sign the hash with the private key.

Hybrid asymmetric encryption is: encrypt the payload with symmetric encryption (e.g. AES) with a random key, then encrypt the random key with direct asymmetric encryption using the public key.

As you can see, with hybrid asymmetric cryptography, there's a difference between signing and encryption besides the public vs private key difference.

Reply on news.ycombinator.com