On Tue, 7 Jul 2020 09:16:00 +0200 "Schanzenbach, Martin" <[email protected]> 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. -_-
