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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
