6

Assume:

  • Alice and Bob both generate separate EC keypairs
  • Alice obtains Bob's public key, and together with her private key creates a shared secret key
  • Alice encrypts a message using the shared key and some mode of authenticated encryption (AES-GCM, for example)
  • Bob generates the same shared secret key using his private key and Alice's public key
  • Bob decrypts the message, paying attention to whether or not the auth-tag is valid

My question is; if Bob is confident that Alice's public key really belongs to Alice, then can he be confident that it was Alice who encrypted the message? Or to put it another way, in this scenario does the auth-tag effectively serve as a signature created with a public-key? Intuitively I want to say yes, but I just want to make sure I'm not overlooking anything.

hunter
  • 4,051
  • 6
  • 29
  • 42

3 Answers3

5

I guess the answer is no, as long as you are using ECIES then this protocol does not work - you cannot trust the public key of Bob, which is required for ECIES.

You could however use ephemeral-static Diffie-Hellman, using ECDH as cryptographic algorithm. Alice would supply the static part as her public key is trusted, Bob may use any key pair. That means that Bob can trust Alice, but not the other way around. This may however be sufficient for some protocols (TLS normally does not perform client authentication either).

Of course, you may just as well use a static key pair for Alice instead of randomly generating it again and again, requiring to set up trust for each key pair creation.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323
4

It depends on exactly what protocol you're asking about.

ECIES as design gives no assurance to Bob that the message really came from Alice.

This is, with standard ECIES, Alice does not use her private key -- instead, everything that Alice does (encrypt using Bob's public key) could have been done equally well by someone else - hence, Bob has no cryptographical assurance that the message really came from Alice.

Remember, ECIES is designed to be a public key encryption system; that's precisely what it does, and public key encryption does not necessarily imply sender authentication.

On the other hand, you state "Alice obtains Bob's public key, and together with her private key creates a shared secret key"; you might by that mean that you don't use standard ECIES; instead of the random number, she uses her ECIES private key.

With that modification, it turns out that the protocol is still secure, and in fact does give source authentication; a message from Alice to Bob can be generated by either Alice or Bob, but no one else without Alice or Bob's private key. In addition, in IES, it's optional whether you use a nonce to stir into the KDF -- with this modification, its use is strongly recommended -- otherwise, any message between Alice and Bob will use the same symmetric key, and that's worth avoiding.

Raoul722
  • 3,003
  • 3
  • 23
  • 42
poncho
  • 154,064
  • 12
  • 239
  • 382
1

I'm answering based on the protocol in your question, which seems to be (EC) Diffie-Hellman.

My question is; if Bob is confident that Alice's public key really belongs to Alice, then can he be confident that it was Alice who encrypted the message?

If Bob is confident no one else has access to either secret key or the shared secret, then yes, authenticated encryption using the shared secret proves to Bob no third party could have encrypted the message.

Or to put it another way, in this scenario does the auth-tag effectively serve as a signature created with a public-key?

To Bob, yes. However, he can't prove to anyone else that Alice encrypted the message and not Bob himself. That is, it does not guarantee non-repudiability.

otus
  • 32,462
  • 5
  • 75
  • 167