[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: TorChat is a security hazard (Answer)
- To: or-talk@xxxxxxxx
- Subject: Re: TorChat is a security hazard (Answer)
- From: Bernd Kreuss <prof7bit@xxxxxxxxxxxxxx>
- Date: Sun, 12 Dec 2010 15:03:40 +0100
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-talk-outgoing@xxxxxxxx
- Delivered-to: or-talk@xxxxxxxx
- Delivery-date: Sun, 12 Dec 2010 09:03:52 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=3VCFdXCgIQDlmGAzx56yxoT8rQ6T2yLVmQqCTWJbjGY=; b=NCnm8qIf1tN8//BABxm5acGUz9z9xevNqkA9dygU3ut0CVH7JF8h6ObOqFLnj2/aCa RwGUY1WpRnLAJUOYjIEFfg4IBgmVkI/7IZzzTGhPJy/RLwL5bApGYOeJ9EwdasDdW0Es kZxEm0dLYWQoZCr/ZINQKIRRERRIxWDkSO2OU=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=ZUlWB2Lo4bHiRb91Cm43GJeNmNFiJdaqTUrHN9+r57TJrqHR0M9yPZQdOXD1GkalsZ zWj7nkXdi5g1beXpHUVAElb18XsQ7Pxulx5rFe8LDGNrNM+KJnpPnUMSaotcDS7UmuT/ zYAofx2usAm0NTPS653QVB6Xh7H6EDh6hhy8I=
- In-reply-to: <20101212072651.GA2021@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Openpgp: id=3945A21D
- References: <4D03C983.7020009@xxxxxxxxxxxxxx> <20101212072651.GA2021@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[sorry for eventual double post, gmail replied to the sender instead of
the list]
On Dec 12, 2010 8:26am, Michael Blizek
<michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> proof. Suppose you have 3 peers A, B and C. B wants to impersonate A:
> A wants to establish a connection to B
This is where your example fails. A *can* not accidentally try to
connect B instead of C.
The only way to make A connect B would be that B first connects A and at
this point it would appear as a completely separate buddy with B's true
address in A's list. If TorChat sends a message it will always use the
outgoing connection. It would not send messages on incoming connections,
this means all messages that are intended to go from A to C (including
the authentication ping) will be sent directly to C. I don't see any
possibility to make a loop over 3 clients as long as both victims are
not patched somehow.
The intention for this architecture was to keep it *simple*, to use only
the mechanisms that Tor provides and to use them in the correct way and
to their fullest potential. I didn't try to re-invent or add anything
additionally on top of that, I used only simple obvious logic. I didn't
want to make yet another complicated thing that cannot be used by
ordinary end users because its proper usage would require a degree in
math and computer science. I wanted to make a tool that configures
itself automatically and just works out of the box. The cryptic 16
character addresses are already near the upper limit of the
comprehension of the average computer user. Usability has to be the
highest priority!
TorChat is exactly as strong as Tor's built-in mechanisms are:
* TorChat authentication/man-in-the-middle <-- Tor hidden_service can
not (easily) be impersonated
* TorChat end-2-end encryption <-- Tor hidden service end2end encryption
* TorChat anonymity <-- Tor anonymity
nothing more and nothing less.
If I had written a similar thing for i2p or any other similar network I
would have used only the mechanisms that would be available and built
into this network too.
Bernd
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFNBNY0xT6R4jlFoh0RAo2LAKCcbFb4+3r28U/LIycQuACVqpD2DACdHYnG
q2d519CuBCELokiCNsoNsa4=
=dHQV
-----END PGP SIGNATURE-----
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk in the body. http://archives.seul.org/or/talk/