Delivery-Date: Thu, 18 Jun 2015 02:37:05 -0400
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_SIGNED,
	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 75F1C1E0E61;
	Thu, 18 Jun 2015 02:37:03 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 1A5E136485;
	Thu, 18 Jun 2015 06:36:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 4654735F53
 for <tor-talk@lists.torproject.org>; Thu, 18 Jun 2015 06:36:56 +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 ec9hm_yD0pcR for <tor-talk@lists.torproject.org>;
 Thu, 18 Jun 2015 06:36:56 +0000 (UTC)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com
 [IPv6:2607:f8b0:4003:c06::22a])
 (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 18D3135E84
 for <tor-talk@lists.torproject.org>; Thu, 18 Jun 2015 06:36:56 +0000 (UTC)
Received: by oiyy130 with SMTP id y130so33625599oiy.0
 for <tor-talk@lists.torproject.org>; Wed, 17 Jun 2015 23:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:in-reply-to:references:date:message-id:subject
 :from:to:content-type;
 bh=TybOnnPwGc8EyAnLeM9ik9FxCpMlOwwZFJcmYTaXAZg=;
 b=LyfAP/5ez51LpzIZuBUjc8xtUWLfm+4JySX/8hZhS26R193eBhsbu3doo9UPz9Bf5I
 2b7AvRcR4yK9zlLhlwnshiJKtbHXJmI6Te2kwq/Wco7dMihKZHzBSWXATqZusns2vz+8
 W0QeBPonghsU7c+mnf9GGUpsS4mohJt3+XBOrtZJKHrE8phVaWPQRaAda3l2Gng1sBJC
 oTEXubrdaPoyUQ3segrRvIuaXDSXhECH+YmdrUEoD62pyo5y/LLE01NW6oZFfpipIb/M
 d9t/Pa1P2CIbNfOGlHgHisDAApoi/lAk5VMVlfzZh6LLEjdoacbWEPlyRdGF7c/87Raj
 Hq3g==
MIME-Version: 1.0
X-Received: by 10.202.196.11 with SMTP id u11mr7402307oif.8.1434609413854;
 Wed, 17 Jun 2015 23:36:53 -0700 (PDT)
Received: by 10.182.49.193 with HTTP; Wed, 17 Jun 2015 23:36:53 -0700 (PDT)
In-Reply-To: <CAMTdTS94DVNt6LsiujHJbUSzRPBbXYzi_Kkk+spCsM0Q12pHWw@mail.gmail.com>
References: <CAD2Ti2-xVw_W2YDqkdQHmcHyKBDQjfT5jvc-8m3EAU8UkqxrUA@mail.gmail.com>
 <20150618045108.GE7957@moria.seul.org>
 <CAMTdTS-0j1Efpfg=2aMynD-rvQyu9nQjmRcRF-Ziq=ZV4q97Jw@mail.gmail.com>
 <CAMTdTS94DVNt6LsiujHJbUSzRPBbXYzi_Kkk+spCsM0Q12pHWw@mail.gmail.com>
Date: Wed, 17 Jun 2015 23:36:53 -0700
X-Google-Sender-Auth: O5Y9FnhywqCmfGm4KnFLhdFex74
Message-ID: <CAMTdTS9=hkTicK99LFa5KZ5ad=EpH6VhLVMVoShekop_8j3YdQ@mail.gmail.com>
From: benjamin barber <barberb@barberb.com>
To: tor-talk@lists.torproject.org
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] Matryoshka: Are TOR holes intentional?
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>

His project was started in july of 2006, which he seems to have been
spearheading in a family business, to supply dark net services to christian
fundamentalists.

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4105#ShofarNexus

The guy ran for congress back before the turn of the millennium, so I dont
know if he is brilliant and misunderstood, or if he is a con artist playing
a part.


On Wed, Jun 17, 2015 at 10:59 PM, benjamin barber <barberb@barberb.com>
wrote:

> http://shofarnexus.com/Download
>
> On Wed, Jun 17, 2015 at 10:43 PM, benjamin barber <barberb@barberb.com>
> wrote:
>
>> I didn't have a problem finding Matryoshka networks but not software
>> called "Matryoshka", just as were not using running "onion software",
>> some different software use the Matryoshka network method to communicate.
>>
>>
>> On Wed, Jun 17, 2015 at 9:51 PM, Roger Dingledine <arma@mit.edu> wrote:
>>
>>> On Thu, Jun 18, 2015 at 12:02:45AM -0400, grarpamp wrote:
>>> >  We also need to take a serious look at TOR, and
>>> > without emotional bias, consider if a serious flaw was designed in.
>>>
>>> "Traffic analysis is the first hole plugged by Matryoshka, but ignored
>>> by TOR."
>>>
>>> I couldn't figure out how to actually fetch this "Matryoshka" software,
>>> but it sure looks like another case of somebody not understanding the
>>> research field, and thinking that solving the traffic confirmation
>>> attack is easy, without actually thinking through the engineering side,
>>> the scaling side, or the statistics side.
>>>
>>> For background see e.g.
>>> http://freehaven.net/anonbib/#danezis:pet2004
>>>
>>> It makes sense that if you think solving the problem is easy, you
>>> wonder why Tor hasn't solved it.
>>>
>>> But even full scale padding, ignoring the practical side of how to get a
>>> Tor network that can afford to waste so much bandwidth, doesn't provide
>>> protection in the face of active attacks where you induce a gap on one
>>> side and then observe the gap on the other side. And it might even be
>>> the case that these gaps happen naturally by themselves, due to network
>>> congestion and so on, so maybe passive observers will be winners even
>>> against a design that does full padding.
>>>
>>> Also, to make it really work in practice, all users are going to need
>>> to pad not just while fetching their web page or iso or whatever, but
>>> sufficiently before and after that too, else an attacker can match up
>>> start times and end times:
>>> http://freehaven.net/anonbib/#murdoch-pet2007
>>>
>>> This is a great area for further research:
>>> http://freehaven.net/anonbib/#ShWa-Timing06
>>> http://freehaven.net/anonbib/#active-pet2010
>>>
>>> tl;dr the whole premise of this person's blog post is flawed, since
>>> their design likely does not work as they think it does.
>>>
>>> --Roger
>>>
>>> --
>>> 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
>>>
>>
>>
>
-- 
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

