ghosttieIn an E2EE system, how does Alice know what Bob's public key is?
Olivier@ghosttie it's public, so either Bob can send it to Alice, or if it's part of a system like Signal, then the public key is part (maybe hidden /abstracted) of the user profile data.
@ghosttie one way would be to meet in person.
In a system like Signal, it would be built in to the user ID. For things like PGP/GPG, websites, or developer signing key, there are multiple mechanisms to verify the key identity. You can use a web of trust (WOT) or keyrings, certificate authorities like DigiCert/Let's Encrypt, or MS/Google/Apple issuing signing keys.
Note that none of those methods are perfect, and a bad actor could still manage to impersonate someone else. But it makes it significantly harder.
Zoarial94 
@ghosttie @dacmot I think you need a second communication channel. And something to corroborate that multiple channels are controlled by the same person. The most surefire way is to meet in person and confirm the keys. I don't think there's a purely technical way to solve this without putting trust into some central authority. It's inherently a social problem.
@Zoarial94 @dacmot @sophieschmieg so if I was doing Fediverse E2EE messaging, we would assume that the PK we get for a person is correct but unverified, and then verify it OOB?
Kind of unrelated, but are there any civilian-friendly ways of comparing PKs? I remember SSH or something had a way of turning the Big Random Number into a picture that you could more easily see differences in...
Sophie Schmieg@ghosttie @Zoarial94 @dacmot I'm not aware of any that have a proven track record of actually working. The problem is that, if you want to have the same security as comparing the entire number, you need to have as much entropy as the number, and all "civilian friendly" ways of encoding information are substantially more verbose than raw bits in hex. So as far as I recall people moved away from things like pictures because the research couldn't show that humans would actually find the difference with high enough accuracy.
But if we're talking about e2ee on the Fediverse in particular (shout out to @soatok ), there is actually another option that I didn't mention in my first post that is uniquely suited here, in key transparency. That's usually a huge pain to deploy and reason about, but gets substantially easier in situations where you may not trust any individual server, but do trust that all of them together do not secretly and maliciously conspire against you.
@ghosttie @Zoarial94 @dacmot @soatok key transparency is something like a "good blockchain": no money (and therefore no scams, fraud, or laundering), no proof of work (and therefore no environmental cost), just an append only log that solves the sybil problem via reputation of Fediverse servers. With that you can make it so that all public key registrations happen publicly and no single server operator can lie about which public key belongs to which account without leaving a public trail. That means that while a server could hand Alice Eve's public key instead of Bob's, everyone, including Bob, would learn about that.
@ghosttie this is the PKI problem, sometimes also called the hardest problem in cryptography. There are many proposed solutions to it, and they all pretty much suck or are at least imperfect. For e2ee chat apps in particular, you either meet in person and scan QR codes, you trust the provider to distribute honestly, or you compare safety numbers out of band. Comparing numbers out of band obviously is getting more and more difficult with things like AI deep fakes making video calls not an easily authenticated channel.
Nils Goroll 🕊️
@sophieschmieg @ghosttie is dnssec still considered a possible solution?
jimfl@ghosttie This is one of the many elements of a public key cryptosystem that is overlooked by people who have a problem and then say “I know: I’ll use public key cryptography!”
Some systems use TOFU, or Trust On First Use, to at least establish that subsequent messages were sent using the key that sent the initial message
Side channels, like key signing parties, or exchanging keys in person in advance might work for two party key use, but fail with many-to-many or one-to-many use cases
Signature schemes use the same kinds of keys, and are difficult to establish key trust in wild systems with lots of independent actors. An example is Open Source software supply chain security, when people say “Simple. Projects just sign their packages.” Why do I believe the key that signed the package belongs to someone who should be attesting for the package?
In closed ecosystems (Apple, Microsoft, etc.) have been made to mostly work, except when sensitive key material inevitably gets mismanaged, breaking trust within the system