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?

smwikipedia
  • 113
  • 6
  • 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 05 '18 at 09:07

3 Answers3

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.

hft
  • 4,940
  • 17
  • 32
  • 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 05 '18 at 03: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 05 '18 at 03: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 05 '18 at 03:24
  • So, **only I** can decide the symmetric key and it **must be me** to tell the server. Not server telling me. – smwikipedia Sep 05 '18 at 03:28
  • You can get more info in https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work – M'vy Sep 05 '18 at 09:05
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.

CBHacking
  • 42,359
  • 3
  • 76
  • 107
  • Just adding some advice here, you should always sign the message before encrypting the result. See https://crypto.stackexchange.com/questions/5458/should-we-sign-then-encrypt-or-encrypt-then-sign – M'vy Sep 05 '18 at 09: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 05 '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 05 '18 at 12:24
  • I messed up `confidentiality` with `authenticity`. That's two different things. Thanks. – smwikipedia Sep 16 '18 at 05:34
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-Hellman key exchange. Note that this exchange has no inherent authentication but you can achieve that by "signing" the messages used in the way you mentioned.

Bruno Rohée
  • 5,351
  • 28
  • 39
Florian
  • 111
  • 3