3 ms·

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

• jagged-chisel 2y ago
  Encrypting with the private key has the name “signing” because it’s convenient. Both are technically correct.
  • cius 2y ago
    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.
    • wongarsu 2y ago
      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
      • cius 2y ago
        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 https://crypto.stackexchange.com/a/79606
    • 3np 2y ago
      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.
      • cius 2y ago
        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 https://crypto.stackexchange.com/a/71362
  • Thorrez 2y ago
    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.
• mschempp 2y ago
  RSA allows encrypting with the private key, see https://github.com/beac0n/ruroco/blob/ce766751b51c8ff6246a2be02a0d028e8e880bcb/src/client.rs#L78 https://github.com/beac0n/ruroco/blob/ce766751b51c8ff6246a2b... and decrypt with the public key, see https://github.com/beac0n/ruroco/blob/ce766751b51c8ff6246a2be02a0d028e8e880bcb/src/server.rs#L171 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-get-a-public-key-from-an-rsa-private-key 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#key-pair---public-and-private 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-pair-for-user-authentication https://www.ssh.com/academy/ssh/keygen#creating-an-ssh-key-p...