Hi Paul, thanks for reading that lengthy email.
If I understand you correctly, the complete magic happens in the key element and there is no description in the XEP or in the linked "signal protocol" which describes it. So all implementations use libsignal? I think this is terrible for a protocol and I'm a bit shocked. At least there should be a note that the key element contains just more than the encrypted "16 bytes key and the GCM authentication tag" as stated in section 4.5. One more think which I noticed was that somewhere in time the namespace changed from the well known urn:xmpp:omemo:0 to eu.siacs.conversations.axolotl. What was the reason for this uncommon format and is it not weired that there is the term axolotl, but the protocol uses signal now? Is there any explanation for the mentioned authentication tag? Cheers On 18.09.2017 14:13, Paul Schaub wrote: > > Hi! > > Am 18.09.2017 um 13:07 schrieb Klaus Herberth: >> >> I am trying to create an MIT licensed OMEMO library written in >> Typescript and while reading the protocol some questions came up. >> > > Nice! OMEMO lacks permissive implementations. > >> - Version 0.2 uses the signal protocol now (sec 1.1), but as far as I >> know there is no "signal protocol". They split it into 4 parts: >> XEdDSA, X3DH, Double Ratchet and Sesame which builds the "signal >> protocol". I think it would be helpful to mention this and link the >> corresponding documents. >> > > All current implementations are using some variant of > libsignal-protocol [1,2,3], which internally use XEdDSA, X3DH and the > Double Ratchet. Links to the documents would be useful indeed. > >> - In the examples you often see the string BASE64ENCODED, so I assume >> I have to encode those values with base64. Would it not be better to >> mention this in the text? >> > > I haven't noticed, that that's missing from the text, but yes that > should also be included. > >> - Device ids are just defined (sec 4.1) as random numbers between 1 >> and 1^31-1. I would propose to use UUID [3] as e.g. used in XEP-0359 >> [4] to minimize the change of collisions even further. >> > > We had a lenghty discussion about that [4]. I think the consens was, > that this can be implemented in OMEMO-NEXT, but for current > implementations it is just overkill. Also there is a very easy way to > deal with collisions. > >> - The protocol requires to update your own device list prior you >> publish your corresponding bundle (sec 4.3). Even if the case is rare >> that you try to request an not yet published bundle, I think it >> should be handled in some way. One solution could be to change the >> order of announcements. >> > > Nice finding. Still I think the risk of something going wrong is very low. > >> - X3DH uses an ephemeral key pair [5], which is also transfered, >> during the AKE. Maybe I missed it in the XEP, but I found no element >> or some way to transfer this key. >> > > All key information is encoded in the "key" eement, which is basically > a protobuf encoded signal message header. > >> - How does the double ratchet [6] work in OMEMO? As far as I >> understand is the double ratchet the key derivation function of the >> "signal protocol". It consist of two parts: the symmetric-key ratchet >> and the DH ratchet. The DH ratchet ensures forward secrecy and uses >> fresh DH keys transfered with every message. I think section 4.5 is >> not covering this, so this means OMEMO has no FS, or not? >> > > As mentioned above, current implementations heavily depend on > libsignal, which handles the ratcheting. OMEMO does have FS, don't > worry ;) > >> - The double ratchet requires that "a MAX_SKIP constant also needs to >> be defined" ([6] section 3.1) to handle out-of-order messages. I >> think OMEMO doesn't cover this topic at all, because there are no >> message or chain numbers transfered ([6] section 2.6). >> > > Same as above, but I also think this should be covered somewhere in > the XEP. > >> - After I received a message tagged with the prekey attribute, the >> protocol (sec 4.7) requires to delete the used prekey, but how do I >> know which prekey was used? I think there is an additional attribute >> missing, which contains the used preKeyId. >> > > The prekeyId is encoded in the "key" attribute. > >> - I would love to see some security consideration for the management >> or audit of own devices or device keys. E.g. I think it would be >> helpful to attach some optional attributes to the bundle like last >> day of use or client vendor/name, so people can decide if they want >> to delete an entry. > > There was a discussion about that too I think. I believe the reason > not to attach information to the fingerprints was, to disocurage > people from making trust decisions based on that information (which > they would do). Daniel wrote a nice article about BTBV which probably > also applies here. > >> To conclude I am wondering how clients like ChatSecure, >> Conversations, Gajim and some more were able to implement this >> protocol, but maybe I just don't understand some parts of the >> protocol and as I said it would be awesome if someone could help me. >> > > I think depending on libsignal made it easier to implement, because > many of the tripping stones you found were already addressed with it. > Imo it's a real addition to have someone implement OMEMO without > libsignal because of such feedback as you just gave :) I hope I could > help you with some of your questions :) > > [1]: https://github.com/WhisperSystems/libsignal-protocol-java > [2]: https://github.com/WhisperSystems/libsignal-protocol-c > [3]: https://github.com/tgalal/python-axolotl > [4]: https://github.com/xsf/xeps/pull/463#issuecomment-302933965 > [1]: https://gultsch.de/trust.html > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
