11–13 of 13 posts
What's the point of a secure cryptographic protocol if your messaging app a.) Sends back telemetry data b.) Accepts arbitrary software updates without user approval c.) Contains proprietary components with unknown workings and d.) Forces you to send all of your messages over hostile servers?
Elaborate on a) ? That's indeed very troubling and completely unacceptable if it's true.
It would be interesting to know how this relates to Axolotl and "the Signal protocol".
But I also agree with your comment, it really helps to understand the "why" to know where this tool sits on the overall shelf.
Or even just a bit more background on existing double DH constructs and specifically what problems this addresses and a use case where you choose this protocol specifically to gain some specific necessary property that you don't get otherwise with other DH constructs.
The special padding during the hashing step seemed a bit odd, not sure why it was quite so many bytes?
I would also love to see pseudo-code, some test vectors, and a sample hex encoded output of an exchange.
It would be interesting to know how this relates to Axolotl and "the Signal protocol".
The first time you want to message that user, but that user is not online, you cannot do an interactive key exchange (and thus, no forward secrecy). Their work around is to have these pre-keys that can only be used once.
So you get one of that pre-key, and you do some sort of Diffie-Hellman handshake that they call X3DH.
Now does all this really matter? Probably at this point, you have not verified the public key of your friend out of band, otherwise he would have gave you one of these pre-keys himself. So the end-to-end encryption could be broken at this point (but you could still later realize what happened).