[OTR-dev] OTR version 4 Draft #2

Wed Mar 21 12:21:56 EDT 2018

Hi all,

Response in line ...

On 03/20/2018 05:25 AM, Sofia wrote:
> Hey!
>
>> Thanks for you efforts in defining OTRv4.
>> I am currently looking into the spec and have been for a few months.
>> I've gradually started implementing parts of the spec, as I've been
>> reading the various parts to try and wrap my head around them. So, I
>> intend to do this implementation.
>>
>> The implementation is in java and is based on otr4j, however with a
>> bit of history. I started out doing heavy refactoring of
>> github.com/otr4j/otr4j, the (abandoned) initiative of GuardianProject
>> to unify all otr4j developers in a single independent otr4j project.
> Thank you! It is great that this initiative has been retaken. :)
>
>> Over the last 2 years I've done some significant refactoring (see
>> https://github.com/cobratbq/otr4j/blob/master/MODIFICATIONS). Apart
>> from fixing a few bugs, I've modified the code base to use state
>> machines for state transitions to ensure protocol is followed
>> strictly. As a nice benefit it isolates secret data to the "Encrypted"
>> message state. This effort was never merged into otr4j/otr4j. It would
>> require peer review as per original agreements.
> I see. Do you have any plans of merging it?

If I can find someone willing to do the review on this work, sure.
Currently, people seem to be preoccupied with other concerns.

>
> I have also found out your blog post, which I'm sharing as it sums out
> very nicely all of this work:
> http://dannyvanheumen.nl/post/refactoring-otr4j/ This is a very nice work.
Thank you.
>
>> * Peer reviews. The OTRv4 implementation strictly builds upon
>> https://github.com/cobratbq/otr4j.
>> * Adoption. (obviously)
> I think this is something we can help after the C library comes into place.
>
>> * I have not found a (suitable) Ed448-Goldilocks implementation for
>> Java. Currently I'm implementing a naive version myself. After the
>> otr4j version 4 support has sufficiently progressed, I may need some
>> help to optimize the implementation, including some constant-time
>> implementations.
> Yeah. Currently there is the 'libdecaf' library that Mike Hamburg
> implemented in C:
> https://sourceforge.net/p/ed448goldilocks/code/ci/master/tree/ This
> library does not only implement ed448-Goldilocks, but other curves and
> encodings as well. I'll suggest you take a look at libgoldilocks:
> https://github.com/otrv4/libgoldilocks This is basically the same
> implementation of Hamburg's library but with everything that is not
> ed448-Goldilocks taken away. Eventually the Golang implementation of
> ed448-Goldilocks will also come into place:
> https://github.com/twstrike/ed448
>
> Of course, it should be noted that internally Hamburg's library uses the
> "decaf" technique.

I have found all of the mentioned libraries, except for libgoldilocks.
Additionally, I found a rust implementation for Ed25519. I used all of
these to get my initial bearings. In the end, I got stuck on Mike's
original source code due to the amount of "extras":
* Some of the core code generated
* Decaf
* Pre-computed multiples (IIRC)
* constant-time operations
* Alternative representation, ... IIRC he used the Extended
representation at the time
* Not sure if Elligator was also in, in any case, I read about that too.

In the end, I could not figure out which parts were relevant and given
that I'm new to EC in general, it was too much information for me to
confidently, reliably extract the critical core parts. Currently, I've
picked up the necessary basics and noticed in the mean time that a lot
of OTRv4 depends on RFC 8032 approach, i.s.o. of plain Ed448-Goldilocks.
This also made it significant more approachable.

> It will be awesome to have a java implementation of Goldilocks.

The Ed448-Goldilocks parts will be in a separate repository. It may be
far from complete compared to Mike Hamburg's ref. implementation. But it
should contain most - if not all - of the parts that are not strictly
specific to OTRv4. (Ed448-Goldilocks basics and RFC 8032.)

>
>> * I would be interested to hear if any other implementors are willing
>> to set up a basic "test runner" that could set up otr testclients (in
>> various languages) to chat with each other, as way to do interop
>> testing. I've been thinking about this for a while but never got to
>> actually implementing it. It might be an interesting way to do interop
>> testing between Java, C and Go (etc.) libraries.
> This is a nice idea. Of course, it needs that the C library is finished ;)

And the Java library, for that matter ...

>
>> So far, I've only just started implementing. Mostly individual
>> snippets to discover the API I would expect from Ed448-Goldilocks. The
>> otrv4 changes are not in a public repo yet. However, they will in time
>> once there's some progress.
> From Ed448-Goldilocks you will basically need point addition, point
> subtraction, scalar multiplication and the EdDSA specific operations
> (encoding and decoding, sign and verification, private and public key
> generation). We can talk more about this if you like and how this
> operations are done in the C library :)

So far I've managed to do addition, multiplication and EdDSA operations.
I believe private key generation is slightly differently applied in
OTRv4 (IIRC not sure right now but I remember kdf1 or so being applied).
However, currently using Affine notation, i.s.o. one of the faster
defined representation as in hyperelliptic.org/EFD. (I started out with
Extended, but struggled with the math. I believe I know my mistake now.)
Additionally, the math currently relies on BigInteger, so I'm not
operating directly on byte[] yet.

Like I said, a naive implementation. I'll drop a note on this list, once
I'm far enough ahead that it makes sense to open it up for feedback. By
then I hope people will jump in to give feedback or help with optimizing
the implementation.

>
>> Few small points of feedback:
>> * The sections on signing and verifying user profiles apply RFC 8032
>> algorithms unmodified. However the spec currently defines the
>> SHAKE-256 application as KDF_2. I personally would prefer to use the
>> original SHAKE-256 as in the RFC to avoid confusion and doubt.
> I think you are completely right on this matter. Using SHAKE-256 in
> these sections should suffice.
>
>> * Last I've seen, it wasn't explicitly stated whether or not OTRv2 is
>> to be dropped. In the implementation I should be able to preserve
>> support for OTRv2, but is this desirable? (I know the modes imply
>> OTRv3 and/or 4, still ...)
> OTRv4 is backwards compatible only with OTRv3, and does not accept
> OTRv2. Speculatively, it should also be compatible with future versions.
> OTRv3 keeps its same compatibility.

Okay, that's clear. In that case, I would add that to the high-level
changes, such that there can be no confusion. OTRv3 is still compatible
with OTRv2 and so far I did not find any concrete parts where OTRv2 gets
broken, except for the defined operating profiles.

> [...]

Regards,
Danny

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20180321/d7ec34db/attachment.sig>