It would be interesting to know how this relates to Axolotl and "the Signal protocol".

This is about as clearly written as I could ever hope a crypto writeup to be! So first off thanks for that!

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.

I'm not too familiar with the Signal Protocol so I might be mistaken. But a Signal user always has "pre-keys" (a 100 per devices I think) published online on the Signal server.

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).

That document is placed in the public domain. If you hate Signal that much, write another one yourself.

On (a) This https://whispersystems.org/bigbrother/eastern-virginia-grand..., claims they only store "date and time a user registered with Signal and the last date of a user's connectivity to the Signal service".

However I think the parent might be concerned that OWS could be compelled to change their server code to log more meta data, currently we must trust them.

For (b) Not sure what could be done about this, maybe an independent service audits each release, subsequent audits would take less time since the diff of the code base would be small. Don't really know, I'd like to know of there are any solutions to this, it seems less like a technical problem than the others though.

For (c) Opening up the server code would encourage people to run their own, see See https://whispersystems.org/blog/the-ecosystem-is-moving/ for why moxie doesn't want federation.

On (d) Using GCM means Google can get all the meta data too if they want/are compelled to. This is a legitimate concern but OWS is very clear what signal does, they don't claim to tackle e.g. traffic analysis. A world with everyone using end to end encryption would be much closed to the crypto-utopia.

I can reply for d): end-to-end encryption.

That's pretty much the reply for all of them. Except c) but I thought the protocol itself was open if not the server end.

Elaborate on a) ?

That's indeed very troubling and completely unacceptable if it's true.

That piece is called Android, actually.

Funny how you created a throwaway account just for trolling