The server role seems quite clearly described in more detail in the actual protocol description, is there something missing? The section you quote just describes the high-level idea of why and how to introduce the server in the scheme.

No. If the section beginning "Protocol" is what you refer to as the "actual protocol description" then no, the server role does not seem clearly described in any level of detail.

To cut a long story short: Alice gives the cache, aka Mallory, a set of secret data which are implied but not proven to be able to be used by Bob to create cryptographic text which Alice can decrypt but this magic cache, aka Mallory, cannot. This document provides few hints and no detail on how we can be assured that the magic cache, A.K.A. MALLORY, is unable to make use of the secret data provided by Alice (and "promised not to be shared") to make inferrences on the crypyographic text provided by Bob.

The cache contains ephemeral _PUBLIC_ keys, that would otherwise be transmitted to anyone who requests them by the message recipient (perhaps through some encrypted channel, but without meaningful authentication). In essence it's the same thing as PGP's encryption subkeys, which are completely published, but the cache contains more of them as the keys are preferably only used once (there is one difference in that the cache gives only one key at a time and will not give the same public key again as long as it contains enough of them).

So: making the whole thing completely public only enables adversary to match session initializations with receivers, which the server can do by definition as it has to route the messages to correct recipient. (In the case without such central server, anybody observing the traffic could do that, as another role of the central server is to mask sender addresses on the lower protocol layers)

Good! Say that! Then the entire protocol and its description can be reduced to "this is a cache of ephemeral public keys and messages encrypted using them".

I know that doesn't sound quite so impressive, but that's because it isn't.

Cryptographic protocols are not supposed to be impressive. But on the other hand your shortened description describes the main difference between Signal and traditional OTR, it does not describe how the protocol works after you get the ephemeral key of the receiver.

Additional and to some extent non-trivial difference from traditional OTR is in how these ephemeral keys are used in key exchange, whose result depends not only on DH with ephemeral keys but also on DH exchange that mixes ephemeral keys with long term ones. This causes that the ephemeral key of the passive side does not have to be signed and allows anyone to produce arbitrary session transcripts, both of these points allow significant reduction of size of the exchanged messages.

That was made apparent in their documentation.

Or would have been, if they had any.

You can't go off about downvotes like this on Hacker News.

https://news.ycombinator.com/newsguidelines.html

Perhaps people are responding to your unwarranted, toxic tone, your rudeness elsewhere in the comments, and your inability to give even a modicum of respect to the developers who've not only designed and openly published groundbreaking advances in secure private messaging protocols, and not only implemented them and freely distributed those implementations, but have also worked to have those designs incorporated into the some of the most widely-used messaging software in history.

Feel free to propose a secure, decentralized way to pass the payload between the endpoints. Be sure your solution includes an effective mechanism to mitigate spam. Bonus if your solution denies attackers access to the same metadata centralized systems do. Double bonus if you can support push messaging systems to deliver timely notification that users have come to expect.

Home servers connected over I2P, hopefully.

I'm not trying to propose a "way" of anything, "secure", "decentralised" or otherwise! Don't you get it? I'm talking about the documentation.

I have no idea if this solution to the problems posed is sound because before I can even get to the source code there is no description of how or even whether it solves the fundamental problems in the cryptographic situation it describes (viz. device which cannot straightaway engage in IP communication requires to receive unsolicitated securely-encrypted messages).

> whether it solves the fundamental problems in the cryptographic situation it describes (viz. device which cannot straightaway engage in IP communication requires to receive unsolicitated securely-encrypted messages).

Please elaborate and clarify.

Instead of responding to the tone, let's concentrate on the merits. For most people, it is unacceptable to require both parties to be simultaneously online in a chat session.

I'm very interested in any potential implementation that allows asymmetric conversations without a dedicated third node (if we don't like the name server) somewhere in between.

Of course tone is relevant. Tone is how one has a civil conversation with another person, even if they disagree.

Tone matters. It's not everything, but it matters.

There are people, and/or messages, in which a lack of civility needn't warrant a complete dismissal. They're relatively rare.

I'm willing to give a hearing here. Crypto is, for better or worse, an area in which there is a tendency toward both informed and abrasive contributions.

I'm aware HN doesn't take well to that. I've been arguing the opposite strategy for the past few days with a friend (he likes tossing bollocks about, I prefer avoiding that). I'd advise ChoHag to tone it down (and reconsider their chosen handle), but contribute. I did consider vouching the flagged/dead comment, but decided against in this case.

> Please resist commenting about being downvoted. It never does any good, and it makes boring reading.

https://news.ycombinator.com/newsguidelines.html