1

I asked a question yesterday about the Keybase key model and got no answers, unfortunately. Let me rephrase the question to make it clearer: in the case, if 2 users just want to send each other low-frequency e2e encrypted messages (e.g. files) via a 3rd party semi-trusted server over a secure channel i.e. TLS, using curve25519 key pairs and do x25519 and AEAD(e.g. poly1305chacha20 like in libsodium's crypto_box_*()). Note that this is not a public web server or a VPN where messages have a streaming nature and you can have thousands if not millions of ciphertexts messages in a short period of time.

  • Is being concerned about forward-secrecy in such case irrelevant and somewhat overkill and static-static DH is enough?

  • Also, can ephemeral-static DH mitigate the forward-secrecy problem, at least for one party (aka the receiver) since static-static DH still suffers that if one of the parties got compromised all the messages are then compromised regardless of whether the other party is keeping his private key secure?

kelalaka
  • 48,443
  • 11
  • 116
  • 196
Ejonas GGgg
  • 173
  • 3
  • A related question Is forward secrecy overhyped or necessary? and the answer contains some of your concerns. – kelalaka Dec 19 '19 at 23:08
  • Seems to me that if you use ECIES (as used for the crypto-box, if I'm not mistaken) then you're already performing ephemeral DH to a large degree. What other cryptosystem were you thinking of that doesn't use an ephemeral key pair? – Maarten Bodewes Dec 20 '19 at 01:12
  • thanks @Maarten-reinstateMonica ! but how? aren't the same 2 key pairs argument of x25519 keys going to produce the same resultant key that is going to be used in the symmetric AEAD with polychacha? assuming we're talking about the case of libsodium/nacl – Ejonas GGgg Dec 20 '19 at 01:23
  • 1
    Let me check. I guess the answer to the question depends on the use case. You need static key pairs anyway if you require authentication of both parties. So what's more important: securing the ciphertext or securing the authenticity of the party that send it? – Maarten Bodewes Dec 20 '19 at 01:26
  • I believe that "securing the authenticity of the party that send it" is much more important. But why do I have to choose? – Ejonas GGgg Dec 20 '19 at 01:28
  • In the end you're going to rely on a trusted key pair of the sender anyway, right? You can use an ephemeral key, but how are you going to prove message authenticity without using a static key pair of some kind? Of course you could try and use forward secrecy but that leaves the problem of authenticating the message, and leaking the static key used to authenticate such message would allow the other party to send other messages as well. So in that case PFS would have limited advantages. – Maarten Bodewes Dec 20 '19 at 01:33
  • Ah, it looks like the ill described protocol uses static-static DH using a nonce to make sure that the encryption is non-deterministic, right? The description of NaCl leaves -uh- something to be desired. – Maarten Bodewes Dec 20 '19 at 01:41
  • In the case of Keybase, the use case I am interested in, it seems that every user has 2 static key pairs (one is curve25519 and the other is probably ed25519), afaik they are depending completely on these static curve25519 for encrypting messages/files between any 2 users. Therefore they have no forward-secrecy. But if we redesign the system so that the sender generates an ephemeral curve25519 key and sign the public part with the static ed25519 privkey so that the forward-secrecy problem is mitigated. Note that complete ephemeral-ephmeral DH is not possible in this case – Ejonas GGgg Dec 20 '19 at 01:42
  • Let us continue this discussion in chat. – Ejonas GGgg Dec 20 '19 at 01:42

0 Answers0