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 <[email protected]> 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. _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
