OTR Support (Off The Record)

[xagifu]

Note: I am not expert on encryption, so my understand could be misguided.

Tor Hidden Services are encrypted end to end it, but I see two problems with this encryption:

1. Tor Hidden Service Encryption standards is not top of the line encryption. I don't believe it has been updated in ten years.
2. If one of the users private keys is compromised then all the conversations that was relaying under that encryption key could be read.

Off The Record should provide Perfect Forward Secrecy (https://en.wikipedia.org/wiki/Forward_secrecy#Perfect_Forward_Secrecy) to negate this unlikely but still dangerous possibility.

[special]

Tor Hidden Service Encryption standards is not top of the line encryption. I don't believe it has been updated in ten years.

It is somewhat dated; there's an effort ongoing to design a next generation hidden service specification based on newer cryptography. See https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spec-ng.txt and the mailing list discussions on that topic.

If one of the users private keys is compromised then all the conversations that was relaying under that encryption key could be read.

There is an element of forward secrecy involved in hidden service circuits. Compromise of the private key does not retroactively compromise communications. For details, see the use of Diffie-Hellman in https://gitweb.torproject.org/torspec.git/blob/HEAD:/rend-spec.txt section 1.8 through 1.10.

I don't believe OTR has much to offer here. Encryption, authentication, and forward secrecy are provided by the rendezvous circuit, and if that is broken, there are a variety of issues that another layer of encryption on the raw text of communications won't solve. OTR's other headline benefit is deniability (in that others can forge messages, meaning others can't cryptographically authenticate a transcript after the fact); this is meaningless inside an authenticated connection.

It's also not suitable for securing other protocol traffic, or things like file transfers, which make it a very incomplete solution to any problem it does solve.

I'd like to hold off on trying to build in cryptography except where there's a valid, suitable design and a clear benefit. If it becomes useful to establish a stronger identity than a hidden service key, or there is a need for cases like group conversations, options will need to be evaluated.

[taoeffect]

It is somewhat dated; there's an effort ongoing to design a next generation hidden service specification based on newer cryptography. See https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spec-ng.txt and the mailing list discussions on that topic.

Outdated links?

All I see:

tree 5e10d93ace2636f7b26944488003aa60e8af51dd
parent 3bac19d0b31b54156ff42cda68dfa093e8d9552e
parent 2f13c587f0d30a4836194e5dfeaef060ce239179
author Nick Mathewson <[email protected]> 1445444403 -0400
committer Nick Mathewson <[email protected]> 1445444403 -0400

Merge remote-tracking branch 'teor/gitignore-osx'

[marfl]

Hi,

OTR's other headline benefit is deniability (in that others can forge messages, meaning others can't cryptographically authenticate a transcript after the fact); this is meaningless inside an authenticated connection.

This is not necessarily true. If Alice and Bob talk with each other, deniability means that Bob can't convince a judge of anything Alice said in that conversation. The way I see it, two things could be made "deniable" in the context of Ricochet:

1. The content of exchanged messages. I think this is already realized by layering on top of hidden services. A shared secret (generated via Diffie–Hellman) is used for encrypting and authenticating all data between client and HS (please correct me if I'm wrong). So, there is no way for Bob to prove that a statement was made by Alice - he could have forged it easily.
2. The fact that Alice and Bob talked with each other at all. Lets say that Alice initiates a connection to Bob. With Ricochet's current authentication mechanism, the fact that she wanted to talk with Bob is clearly undeniable (signatures using her public key etc.). Bob, however, could still deny that he wanted to talk to Alice (he was just listening for connections!) and that he talked to her after she authenticated herself. Because by that time both parties already shared a session key, so Alice could have faked all subsequent responses from Bob.

Now, this might be a separate issue, but I think Ricochet's authentication mechanism could be improved so that both Alice and Bob can later deny having communicated. I'm thinking about a protocol like this:

1. Alice opens a HS connection to Bob.
2. Bob immediately calculates a random ephemeral key b and sends g^b (b's "public" part) to his (at that time unknown to him) communication partner.
3. Using her private key A (the public part g^A forms her .onion address), Alice calculates a session key g^Ab (this is basically Diffie-Hellmann). Alice then sends her public key (g^A) and some message like "this is A talking to B (nonce)" back to Bob, using g^Ab for forming a MAC (authenticating the message).
4. Upon learning g^A, Bob can also calculate g^Ab, verify the MAC and believe Alice that its her.

However, Bob could also have faked the MAC, so Alice can still deny having talked with Bob. And Bob learns that it's Alice only in step 4, so he can deny wanting to talk to Alice as well. This is heavily inspired by the key exchange mechanism described here:

https://whispersystems.org/blog/simplifying-otr-deniability/

Compared to Ricochet's current auth mechanism, one full round-trip would be necessary before communication can start. So there would be a small delay.

[burdges]

I believe the correct issue for this is here : #72

As mentioned there, Axolotl is superior to OtR in basically every way relevant for messaging. In particular, Axolotl provides long-term forward-secrecy, while OtR provides only short-term forward-secrecy, exactly what ricochet gets from using Tor hidden services. And no extra round trips when starting sessions.