6 comments

[ 2.8 ms ] story [ 22.0 ms ] thread
FWIW, I was expecting something like "the mechanism is fundamentally flawed because the e2e encryption actually is designed in a way where the server can derive or find the key"; but, thankfully, this is "merely" the "obvious" vulnerability in key exchange: "how do I know I wasn't given a forged key by the server?", to which the protocol generally won't have any solution (barring some kind of pgp-style web of trust, which protocols should probably adopt) and the only reasonable thing to do is to add a UI that shows the user the key and helps them verify it (preferably with a mechanism to make chats look insecure until they are verified, like Threema also gets right)... which thankfully this developer did--though I have no clue how well the UI works in context as I haven't used it and am only glancing at the screenshots... probably nowhere near as good as Threema--instead of trying to paper over the problem and pretending it doesn't really exist by simply throwing certificate pinning at the proximal MITM problem because their server can (of course) be trusted like Apple does with iMessage without addressing the ultimate flaw [<- all of which I describe in a single run-on sentence, as it is maximally fun :D, before y'all get upset at me and leave pointless replies].
> add a UI that shows the user the key and helps them verify it [...] probably nowhere near as good as Threema

Indeed, Threema really has to get more credit for this one.

How many people verify their contacts in Signal when they opportunistically get the chance? Wire? WhatsApp? Matrix?

My mother in law wanted to verify keys with me in Threema of her own volition. In Signal, which she tried for the same reason (securely communicating medical data between colleagues), she didn't even know it was possible, let alone that she should be doing that.

> FWIW, I was expecting something like "the mechanism is fundamentally flawed because the e2e encryption actually is designed in a way where the server can derive or find the key"

The mechanism wasn't intentionally designed that way. But the symmetric ChatKeys were created with Random(), seeded (at least partially) with time().

This recently happened with a Bitcoin wallet app called Cake wallet. They used time() in their random number generator which allowed the key generation to be replicated and funds stolen.
What’s wrong with just using /dev/urandom for the entropy pool?