[OTR-dev] OTR version 4 Draft #2

[Sofia]

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?

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.


> * 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.

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

> * 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 ;)

> 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 :)


> 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.

> * As mentioned before, it may be good to define how state transitions
> look in case multiple clients respond to a query message. (That is,
> single account, multiple active chat clients.) With clients having
> mixed OTR protocol versions. I'm happy to be involved in this
> discussion if you need a more practical perspective.

Instance tags should work for some of these cases. Section "Receiving a
Query Message" details how the different versions are handled. I think
it should be better detailed in the protocol or maybe somewhere else.
Let's start some discussion around that, so I'll probably create an
issue around this ;)

> * I think I read somewhere in an issue on the otrv4 github that you
> may rename "UserProfile" to "ClientProfile" or something, because it's
> corresponds better to the intention of this profile. Reading this
> particular suggestion in itself clarified a few things I did not
> realize before, so I'm all for doing this name change.

Yeah, I think it is probably a good idea to change the name as the "User
Profile" is generated per client/device basis. Mmm...


Thanks for the work and for looking at this!

On 3/19/18 3:47 PM, Danny van Heumen wrote:
> Hi all,
> 
> 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. 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.
> 
> In time, I could use some help:
> * Peer reviews. The OTRv4 implementation strictly builds upon
> https://github.com/cobratbq/otr4j.
> * Adoption. (obviously)
> * 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.
> * 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.
> 
> I will most likely update Jitsi (desktop client) to otrv4 support simply
> to be able to test the library in an application.
> 
> 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.
> 
> 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.
> * 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 ...)
> * As mentioned before, it may be good to define how state transitions
> look in case multiple clients respond to a query message. (That is,
> single account, multiple active chat clients.) With clients having mixed
> OTR protocol versions. I'm happy to be involved in this discussion if
> you need a more practical perspective.
> * I think I read somewhere in an issue on the otrv4 github that you may
> rename "UserProfile" to "ClientProfile" or something, because it's
> corresponds better to the intention of this profile. Reading this
> particular suggestion in itself clarified a few things I did not realize
> before, so I'm all for doing this name change.
> 
> Regards,
> Danny
> 
> 
> 
> On 03/16/2018 05:39 PM, Sofia wrote:
>> Hey!
>>
>> I am Sofia from the team that previously sent a draft of the OTRv4
>> protocol. We, as a team, would like to present the third version of this
>> draft. It has been reviewed by Ian and Nik two times in the interim. The
>> draft is at Github[1].
>>
>> There are many changes on this version as compared with the version 3 of
>> the OTR protocol. Just to briefly summarize them:
>>
>> * Security level raised to 224 bits and based on Elliptic Curve
>> * Cryptography (ECC) (using ed448, Goldilocks, -huge thanks to Mike
>> Hamburg!-).
>> * Additional protection against transcript decryption in the case of ECC
>> compromise.
>> * Support for both online and offline conversations.
>> * Support for an out-of-order network model.
>> * The following cryptographic primitives and protocols have been updated:
>>   * Deniable authenticated key exchanges (DAKE) using "DAKE with Zero
>> Knowledge" (DAKEZ) and "Extended Zero-knowledge Diffie-Hellman" (XZDH).
>> DAKEZ corresponds to conversations when both parties are online
>> (interactive) and XZDH to conversations when one of the parties is
>> offline (non-interactive).
>>   * Key management using the Double Ratchet Algorithm.
>>   * Upgraded SHA-1 and SHA-2 to SHAKE-256.
>>   * Switched from AES to XSalsa20.
>> * Support for different modes in how the specification can be used
>> (OTRv4 only, OTRv4+v3 compatibility mode, OTRv4 interactive only).
>> * Explicit instructions for producing forged transcripts using the same
>> functions used to conduct honest conversations.
>>
>> The DAKEs we are using are based upon the ones defined by Nik and Ian in
>> their paper: Improved Strongly Deniable Authenticated Key Exchanges for
>> Secure Messaging[2]. Nik will be talking about them at the next PETS
>> [3], if you are interested, or you can check this diagram around them [4].
>>
>> Previously, there were some comments inquiring whether this was the
>> "official" draft of OTRv4. As we have been closely working with Ian and
>> Nik on this, we consider this an official version 4 of the OTR protocol.
>> Just for context, this version of the protocol started with a discussion
>> held at the beginning of March, 2015, at the IFF - you can see the
>> report and discussion about that beginning here [5].
>>
>> This proposal have had two reviews. We briefly held a meeting around it
>> with Ian at Real World Crypto, 2018.
>>
>> Notice that the draft points to another specification for how a prekey
>> server used for offline conversations works. This specific specification
>> is still a work in progress. But we will finish it soon. ;)
>>
>> We are sending this in order to get a third review from Nik and Ian, but
>> also to get the opinions, thoughts, discussions and much more from the
>> OTR community. This is by no means a finished draft, so, we welcome your
>> feedback on it (please, do so).
>>
>> Let's discuss and share our opinions! :)
>>
>> Thanks and have a very good weekend!
>>
>> The OTRv4 team
>>
>> 1- https://github.com/otrv4/otrv4/blob/master/otrv4.md
>> 2- http://cacr.uwaterloo.ca/techreports/2016/cacr2016-06.pdf
>> 3- https://petsymposium.org/2018/paperlist.php
>> 4- https://cs.uwaterloo.ca/~njunger/dake_csdf17_poster_72dpi.png
>> 5- https://lists.cypherpunks.ca/pipermail/otr-dev/2016-March/002447.html
>>
> 
> 
> 

-- 
Sofía Celi (aka cherenkov)
@claucece / @cherenkov_d
EF74 1A5F 5692 E56F 14F6  243C 3992 6144 F89D 996F

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