Delivery-Date: Thu, 07 Jan 2016 21:54:31 -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.1 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,T_DKIM_INVALID,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 D66071E04D4;
	Thu,  7 Jan 2016 21:54:29 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id A22C4218FC;
	Fri,  8 Jan 2016 02:54:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 129F021450
 for <tor-talk@lists.torproject.org>; Fri,  8 Jan 2016 02:54:22 +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 lEKeYES5EE1w for <tor-talk@lists.torproject.org>;
 Fri,  8 Jan 2016 02:54:22 +0000 (UTC)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com
 [IPv6:2607:f8b0:4002:c07::232])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id E2C04202A2
 for <tor-talk@lists.torproject.org>; Fri,  8 Jan 2016 02:54:18 +0000 (UTC)
Received: by mail-yk0-x232.google.com with SMTP id x67so349313810ykd.2
 for <tor-talk@lists.torproject.org>; Thu, 07 Jan 2016 18:54:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc:content-type;
 bh=zz6epomlyZixytth7s/74slpcDEbGape7lbFU+56x40=;
 b=uOEI4OPLPcelt3LWTjzkrIUJZYSktm4zl2zusB1gOupoubnHWAewvyGXRwW861G472
 RMI5jq55PT5fRDtpaEPz1cXcV3FCReo3wTyG8kjfOzV2Xgw+Qzf4PhdPKerOBUiuEOBB
 5lCqiETOKNpVr580vI5OOsPZzsz4yZnK2hUd8ZOgpmY7/pcCG3DplfsfjcbbyLlmKCdi
 6jleoY6cD111hFzpUBUJZFXmt3ShrjxU5BNqBhbwm6OHE5NPCzNpFBtO4iOYvJZ3n8Hv
 eFgwucJEkpD/yUXqqhfkDvKQ2YhJz7FBZwJRL2gl81CEH5k4HE3BInhWsvOWWnJqFXcq
 Gopw==
X-Received: by 10.13.231.5 with SMTP id q5mr43088957ywe.33.1452221656569; Thu,
 07 Jan 2016 18:54:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.102.66 with HTTP; Thu, 7 Jan 2016 18:53:57 -0800 (PST)
In-Reply-To: <20160107194117.GR13670@hexapodia.org>
References: <CAD2Ti2_i_=WrJzRA0xFks8Oc3YpRdQ8thtN0G942i=kQcGhu2A@mail.gmail.com>
 <20160107194117.GR13670@hexapodia.org>
From: Travis Biehn <tbiehn@gmail.com>
Date: Thu, 7 Jan 2016 21:53:57 -0500
Message-ID: <CAKtE3zeauoHjswqvjwA8zK2BE+johwZxYsq8RqGjtFs89Hhstg@mail.gmail.com>
To: Andy Isaacson <adi@hexapodia.org>
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Cc: "cypherpunks@cpunks.org" <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 Thu, Jan 7, 2016 at 2:41 PM, Andy Isaacson <adi@hexapodia.org> wrote:

> 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
>


To add;
It was surprising (to me) that Chaum should be the one to produce the first
of the modern 'solving the key escrow problem' algorithms. Academia has
been ignoring this particular problem for quite a while - I expect that
more proposed solutions will follow, solutions that will be more difficult
to prove insecure...

PT sounds like its rooted in threat models & crypto systems from 10-15
years ago - I'm not sure why anyone would migrate to this system - over
anything presently available (unless everything else is made illegal, of
course).

Check out cMix's 'beta' paper & make attacks as necessary.
http://www.scribd.com/doc/294737065/cMix-Anonymization-by-High-Performance-Scalable-Mixing

Some of Chaum's earlier work involved designing systems with arbiters where
3rd parties could prove evidence of misdeeds - this system, using threshold
secret sharing (right?), doesn't expose the same properties.

Which means that, of course, operators of routers are free to collude and
subject to TAO from various IA.

-Travis
-- 
Twitter <https://twitter.com/tbiehn> | LinkedIn
<http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn>
| TravisBiehn.com <http://www.travisbiehn.com> | Google Plus
<https://plus.google.com/+TravisBiehn>
-- 
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

