[OTR-dev] [OTR-users] otr dh key encryption

[Ileana]

Thanks for your replies.

I am trying to get this down to simple list of use cases, as to where to
use either service.  


On Mon, 18 Feb 2013 21:46:00 -0800
Gregory Maxwell <gmaxwell at gmail.com> wrote:

> You're really understating OTR's authentication advantages.  The SMP
> handshake allows you to use past social context to do a highly secure
> (brute force proof, it's a ZKP) authentication handshake without
> having to previously establish a secure channel to transmit high
> entropy data in... if you had a channel to securely establish a hidden
> service ID you might as well have exchanged a long lived symmetric key
> (And gained some hypothetical security against QC enabled
> adversaries).

I completely agree with this point...exchanging the hidden service keys
for tor chat should occur over another secure channel idealy.  However
people just publish their .onion addresses publicly.  These users
must not be concerned about traffic analysis or linking their contacts
too much...perhaps they are only interested in hiding their location.

I think you are right when OTR really shines when chatting with an
adversary, and the adversary not really being able to prove the logged
conversation was yours.  By retrieving a torchat hiddenservice key, and
captureed handshake, that would confirm you where having the chat and
the hidden service....and also linking you with anyone else that
captured traffic or has your onion address....

> 
> The availability point is really about the underlying transport with
> OTR. Presumably you could use OTR over personally run jabber servers
> over tor to get similar properties, though in both cases the tor
> network itself is subject to denial of service (and, in general,
> hidden services seem a bit more brittle than tor is over all).

I think the tor network as a whole is probably less subject to DOS
then a particular(pick one) IRC/Jabber server.  However, I don't
understand for instance the failover capabilities implemented for tor
directory authority servers which are needed for the network to
function.


> 
> > Encryption secrecy 	Perfect forward secrecy 	Perfect
> > forward secrecy Proof of Communication 	Retrieving hidden
> > service key is proof of running the service
> 
> This sort of misses OTR's main protocol innovation— it conducts its
> operation without binding the content with a cryptographic signature.
> So if you're talking to a traitor they can't log your signed packets
> and then prove to a third party what you said and yet the person you
> spoke to knows for sure it was you.
> 
> So there are two different kinds of denyability at play— being able to
> deny a conversation happened (which perhaps use with tor provides
> although traffic analysis is _very_ powerful) and being able to deny
> _what_ you said in the face of a defecting counterparty.  I don't
> believe the torchat provides denyable authentication. 

I would like to know if I can quote you in my article for explanations
like this.

> I'm not sure
> if torchat has denyable authentication or if something in the tor
> transport breaks that.

Tor chat is just a hidden service in tor, with text transmitted over
that channel.  Some one-way
hash of the hidden service key is the .onion address, which the client
and other nodes can verify.  So it is strong authentication.  Without
looking at the code, which is probably the only way to figure this out
(and the tor code is a maze trying to figure out which auth sections
are for nodes, which for hidden service, etc.)...the torproject
paraphrases that "tor verifies that the connection with the hidden
service is the .onion address you think it is."  So that is strong
authentication, which I don't believe is reputable if the hidden
service key is retrieved.

But beyond that I couldn't answer...Is the hidden service key also used
for encryption for of dh key exchange?  If so, the encryption itself is
the signature...as it is using the same key for authentication and
encryption, which is not recommended for this exact reason.

> 

> Neither torchat nor OTR use 256 bit AES, they both use 128 bit AES.

OK...this part I am pretty sure is a mistake.  Tor purports to use
AES-256 for all connections, including hidden services...I relooked at
the OTR code and see the that 16 bytes * 8 bits is indeed 128.




---------------------------
So this brings me to my concern complaint:  Something like tor is
making thousands of connections and transmitting Terabytes of data all
through these dh 1024 bit group -->AES-256 bit.  That is a lot of data.

From my review of the cryptographic recommendations for forward
secrecy, the 1024 bit group is too small, and the SHA-1 hash, still
used by tor, is also not recommended.  However, the thread field is
different:  An attacker potentially has to decrypt gigabytes of data
with many different connections (they might not know exactly which
connection contains the info they want).  So maybe for that purpose,
the lower encryption might be sufficient.

But OTR is for critical communication:  chats...communication which
ought to be the most secure you can have...in particular to brute-force
attacks, as it is more likely that an IRC operator for instance may
know exactly which OTR session he/she is interested in cracking.

Hence, OTR should really look to having the strongest encryption
available and reasonable.  On my machine, OTR currently takes about a
minute or so to generate a key...on another machine it seems like two
seconds(not sure if this is blocking on the prng?)

Is it reasonable that I don't want anyone to be able to decrypt my otr
connection for 30 years?

Anyway, I would be willing to wait 5 minutes to meet the recommended
strengths for key lengths:  In this case:

DH prime group:  2048-4096 bits
Hash function:  at least SHA-256
AES key length:  256 bits

In OTR's favor, the amount of cipher text is small, reducing some
crypt-analysis efforts.

So not a crypto expert (but learning)  but I can read www.keylength.com
and see that OTR does not meet recommendations for forward security.