-4

In the Public Key Cryptography all I know is that the public key in the server is to encrypt the message and the client which has the private key can decrypt that message which is fine.

The part which I don't understand is that as the server has only the public key to encrypt the message how it would decrypt the response from the client. I believe that the public can't be used to decrypt the response from the client.

Also how the client encrypts a message to the server as the private key is only used for decrypting the message and not for encrypting.

Sorry for my ignorance. I have searched the internet and somehow the answers to these are eluding from me.

Any help would be greatly appreciated.

Thanks, Mohamed

mohamed
  • 311
  • 2
  • 6
  • *"the server has only the public key"* - that's where you're wrong. The server has both the private key and the public key. – Artjom B. Sep 18 '16 at 14:39
  • Thanks. Here is my further question. In real world, say for example to access gitHub repository from local, after generating the keys using ssh-keygen the client copies the *.pub key to the git hub server (which means the public key is copied to the server). In other words the server now has only the *.pub key (say id_rsa.pub). In this case how can we say that the github server has my private key ? Please see the url https://help.github.com/articles/adding-a-new-ssh-key-to-your-github-account/ for ssh to github – mohamed Sep 18 '16 at 15:21
  • @mohamed In that case you're talking about signing which is done with the private key and verifying the signature with the public key. In RSA this is basically the same operation as encryption, but other RSA is a special case. Other asymmetric crypto algorithms exist either for encryption or signing. – Artjom B. Sep 18 '16 at 21:00

1 Answers1

1

If a server has only a public key it cannot decrypt a message from a client.

One more time, with the important vocab words in bold: If a server has only a public key it cannot decrypt a message from a client.

What the server is probably doing is verifying a message signed by the client.

In the case of SSH public key authentication (RFC 4252, section 7) it is a signature over the just-negotiated session ID and some context data (which requires the client to have the private key). The server can then run the signature verification algorithm (which only requires the public key). If a preregistered key checks out, the client is thus authenticated.

In the case of RSA keys the signing and decrypting operations look mathematically similar, which can cause some to use the terms loosely, but we should be precise.

  • Encrypt (public key): Transform content in such a way to occlude it from everyone except the intended recipient (the holder of the private key).
    • Common algorithms: RSA
    • In encryption the encrypted output REPLACES the original content in transmission.
    • Public Key Encryption is frequently used to encrypt a newly generated symmetric key which actually encrypts the data. For RSA the encrypted output is limited by the key size, symmetric algorithms have much larger maxima.
  • Decrypt (private key): Transform content from the Encrypt operation back into its original form.
    • Since anyone could have your public key, anyone can encrypt data for you.
    • Nothing is inherent in the Encrypt/Decrypt pair to establish trust... the message could be a poison pill, and you don't know who wrote it.
  • Sign (private key): Apply a transform over an input (which is usually a digest/hash of the true content) to produce a value no one else can.
    • Common algorithms: RSA, ECDSA, DSA
    • The signature is presented WITH the content, it does not replace it.
  • Verify (public key): Apply a transform over the input and the signature which results in a true or false.
    • If the digest is computed independently by the content receiver the signature proves that the content was not tampered.
    • When the signature is deemed correct it proves that it was generated by the key holder, which can be used in a trust decision. (The key could have been compromised, in which case "key holder" and "original key holder" could be different)
    • For RSA this is "unpack the digest using an algorithm similar to decrypt, then compare the digests", so an RSA implementation could indicate what the correct hash is.
    • For DSA and ECDSA the digest is used as a BigInteger in a formula that produces the second half of the signature from the first half, so DSA can't tell you what a correct digest value is.
Community
  • 1
  • 1
bartonjs
  • 30,352
  • 2
  • 71
  • 111