The specification uses AES-128 in Galois/Counter Mode (GCM), please upgrade to AES-256. Or use ChaCha20 and Poly1305. https://tools.ietf.org/html/rfc7539
"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? Unclear." https://blog.cr.yp.to/20151120-batchattacks.html https://cr.yp.to/papers.html#bruteforce Andreas Straub: > 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[1] and wire protocol[2] 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. :) > > Cheers, > Andy > > > --- > [1] https://github.com/trevp/axolotl/wiki > [2] https://github.com/WhisperSystems/Signal-Android/wiki/ProtocolV2 > > _______________________________________________ > Standards mailing list > Info: http://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
