> On 7. Jul 2020, at 01:45, Cy <[email protected]> wrote: > > On Mon, 6 Jul 2020 21:05:13 +0200 > "Schanzenbach, Martin" <[email protected]> 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
