Delivery-Date: Thu, 07 Jan 2016 14:47:48 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 942DA1E0373;
	Thu,  7 Jan 2016 14:47:45 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 6C84728447;
	Thu,  7 Jan 2016 19:47:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id BC9302843F
 for <tor-talk@lists.torproject.org>; Thu,  7 Jan 2016 19:47:33 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ZS-6Bq6jW1a8 for <tor-talk@lists.torproject.org>;
 Thu,  7 Jan 2016 19:47:33 +0000 (UTC)
Received: from straum.hexapodia.org (straum.hexapodia.org [192.235.78.53])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 9C14821694
 for <tor-talk@lists.torproject.org>; Thu,  7 Jan 2016 19:47:33 +0000 (UTC)
X-Greylist: delayed 372 seconds by postgrey-1.34 at eugeni;
 Thu, 07 Jan 2016 19:47:33 UTC
Received: by straum.hexapodia.org (Postfix, from userid 22448)
 id 245DB4237; Thu,  7 Jan 2016 11:41:18 -0800 (PST)
Date: Thu, 7 Jan 2016 11:41:18 -0800
From: Andy Isaacson <adi@hexapodia.org>
To: grarpamp <grarpamp@gmail.com>
Message-ID: <20160107194117.GR13670@hexapodia.org>
References: <CAD2Ti2_i_=WrJzRA0xFks8Oc3YpRdQ8thtN0G942i=kQcGhu2A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAD2Ti2_i_=WrJzRA0xFks8Oc3YpRdQ8thtN0G942i=kQcGhu2A@mail.gmail.com>
X-Old-GPG-Fingerprint: 1914 0645 FD53 C18E EEEF C402 4A69 B1F3 68D2 A63F
X-GPG-Fingerprint: A5FC 6141 F76D B6B1 C81F  0FB7 AFA0 A45F ED3D 116D
X-GPG-Key-URL: http://web.hexapodia.org/~adi/gpg.txt
X-Domestic-Surveillance: money launder bomb tax evasion
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: cypherpunks@cpunks.org, tor-talk@lists.torproject.org
Subject: Re: [tor-talk] Chaum Fathers Bastard Child To RubberHose ...
	PrivaTegrity cMix
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On Wed, Jan 06, 2016 at 11:51:29PM -0500, grarpamp wrote:
> Nine server council... a hoseablitly focus point similar to Tor dirauths.
> In any case... interesting.

The privaTegrity (PT) backdoor is significantly more malignant than the
Tor dirauth issue.

If you pwn the Tor dirauths, you can sign and publish a false
"consensns" to clients that will cause them to use only your relays for
new connections, thus breaking anonymity for new connections.  Doing so
leaves a trail of bits showing that this was done (mostly just on the
target system).  Tor is actively seeking solutions to make their system
more privacy-preserving and if a better option shows up in research,
they will likely adopt it.

If you pwn the PT overlords, you can retrospectively deanonymize
connections that you recorded in the past.  If PT were deployed at scale
with a, say, 12-month deanonymization window [1] then every connection
during that interval would be silently deanonymized by APT0 who has
stealthily exfiltrated the overlord private material.

[1] the whole point of the PT backdoor and its claim to "break the
    crypto war stalemate" is that a lawful investigation could go back
    and ask "who sent this bomb threat".

If PT were deployed at scale and a vulnerability were found that used
the backdoor, the developers are left with an uncomfortable choice --
fix the vuln and thereby break the backdoor, or leave users vulnerable
and preserve the so-called "lawful" access?  This is not a conflict that
I want my privacy technologists to have to navigate.

Now, cMix seems like an interesting technology (much like the tech bits
of eCash were interesting back in the 90s, a previous #chaumism[3]).  I
chatted with one of the coauthors yesterday and there's clearly an
interesting performance improvement to existing mix networks; read the
paper[2] for more details.  But the PT system built on it is predicated
on an unrealistic model of datacenter security, international
geopolitics, network economics, cyberwar, and network reliability.

[2] https://eprint.iacr.org/2016/008.pdf
[3] https://twitter.com/hashtag/chaumisms

-andy
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

