Public key Infrastructure

Question

Here the MD5 hash is being encrypted with the private key of the sender. But I read in a paper that private key is only used for signing and not encrypting. Is the image wrong or can private key also be used in the way that is shown in the image?

Answer 1

Signing actually means encrypting the hash of the message with the private key, so yes it's correct. That means you decrypt the hash with the sender's public key, therefore you can be certain the sender wrote that message (provided that the hash you compute matches the one you decrypt).

Answer 2

Encryption is typically described as changing a peice of data from something readable by anyone (cleartext) to something undecipherable (ciphertext). Then decryption is the reverse process. Any time an operation is performed, regardless of the purpose, these terms apply.

In the case of a signature, the purpose is integrity, but the same process holds true:

• The message is hashed

• The hash is encrypted with the sender's private key.

• The encrypted hash is the signature, which is appended to the message

The message itself is later encrypted entirely with 3DES and transmitted, so privacy is provided by the the symmetric key.

On the other end: - the signature is removed from the message - the unintelligible ciphertext is rendered back into the original hash by the public key of the sender - the (now cleartext) hash is compared to a repeated hash of the message

In this case, the encryption is something that anyone can decrypt using the public key of the sender - so it doesn't guarantee a private transmission. But it's still encryption because the original data (the hash) cannot be interpreted without first decrypting the signature.

It gets confusing in asymetric cryptography, because "signing" and "encrypting" are two applications of public/private key pairs, but even in a signature the mathematical steps of encryption/decryption take place because cleartext gets turned into ciphertext in either case.

Answer 3

"Encryption with the private key" is how the very first digital signature algorithm was initially described, in a hand waving way (this was RSA, back in 1977; the article also contains more useful mathematics). It turns out that this "explanation":

1. works only for RSA, not for all signature algorithms;
2. does not actually work for RSA either. The whole "encrypt with the private key" bypasses any notion of padding, which happens to be crucial for security.

See PKCS#1 for how RSA should be used. In particular, see how private key and public key operations are not at all symmetrical, and cannot be swapped in such an off-hand manner.

What should be remembered is the following:

• An asymmetric encryption algorithm is such that anybody can encrypt the data, but only one person can decrypt it. In cryptography, something which can be done by only one person means that this person knows an element (a "key") which is not known by anybody else (hence, a private key). On the other hand, something which can be done by everybody uses only public elements, by definition.

  (The heart of cryptography is: knowledge is power. Everybody can buy the same kind of PC, so what gives power is knowledge of data. Keys are specific data element which concentrate this type of power-granting knowledge.)

• A digital signature algorithm is such that only one person can generate the signature, but anybody can verify it. There again, the signer must know something special which gives him his signature powers; namely, a private key. The corresponding public key is used to verify the signature (it is public, thus anybody can do the verification bit -- just what we want).

• Asymmetric encryption algorithms and digital signature algorithms live in separate worlds. It just happens that there is an asymmetric encryption algorithm called RSA, and a digital signature also called RSA, and they build on the same underlying mathematics, so it seems that they could use the same kind of keys. However, there are good reasons why signature keys and encryption keys should be distinct from each other, even when they are mathematically compatible.

• The schematic you show tries to illustrate so-called "secure emailing". The Sender wants to send a message to the Receiver, so that nobody else than the intended Receiver may read the message, and also so that the Receiver may reliably detect message alterations (or even use the message as a legally opposable proof against the Sender himself). The confidentiality part calls for asymmetric encryption, while the integrity part uses a digital signature. There are two algorithms here, and, necessarily, two key pairs: the Receiver does the decryption (so he has a private key), and the Sender generates the signature (so he also has a private key). Thinking of the two key pairs as being somewhat equivalent is just bogus, wrong and confusing.

• PKI is something else. PKI is a way (or, actually, several ways) to bind values together in a verifiable way; in particular, to bind public keys to identities. This uses digital signatures. One use of PKI is to allow people to make sure that a given public key is really owned by whoever they believe the owner to be. This is a much needed requirement before applying encryption on an email (the encryption does its job only if you encrypt with the right public key, the one of the intended Receiver, not the key of some evil interloper). This is also a needed component for signature systems, which build on digital signatures and strive for obtaining legally binding signatures. There again, signatures and encryption go separate ways, because encryption is needed a priori (you must make sure of using the right key before clicking on "Send") while signature is an a posteriori thing (the PKI occurs at verification time).