[OTR-dev] OTR version 4 Draft #2
Daniel '.koolfy' Faucon
koolfy at koolfy.be
Mon Mar 19 05:32:26 EDT 2018
On Friday 16 Mar 2018 à 22:55:32 (+0000), Carsten Mattner wrote:
> On 3/16/18, Sofia <sofia at autonomia.digital> 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.
> > 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.
> Thank you for working on this! I still use XMPP+OTRv3 because:
> 1. XMPP has comfortable clients of choice (on desktop, native)
> 2. OTRv3 just works
> 3. OMEMO is only supported in a few clients and incompletely at that,
> and it doesn't work seamlessly like libotr integration in Pidgin
> or mcabber
> I suppose (couldn't find it) that there is a libotr branch implementing
> the draft, right? This is very important if we want to upgrade pidgin,
> weechat, mcabber, jackline, adium, etc to OTRv4.
Allow me to jump in, as weechat is mentionned.
I contributed to the weechat plugin (weechat-otr), and then to its underlying
python OTR implementation (pure-python-otr, aka potr), for which I am the current
As much as I'm excited about all this, and *will* read this draft, I have
bad news for weechat adoption, and python clients in general.
The current state of potr is bleak. I'm having a hard time finding time and energy
for this project, and there is much to be done. Allow me to elaborate.
Before we can talk about implementing an otrv4 for weechat, we need to finish potr
support for otrv3. Right now it lives in a post-2/pre-3 state that freaks me out.
Before we can talk about finishing the otrv3 support, we must finish switching over
to a better (=maintained) underlying primitives library (pycrypto -> pycryptodome)
which still requires some work to comply with the CTR handling described in the RFC
As you can see this has been in my "urgent" bin for more than a year now.
And then there's the fact that the current git "stable" was never packaged, so any
distribution-published package is grossly out of date and contains ugly old bugs.
TL;DR: Any python client is stuck with potr, which is miles away from being
less than hacky at the moment, and lightyears away from any OTRv4 support :(
This directly affects at least weechat (irc) and Poezio (xmpp), that I know of.
I have booked a weekend to fixing issue 68 early April, but clearly, being
alone won't cut it in the longterm.
… and then there's the whole debate about whether a python implementation *can*
be secure at all, which I won't even get into.
I think having a proper python OTRv4 implementation would do great things for
If this matters to you, please send help :(
More information about the OTR-dev