Re: Encrypting to a public key?

[Cy]

On Tue, 7 Jul 2020 09:16:00 +0200
"Schanzenbach, Martin" <mschanzenbach@posteo.de> wrote:

> P_bob does not have to be ephemeral.

My understanding was that P_bob had to be ephemeral. So, that makes ECDH a lot 
more
appealing. If P_bob is static, Bob can publish it, perhaps as a CHK. Then many 
people can
get it, and immediately start a conversation, without having to wait for him to 
publish
anything else.

> > 2. Wait for Bob to send it to you and do nothing.  
> 
> This transfer of public key of the destination identity will always have to 
> happen.

The time it takes to get Bob's key is definitely not a concern. I was concerned 
with the
time it takes to wait for Bob to generate his (ephemeral) key. If that isn't
necessary, then that's great! So to use Alice instead of me, after Alice has 
Bob's key,
she has to send Bob something once, and she does not have to wait for a reply. 
Bob might
still have to wait, if he doesn't yet have Alice's key, but he won't have to 
wait for
Alice to generate it either. Is that right?

d_N = private ECDSA key
P_N = public ECDSA key

Alice:
  1. ECDH(d_alice, P_bob) => shared secret
  2. HKDF(shared secret) => ???
  3. Send P_alice to Bob or maybe its CHK, as a request to talk
  4. Send ENC(shared secret, message) to Bob
  5. Go to step 4.

And Bob:
  1. Receive request to talk and get P_alice's key, or its CHK then download 
P_alice
  2. ECDH(d_bob, P_alice) => same shared secret as Alice
  3. HKDF(shared secret) => ???
  4. Send ENC(shared secret, message) to Alice
  5. go to step 4

I'm not entirely sure the purpose of HKDF here. Some sort of anti-flooding 
measure? Also
didn't you say ECDSA keys were only to be used for signing? Because I don't see 
this as
having much to do with signing.

> But they do not have to be. In TLS this is true because ephemeral keys
> for both parties are a better idea. 

A better idea for certificate authorities at least. -_-