Re: Encrypting to a public key?

[Schanzenbach, Martin]

> On 7. Jul 2020, at 01:45, Cy <fromgnunet@cy1.allowed.org> wrote:
> 
> On Mon, 6 Jul 2020 21:05:13 +0200
> "Schanzenbach, Martin" <mschanzenbach@posteo.de> wrote:
> 
>> more commonly you
>> use the ECDSA keys to derive a symmetric encryption key.
>> Basically, you use ephemeral ECDH to do that:
> 
> Thanks for letting me know! I was aware of ECDH, but it requires a lot more 
> interaction
> than I'm comfortable with. A public encryption key, I can passively publish, 
> but I
> believe Diffie-Hellman keys have to be recreated on the spot every time.
> 
>> 2. Calculate ECDH (d, P_bob) => x // x is your seed for a symmetric AES key
> 
> See the P_bob is the problem because "ephemeral" public keys are not secure 
> to reuse, for
> reasons I don't completely understand. So unless I seriously misunderstand, 
> DH is more
> like this:

P_bob does not have to be ephemeral. After all, you want to encrypt _for_ bob.
The GNUnet ECDH API is also designed like this. ECDH functions take 1 ephemeral 
key
(an ECDH key) and one "static" key (an EdDSA key).

> 
> 1. Ask Bob (without encryption or authentication) for a new P_bob

Sure you always need P_bob, but it does not have to be ephemeral.

> 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.
Even in basic RSA.

> 3. Bob generates a P_bob and sends it to you.
> 4. Now Bob has to wait around and do nothing.
> 5. Calculate ECDH(d, P_bob)
> 6. Encrypt your data using HKDF(x) // HKDF is a key derivation function
> 7. Transfer Enc(x, DATA) and P to bob
> 8. Bob calculates ECDH (d_Bob, P) => x
> 9. Bob decrypts using HKDF(x)
> 10. Now you both know the same shared secret.
> 
> With a public encryption key, it goes more like this:
> 1. Download Bob's public key from a CHK or something while he's asleep.

You can do that with P_bob. It is a static EdDSA key (we actually use EdDSA 
outside of GNS).
P_bob may be static. How you authenticate it is different question, but 
irrelevant as
also a problem with, say, RSA.

> 2. Encrypt a random session key to his public encryption key.
> 3. Send it to him.
> 4. Bob decrypts and gets the shared secret.
> 5. Now you both know the shared secret.

I really don't see how this is any different from what I proposed.
I think the misunderstanding is that all keys are ephemeral.
But they do not have to be. In TLS this is true because ephemeral keys
for both parties are a better idea. But you want to encrypt TO a public key.
So you have to do ephemeral<->static ECDH with EdDSA.

> 
> Diffie-Hellman's extra interactions are negligible over a reliable, low 
> latency
> connection, so they just do that without worry. But for high latency 
> communication, I'd
> prefer an authentication system that doesn't require both parties wait for 
> each other to
> generate data. And for privacy purposes, I'd prefer to avoid generating keys 
> on demand,
> as that would prove to third parties that I'm online, whether I approve of 
> their knowing
> that or not.
> 
> Anyway yes I'll probably just use libgcrypt directly then, or libsodium, if I 
> want to
> make a more high latency friendly secret sharing scheme.
> 
> like in this thingy:
> https://doc.libsodium.org/public-key_cryptography/authenticated_encryption
> 

I really think there is not need to do this.

BR

>> crypto_box_easy(ciphertext, sharedsecret, sharedsecret_len, nonce,
>>                    bob_publickey, alice_secretkey)
>

signature.asc
Description: Message signed with OpenPGP