
Off-the-Record Messaging Protocol v3 - dgellow
https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
======
moxie
This OTRv3 document has been available since at least 2012(?), so I'm not sure
why there's a sudden interest in discussing it, but here was our analysis of
OTRv3 at Open Whisper Systems:

1) The introduction of SIGMA in the switch from OTRv1 to OTRv2 significantly
reduced the "deniability" properties of OTR. The protocol does some explicit
things to provide "full" deniability, but in OTRv3 only people who've actually
had a conversation with Alice can produce a complete forged transcript with
Alice. More details: [https://whispersystems.org/blog/simplifying-otr-
deniability](https://whispersystems.org/blog/simplifying-otr-deniability)

2) OTRv3 doesn't work in asynchronous environments. It depends on a reliable
and synchronous transport that delivers messages in-order. The messaging
landscape is increasingly asynchronous, so OTRv3 is a difficult fit for modern
messaging protocols. More details:
[https://whispersystems.org/blog/asynchronous-
security](https://whispersystems.org/blog/asynchronous-security)

3) The OTRv3 "ratcheting" protocol is slow. It uses what we refer to as a
"three step ratchet," which provides less-than-ideal forward secrecy and
"future secrecy" semantics. More details:
[https://whispersystems.org/blog/advanced-
ratcheting](https://whispersystems.org/blog/advanced-ratcheting)

We sought to improve on OTRv3 by addressing these issues in the TextSecure V2
protocol, which we believe builds on the work of OTR to provide enhanced and
simplified deniability, an asynchronous-friendly environment, and optimal
forward and future secrecy semantics:
[https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2](https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2)

It also now supports group messaging and multi-device messaging, but we'll
cover those in a future blog post.

~~~
lawl
That is cool and all, but let me explain why I still prefer OTR.

OTR is a library that works with many different clients (pidgin, miranda,
irssi etc.). While as far as I know your stuff is pretty much baked in your
products. Correct me if i'm wrong please.

And I think that is exactly the problem. I've heard of TextSecure and looked
at it, but I never bothered to try it. Because it only seems to work with SMS
and MMS (at least that's what it advertizes). Now in Switzerland we have the
situation that a single SMS costs still about 10 cents (in USD and CHF). But
since I've got a traffic flat obviously I'd prefer to send messages over the
internet. I've used WhatsApp in the past, and it really was a great
replacement for SMS. But I've uninstalled it over privacy concerns.

I realize I'm kinda going off-topic, but I will take this chance to tell the
people who could fix this mess where my problems are.

\- TextSecure is still bound by phone number. So you can't use TOR to hide
your identity. Since it's using SMS you can't deny you ever talked to someone.
Your ISP can disprove that.

\- Again - there is no library to just leverage your protocol, even if it's
better than OTR.

Why can't we just have federated XMPP servers that use whispersystems crypto
protocol and maybe some XMPP extensions or a custom protocol to push from the
XMPP server to cellphones without battery drain.

If I could, I would fix this. But I don't trust my crypto skills. I could
never design a secure protocol from scratch. So _PLEASE_ create libraries
regular devs can use to make the world a better place. (OTR does this! At
least I would think I do have enough knowledge to use libotr correctly.)

Edit: Looking at the TextSecure code there is Push Notification stuff. So does
this use SMS or a messaging server on the interwebs? I'm actually confused
now.

~~~
Perseids
You should take a look at Threema. That does exactly what you describe afaikt
- except XMPP, its a walled garden - using NaCl.

Edit: I should probably elaborate:

\- It uses the internet connection to transfer messages

\- You can choose not to publicize your phone number and solely exchange keys
via QR-codes.

\- It uses NaCl which utilizes a permanent Diffie-Hellman key exchange to
derive a symmetric key for authenticated encryption. If you can decrypt your
messages, then you can forge them.

\- There is no desktop client yet, but it is on the far agenda.

\- It is not an open protocol.

Personally I don't think XMPP is a good basis for an asynchronous, encrypted
network protocol. It is extremely verbose and the extension that would make it
tolerable to use with unstable internet connection and multiple clients are
not supported by enough clients and servers. Also it misses an encryption
standard for asynchronous communication. And again I think OTR is not a good
basis for that. For example afaik there are no mechanisms for recipient key
selection in a non-interactive way.

PS: I would greatly appreciate some markdown dialect for the Hacker News
posts, if only to typeset lists.

------
lawl
When I saw this I really hoped I would click the link and it would say there
that OTRv3 supports group chats now. Sadly that is not the case. But support
for multiple logged in clients and a key for file transfer or voice is also
cool.

I would hope that means that libjingle based voice chat's can soon be OTR'd
too? Now pidgin just needs a decent interface for them...

Then we convince everyone to use XMPP (or google and facebook to [re]enable
XMPP federation) and we can finally drop Skype.

 _wakes up from his dream_

~~~
XorNot
A WhatsApp client with OTR would be sweet as well.

~~~
lawl
Technically there is no reason why it shouldn't have one.

If WhatsApp would just try to make their XMPP costumizations a standardized
XMPP extension and enable federation on their service. Finally we have unified
Instant Messanging.

 _dreams again_

(btw there's nothing stopping you from adding OTR support to one of the open,
reverse engineered, whatsapp clients)

~~~
xnyhps
> (btw there's nothing stopping you from adding OTR support to one of the
> open, reverse engineered, whatsapp clients)

Except, you know, DMCA notices:
[https://github.com/github/dmca/blob/master/2014-02-12-WhatsA...](https://github.com/github/dmca/blob/master/2014-02-12-WhatsApp.md).

Yes, this is complete bullshit. Especially how they try to use a DMCA notice
for trademark infringement.

------
hnolable
I believe the weakest link in OTR is its Diffie-Helman key exchange. If you
break that you get the symmetric key and can decrypt everything passively. OTR
has been using a 1536 bit modulus for its Diffie-Helman exchange since 2004
[1] (The weakest one from RFC 3526 [2]). Seems they are still using the same
one today.

In 2004 this was probably a fine choice, especially considering the tradeoff
between CPU processing (usability) and security. But considering the NSA
scandal, specifically them recording all encrypted communications forever, and
Bruce Schneier increasing his key lengths [3], and the ability for CPUs to
process higher keylengths without any noticeable slowdown, I don't feel
confident it is strong enough today.

Other than this gripe OTR is amazing and everyone should be using it.

Edit: xnyhps's post [4] concludes that only a single "cracking" of the 1536
bit group would need to occur to then decrypt any past or future OTR
conversation "instantly".

[1]
[https://web.archive.org/web/20041215062523/http://www.cypher...](https://web.archive.org/web/20041215062523/http://www.cypherpunks.ca/otr/Protocol.txt)
[2] [http://www.ietf.org/rfc/rfc3526.txt](http://www.ietf.org/rfc/rfc3526.txt)
[3]
[https://news.ycombinator.com/item?id=6376954](https://news.ycombinator.com/item?id=6376954)
[4]
[https://blog.thijsalkema.de/blog/2014/01/17/misconceptions-a...](https://blog.thijsalkema.de/blog/2014/01/17/misconceptions-
about-forward-secrecy/)

~~~
tptacek
OTR uses DH in a ratcheting protocol that requires attackers to continuously
break new DH exchanges; it's not like TLS, where one exchange at the beginning
of the session gives you the whole session.

Also, while a 1536 bit modulus isn't the best you can do in 2014 (we should
all be using curves now instead of doing DLP crypto), it's probably not within
reach of attackers right now. Effort doesn't scale linearly from those 1024
bit factoring problems.

~~~
xnyhps
> OTR uses DH in a ratcheting protocol that requires attackers to continuously
> break new DH exchanges; it's not like TLS, where one exchange at the
> beginning of the session gives you the whole session.

Please correct me if I'm wrong, but as far as I know the required effort to
break multiple DH exchanges doesn't scale linearly in the number of exchanges.
A single successful index-calculus attack on the used group will make breaking
additional key exchanges much easier.

~~~
pbsd
You're not wrong. The current state of the art puts the precomputation step at
complexity L_n(1/3, 1.923)§, and additional individual discrete logs at
L_n(1/3, 1.232). So individual logarithms are still subexponential and nothing
to scoff at, but they do become easier, yes.

Ignoring constant factors, for a 1536-bit prime this would mean cost ~2^102
for the initial precomputation, and ~2^66 for each individual log.

§ L_n(a, c) is the usual exp(c(1 + o(1)) (log n)^a (loglog n)^(1-a)).

~~~
bhitov
> The current state of the art puts the precomputation step at complexity
> L_n(1/3, 1.923)§, and additional individual discrete logs at L_n(1/3,
> 1.232).

Could you cite that? Not skeptical, just interested.

~~~
pbsd
Razvan Barbulescu's PhD thesis [1]. Note that the best asymptotic complexities
are a little different: the 'best' is really L_n(1/3, 1.902), but that variant
is hopeless in practice (it would require truly gigantic inputs for it to pay
off). Similarly, there is a "discrete logarithm factory" method, based on
Coppersmith's factorization factory, but that also has very large initial
costs that make it not very attractive in practice.

[1] [http://tel.archives-
ouvertes.fr/docs/00/92/52/28/PDF/these_a...](http://tel.archives-
ouvertes.fr/docs/00/92/52/28/PDF/these_avec_resume.pdf)

~~~
bhitov
Much appreciated =). I looked for references after reading the parent
discussions and xnyhps's blog post but was unsuccessful.

------
lvh
Not that I mind more people knowing about OTR, if you've seen OTR before, this
isn't new: v3 of the protocol is the current version, but we've had it for a
while now (Pidgin plugin has supported it since Sep 2012).

------
oleganza
OTR is designed to help Alice to repudiate her messages when an archive of her
conversation is taken by FBI from Bob's computer.

Alice might say: "Look, anyone could sign those messages as the keys were in
the clear!"

Judge will reply: "Unfortunately, the collected evidence is quite believable
and we have a couple of parallel constructions in place, so you don't have a
chance."

I don't believe in a technical possibility to disprove someone in a court of
law. Law is not mathematically defined, but interpreted quite frivolously
depending on how much out of favor with the state you are.

I'd rather focus on better protecting one's identity and carefully choosing
who to speak with in the first place. I'm afraid, OTR is just wishful
thinking. (However, technically it's pretty cool.)

~~~
nullc
I'm afraid you've misunderstood it.

The goal is to be no less non-reputable than unencrypted plaintext is— It's a
rather large shock when using encryption increases you risks, and OTR prevents
this.

It, obviously, cannot make anything more reputable than plantext was.

------
moeffju
OTRv3 was released in 2012. Can a moderator please add [2012] to the title?

------
vader1
Sadly, Adium trunk is still on libotr 3.2.1 (OTRv2) which gets so confused if
either party is using multiple simultaneous logins that I just disabled it for
most of my contacts who are on a mac.

~~~
xnyhps
Adium 1.6 will include libotr 4, it's already implemented in the nightlies.

------
flavor8
Wikipedia has a good ELI5 diagram of Diffie Hellman, which OTR uses:
[http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exch...](http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)

------
higherpurpose
I think Open WhisperSystems' Axolotl is superior to OTR now on several levels:

[https://www.whispersystems.org/blog/advanced-
ratcheting/](https://www.whispersystems.org/blog/advanced-ratcheting/)

