[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Encrypting to a public key?
Re: Encrypting to a public key?
Tue, 7 Jul 2020 09:16:00 +0200
> On 7. Jul 2020, at 01:45, Cy <email@example.com> wrote:
> On Mon, 6 Jul 2020 21:05:13 +0200
> "Schanzenbach, Martin" <firstname.lastname@example.org> 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
> 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
(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
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
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
> 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:
I really think there is not need to do this.
>> crypto_box_easy(ciphertext, sharedsecret, sharedsecret_len, nonce,
>> bob_publickey, alice_secretkey)
Description: Message signed with OpenPGP