1

Below is an illustration of the digital signing process.

enter image description here

According to Wikipedia:

A digital signature is an authentication mechanism that enables the creator of the message to attach a code that acts as a signature.

Suppose sender generates private key 1 and public key 1 to generate the signature.

I think sender basically sends the original Data + Certificate (which contains public key 1) + signature to the receiver.

Then the receiver can:

  1. extract the public key 1 from the certificate
  2. use the public key 1 to decrypt the message hash from the signature
  3. Use the hash to verify the original Data.

But what if someone in the middle intercepts the message? He can do all the same as the receiver. Thus the original Data will be exposed. How is this prevented? Is it prevented by using another pair of keys to encrypt the original Data? If so, how is the public key given to the receiver without being intercepted?

I think it is dangerous to send the public key along with the message. But even if you don't send the public key along with the message, the man in the middle can still intercept the public key and keep it for later use.

So, how to keep both confidentiality and authenticity in a public channel, and with all communications happening only on that channel?

  • Never trust keys you get from unverifiable source. Keys need to be send and authenticated prior to any signature validation made by this key. This is usually done by using person-to-person key exchange, or using third parties (like Certification Authorities in the PKI model). – M'vy Sep 5 '18 at 9:07
2

This is a bad diagram. The basic operation isn't inherently wrong, at least for RSA, but thinking of signing as "encrypting" and verification as "decrypting" is going to lead to exactly the kind of confusion you are expressing here. It is much better to think of it this way:

  • A public key can be used for two things: encrypting and verifying.
  • A private key can be used for two things: decrypting and signing.

Or, equivalently, you can say the following:

  • You can use your private key to decrypt a message somebody encrypted with your public key.
  • You can use your private key to sign a message so that anybody who has your public key can verify the message is from you.
  • You can send your public key to everybody, so they can send you encrypted messages and verify your messages.
  • Unless you are sending a secret message to yourself, or verifying that it was actually you who wrote a message, you never use your public key yourself.

In the question you posed, the MitM doesn't need to decrypt anything, because the message was never encrypted at all! The message (or rather, a hash of it) was signed, so the MitM can't modify the message without breaking the signature, but the message itself is in plain text.

If you want to both encrypt (provide confidentiality) and sign (provide authenticity), you need your private key (for the signing) and the recipient's public key (for the encrypting). That is, before Alice can send a secure message to Bob, she not only needs to generate her own keypair (for signing), she needs Bob to both have generated his own keypair and (verifiably) sent his public key to her (Alice). This is the pattern used by numerous secure messaging schemes, such as OpenPGP (including GPG) and S/MIME (both of which are primarily focused on end-to-end email security).

Another option is of course to encrypt using a symmetric key that you have previously exchanged with the recipient (a "pre-shared key") and then also generate a message authentication code (MAC) using that key or another that you have also exchanged. This MAC might be hash-based (an HMAC, which combines a shared secret key with a secure hash algorithm such as a member of the SHA2 or SHA3 families), or might be derived from the symmetric cipher itself, such as an authentication tag out of a block cipher in Galois/Counter Mode (GCM). However, symmetric keys have no public component - it's never safe to do things like put them into a public certificate - so key exchange is somewhat easier (though still fraught!) when using public/private (asymmetric) keys instead.

  • Just adding some advice here, you should always sign the message before encrypting the result. See crypto.stackexchange.com/questions/5458/… – M'vy Sep 5 '18 at 9:11
  • @M'vy I'm not actually entirely in agreement with that, as it opens the decryption process itself to attack from untrusted sources. In symmetric crypto, the standard (and unfortunately frequent) example is padding oracles. In asymmetric crypto, I know of no issue that is so pervasive and serious, but there can be issues. For example, most side-channel attacks on crypto require that the relevant key be in active memory, or even in use; if one has a side-channel on a machine that both decrypts and verifies, it is most exploitable if it must decrypt before deciding if the message is valid. – CBHacking Sep 5 '18 at 10:50
  • Bit of a conundrum maybe. Being that you can use two sets of keys as you said, I'd still prefer the advice sign then encrypt so as not to compromise authentication and non-repudiation. – M'vy Sep 5 '18 at 12:24
  • I messed up confidentiality with authenticity. That's two different things. Thanks. – smwikipedia Sep 16 '18 at 5:34
2

Is it prevented by using another pair of keys to encrypt the original Data?

Yes, you can use one set of keys for signing and one set of keys for encryption.

How is this prevented? Is it prevented by using another pair of keys to encrypt the original Data? If so, how is the public key given to the receiver without being intercepted?

The problem of key distribution is fundamental. In practice this problem is solved by using a trusted third party called a Certificate Authority (CA).

The CA is implicitly trusted (because the manufacturer installed its root certificate in your computer) and the CA can sign a web server's (e.g., google.com) certificate to prove that the certificate belongs to the web server.

You can then verify the CA signature on the certificate. This gets rid of the MITM attack because the MITM can not obtain a signed certificate from the CA saying that the MITM is, e.g., google.com.

  • Thanks. But I am not worrying about a MITM pretending to be someone. I am worrying about that MITM can get the public key and decrypt the original Data. Since it is a public key, I assume anyone can get it, including the MITM. – smwikipedia Sep 5 '18 at 3:18
  • 1
    The way it works is: the server sends you its public key. So now you can encrypt messages that only the server can decrypt. Now you can create a new secret key (usually a symmetric key) on your machine and you can send that to the server (encrypted with the server's public key). Now only you and the server will know this new secret because only the server could decrypt it with its private key. – hft Sep 5 '18 at 3:22
  • And btw, with a public key server, Tom can generate a key pair, upload the public key to the server while keeping the private key to himself. Anyone who wants to talk to Tom can download the public key from the server and encrypt the message. But this can only guarantee the confidentiality of one-direction communication, i.e. from others to Tom. But not from Tom to others. Because an adversary can also download the public key and decrypt any message sent from Tom to others. I think Tom needs to download the public key of anyone he wants to talk to from the public key server. – smwikipedia Sep 5 '18 at 3:24
  • So, only I can decide the symmetric key and it must be me to tell the server. Not server telling me. – smwikipedia Sep 5 '18 at 3:28
  • You can get more info in security.stackexchange.com/questions/20803/… – M'vy Sep 5 '18 at 9:05
1

Authentication is only one part of what you want to achieve. To encrypt a message (and thus keep confidentiality) over a public channel you could use something like a Diffie-Hellmann key exchange. Note that this exchange has no inherint authentication but you can achieve that by "signing" the messages used in the way you mentioned.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.