[Standards] OMEMO and Olm

Sam Whited sam at samwhited.com
Fri May 26 16:35:38 UTC 2017

> Yes, it's true that there's currently no such thing [a permissively licensed implementation] for XEdDSA …
> implementing this yourself really isn't
> that complex. You can re-use existing EdDSA code, all you need to do is
> write the key conversion code yourself, for which there is pseudo-code in
> the standard, which maps fairly directly to well-known mathematical
> primitives, for which you can also re-use existing code. The main novel idea
> in XEdDSA is resolving an ambiguity in the conversion by forcing a sign bit
> to 0, and that's about it. Your code doesn't have to be constant-time and if
> you do it wrong, the signature just won't verify.

This is my only real concern with using XEdDSA as it stands today;
crypto is subtle, and it can be very easy to make mistakes that have
catastrophic consequences. To find out, I decided to do an
implementation of XEdDSA and see how difficult it was. I haven't
finished or tested it yet (and I'm not sure if I'm going to or not),
but I've gotten far enough to come to the conclusion that Andy is
right: If you already have an ed25519 imlementation (and possibly a
curve25519 implementation if you want to use the montgomery form of
the keys, I skipped this part and just used edwards keys directly)
then it's fairly straight forward. The hardest part is interpreting
the spec (crypto people like to use notations that make me sad and
probably make it easier to make a mistake).

All that being said, I still would prefer if there were other existing
implementations; relying on software that doesn't exist except in
GPLed form still feels poor to me, but being able to use a single key
for both ECDH and signatures is really nice.


More information about the Standards mailing list