On 2021-01-26 04:31, David Barrett wrote:
Yes, this does assume a central keyserver -- and I agree, it's possible that it lies to you, establishing a connection with someone other than who you requested (or even a man-in-the-middle). I don't know how to really solve that for real without some out-of-band confirmation that the public key returned by the keyserver (whether centralized or distributed) matches the public key of the person you want to talk to.
Jitsi's solution works. It is the much studied reliable broadcast problem, which is a hard but much studied problem, with a bunch of hard to understand solutions, which nonetheless work.
I think you are saying that performance isn't a real world concern, but forward secrecy is? If so, that makes sense.
Yes. Ristretto25519 shared secret construction (using asymmetric cryptography to construct a shared secret that is then used in symmetric cryptography) takes 2.5 microseconds on my computer running unoptimized debug code. For forward secrecy, you need to construct two secrets, one from the transient key and one from some mingling of the permanent key with the transient key, which takes 5 microseconds. And you then use the authenticated shared secret for the rest of the session.