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
