[pacificresearch]

I fail to see how this is a major improvement over OMEMO? OMEMO is also an asynchronous multi-party chat algorithm, except it's already widely adopted by clients on several different platforms (Android, iOS, Windows, Mac) and has also received a significant amount of attention from security researchers.

OMEMO's cryptographic security has already been audited as well: https://conversations.im/omemo/audit.pdf . I should know as we (Pacific Research Alliance) funded the audit of OMEMO ;) . Auditing merely the protocol seems a little problematic, it's quite rare for vulnerabilities to be in an encryption protocol itself and much more common for it to be in the implementation. There doesn't seem to be any application which actually implements this library right now, let alone a network capable of supporting it. In OMEMO's case we also audited the OMEMO implementation in Conversations where it was originally conceived.

The only difference I can tell from their website is "Room consistency: Group chat participants are confident that they are in the same room". This seems like a pretty niche area to be concerned about, and in practice can be solved by a properly secured network. Although I am no cryptographer I believe OMEMO may offer the same quality as well, because all the messages must be encrypted for each participant, so at worst you could fake an identical room with identical participants, which doesn't really seem like a valid security problem.

While I love to see new research and further development into this area, it seems this is a little late to the party.

[kelnage]

I would argue that the reason protocol errors are perceived to be "quite rare" is because the security guarantees that many (most?) security protocols offer are usually under-specified, if at all. When auditing protocols, analysts often have to infer what properties a user might expect.

A great example of this would be [1], where a number of ISO-standardised authentication protocols failed to give even the most basic authentication properties. And this kind of issue isn't limited to ISO - the same kinds of issues appeared when analysing TLS, Signal, and others.

The problem is that implementation errors are usually more clearly violations of confidentiality (i.e. it is obvious that an attacker is able to access something they weren't supposed to) - so they are generally held to be more valuable - and hence more eyes spend time looking for them.

(Disclaimer: I am doing a PhD in this field with Prof Cas Cremers, which might bias my views on this subject a little)

1. http://www.cs.ox.ac.uk/people/cas.cremers/downloads/papers/B...

[wuch]

What issue do you refer to in context of Signal protocol?

[kelnage]

Sorry, I didn't make myself clear there. Under-specified security properties. Although they (and TLS, honestly) do a better job than others, in their protocol documentation they really don't go to any lengths to describe what actual security the protocol provides - just that it is "secure". This makes verifying these protocols nigh impossible - and usually you end up with the analyst having to reverse-engineer what security properties they think the designers wanted the protocol to ensure.