Re: TorChat is a security hazard (Answer)

[Michael Blizek <michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Hi!

On 19:57 Sat 11 Dec     , Bernd Kreuss wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> I found this message from February in the archives and since the
> original message ID is hidden I cannot write a follow up, so I start a
> new thread to comment on the topic:

...

> I am the original developer of TorChat and I feel the need to comment
> the above message. Point 1 is about the supposedly missing
> authentication and points 2 and 3 are direct consequences of point 1.
> 
> I did not yet write any paper that explains the protocol in detail, it
> is all "hidden" in the source and in the source code documentation of
> the message classes. I will now try to explain how it works.
> 
> > 1. No authentication.
> 
> This is not true. There is authentication, the incoming connection must
> prove that it is reachable under the .onion address it pretends to be by
> correctly answering pings with random numbers that are sent to this
> address. The connection procedure is as follows:
> 
> * client A will connect the hidden service of client B
> * after successful TCP connection to B it will send its own hidden
> service ID (its onion address) to client B along with a ping message
> containing a random number.
> * client B will now try to connect back to the (still untrusted) address
> given to him in this (still anonymous) incoming connection.
> * after successful TCP connection it will also send its own address to A
> along with a ping message and also the pong to A's ping message.
> 
> * A will receive the pong on the incoming connection for the ping it has
> sent over the outgoing connection and now knows that the incoming
> connection undoubtedly belongs to the outgoing connection to B. It will
> then also answer the ping from B
> 
> * B will receive the pong to the ping that it has sent and also know
> that this incoming connection undoubtedly belongs to A

I have not participated in the previous discussion. This concept sounds like
reinventing diffie-hellman to me - except it does not fully man in the middle
proof. Suppose you have 3 peers A, B and C. B wants to impersonate A:

A wants to establish a connection to B and sends B a cookie + A's .onion
address. B does *not* connect back to A, but sends the cookie and A's
.onion address on to C. Then C will connect back a A and send A its cookie.
A sends the cookie to B and B sends it on to C.

Now B can read and manipulate the messages A sends to C. Of course, this
requires that A knows and wants to contact B, not C. And A will probably get
suspicious because suddenly C answers, not B.

Anyway, why not do a complete diffie-hellman key exchange on both the incoming
and outgoing connoction and then combine both keys to do symetric encryption
on top of tor? OK, it is probably a bit paranoid, but...

	-Michi
-- 
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/