[Standards] Proposed XMPP Extension: OMEMO Encryption
fedor.brunner at azet.sk
Wed May 4 12:16:58 UTC 2016
The specification uses AES-128 in Galois/Counter Mode (GCM), please
upgrade to AES-256. Or use ChaCha20 and Poly1305.
"Bottom line: 128-bit AES keys are not comparable in security to 255-bit
elliptic-curve keys. Is 2^255−19 big enough? Yes. Is 128-bit AES safe?
> Hey all,
> since I haven't really responded to this yet on the list and recently
> there has been some discussions on the topic in the XSF MUC, I thought
> I'd give a short update. (This actually turned out much longer than I
> intended so skip to the second to last paragraph for a summary if you're
> pressed for time)
>>> To get the ball rolling, I’ll play devil’s advocate for a bit here: it is
>>> impossible to implement OMEMO from scratch by the current documentation alone.
>>> “Axolotl” has no standard, and it appears Open Whisper Systems has no
>>> intention of writing one. The few bits of documentation and blog posts that we
>>> have are not enough to implement it and are outdated or wrong in some places.
> To give some context to those that haven't been following this in
> detail, there are two different versions of the TextSecure protocol that
> are currently relevant, v2 and v3. Axolotl was introduced in v2, v1 was
> OTR-based. There is publicly-available documentation of the
> cryptography and wire protocol used in v2. These are not exactly a
> standard, but do describe the protocol pretty clearly.
> Currently, the OMEMO ProtoXEP mandates use of v3. v3 introduced some
> variations on the underlying cryptography, along with corresponding
> changes of the wire protocol. Neither of those things are publically
> documented anywhere to the best of my knowledge. For this reason there
> has been some justifiable resistance towards OMEMO. I agree that this is
> a problem, and in light of this fact, I understand hesitation to proceed
> with standardization of OMEMO in its current form.
> I don't think that getting the Open Whisper Systems people to write up a
> spec of v3 for us is realistic, and I wouldn't feel comfortable with
> writing up this spec myself. What I propose is that we change the OMEMO
> spec to REQUIRE conforming implementations to support v2. We would
> further make it OPTIONAL to support v3 as well, as many client
> developers will likely re-use existing implementations of axolotl, most
> of which support both versions.
> The scenario of interest is establishing a new session. Let's say Alice
> wants to talk to Bob. Alice can discover whether Bob supports v3 by
> checking whether a signedPreKeyPublic and corresponding
> signedPreKeyPublicSignature are present in Bob's published preKeyBundle
> as these items were added in v3 (We might also explicitly announce v3
> support in the XML here, I don't really feel strongly about this either
> way, although I don't think it's necessary). If Alice supports v3, and
> so does Bob, they can use v3 to establish their connection. If Alice
> supports v3, but Bob doesn't, Alice will realize this and fall back to
> v2. If Alice doesn't support v2, regardless of whether Bob does or not,
> Alice will simply ignore the signedPreKeyPublic and signature as she
> isn't aware of them, and establish a v2 session. Therefore, in this
> scheme we obtain automatic, transparent version negotiation (of sorts)
> for free.
> As a side-note on the cryptographic differences/benefits introduced with
> v3, there's not any documentation I could find that states the intent
> behind the changes. I won't speculate or make educated guesses as to the
> precise reasons at this time, but I will say that in any case, v3 does
> not appear to be less secure than v2, so allowing its use in an OPTIONAL
> fashion shouldn't decrease the security of the protocol. Further,
> distrusting clients can always chose not to announce support for it if
> they're dissatisfied with its unspecified nature.
> In conclusion, we can (mostly) resolve the standardization issues with
> axolotl using the previously described change, with no immediately
> obvious downsides. I would be interested in hearing some feedback on
> whether those parties previously dissatisfied with OMEMO for this reason
> agree that using v2 is a workable solution to the specification dilemma.
> In that case I would draw up the necessary alterations to the ProtoXEP.
> I would further be interested in opinions on the issue of whether the
> documentation that is available on v2 is deemed sufficient for an
> independent implementation, and if not, in what manners it is lacking,
> so please take a look!
> Additionally, there hasn't been much discussion about this on the list,
> so if there are any further grievances with OMEMO in its current state,
> please make yourselves heard, and maybe we can resolve those as well. :)
>  https://github.com/trevp/axolotl/wiki
>  https://github.com/WhisperSystems/Signal-Android/wiki/ProtocolV2
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 931 bytes
Desc: OpenPGP digital signature
More information about the Standards