[OTR-dev] OTR version 4 Draft #2

Mon Mar 19 16:47:51 EDT 2018

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
>

-------------- 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/20180319/138057f8/attachment.sig>