This is a simple question but one which greatly confuses me. When you have a PKC, the public key can be accessed by anyone. Therefore, doesn't this mean that anyone can encrypt data? My question is basically that if you have such a scheme where the public key is used to encrypt some instructions, the receiver can end up decrypting rogue instructions does it not? In such case, the receiver would need to do some security checks upon decrypting the message.

Looks like the PKC's purpose is purely the security of the message itself, and not the actual integrity of data.

  • Both answers here are mildly misleading. Signing is not the same as "encrypting with private key". Please read this, this and this if you want to avoid confusion. Commented Aug 10, 2017 at 15:40

2 Answers 2


Your concern is misplaced though everything you wrote was technically correct. The tricky part of understanding PKI is seeing how each type of protection is gained.

If a sender wants to ensure that a message can only be read by the intended recipient, the sender uses the recipient's public key. In this way, no one else can decrypt the message since the complimentary private key is secret and the sender has gained confidentiality.

If the sender can also provide the recipient with confidence that the message was created by the specific sender (non-repudiation) and has not been tampered with since the sender created it (integrity) by making a hash of the message, encrypting the hash with the sender's private key and attaching the encrypted hash to the encrypted message. Since the decryption of the hash can be performed with the sender's public key, the recipient can decrypt it and confirm the hash against the message. The encrypted hash is called a digital signature since it ties sender to message.

[NOTE: The message and the hash are not encrypted with the same or even related keys. The message is encrypted with the recipient's public key while the hash is encrypted with the sender's private key.]

Both integrity and non-repudiation can be strengthened by using a time-stamp server. This is a lesser know but very valuable step in which the sender sends the hash to a trusted server (typically a third-party commercial service) which replies with the hash and a time-stamp encrypted with its private key. The sender then encrypts that response and sends it as his signature.

With all those steps, the recipient knows:

  1. No one but the sender has seen the contents;
  2. Only the sender could have sent the message;
  3. The message is unchanged since the sender signed it
  4. When the sender signed it.

All of this assumes that both recipient and sender have maintained the confidentiality of their private keys. With this assumption, the recipient can not deny having sent the message and, if time stamped, having sent it at the time indicated by the time stamp.


Yes, anyone can encrypt with a public key but the use of keys in this case isn't for non-repudiation i.e. proving who sent, but only ensuring that only a specific recipient can decode and read the plain text i.e. that any interceptor of the message can't read it. This is the confidentiality part.

In order to ensure that the receiver can trust the sender, the sender needs to sign the encrypted file in some way, i.e. use some system to prove to the recipient that one person sent the file and that sender can be 'proven'. In public key systems this is done by the sender hashing the file they have encrypted and then encrypting that hash with their private key. The receiver then uses the public key of the signer/sender to decrypt the encrypted hash and comparing it with the hash they generate from the decrypted file, and, because only the sender can have created that hash, the receiver knows, beyond doubt, that the sender was the person who they said they were. This is the integrity part.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .