Delivery-Date: Mon, 27 Oct 2014 19:32:21 -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=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,URIBL_BLACK 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 544531E0BEC;
	Mon, 27 Oct 2014 19:32:20 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 4FFA231080;
	Mon, 27 Oct 2014 23:32:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id F0C683107B
 for <tor-talk@lists.torproject.org>; Mon, 27 Oct 2014 23:32:12 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
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 E4htv6mr3EGG for <tor-talk@lists.torproject.org>;
 Mon, 27 Oct 2014 23:32:12 +0000 (UTC)
Received: from outbound.mailhostbox.com (outbound.mailhostbox.com
 [162.222.225.11])
 by eugeni.torproject.org (Postfix) with ESMTP id BEE6D31063
 for <tor-talk@lists.torproject.org>; Mon, 27 Oct 2014 23:32:12 +0000 (UTC)
Received: from [0.0.0.0] (tor-exit01.solidonetworks.com [94.126.178.1])
 (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
 (No client certificate requested)
 (Authenticated sender: s7r@sky-ip.org)
 by outbound.mailhostbox.com (Postfix) with ESMTPSA id 68C3E1918078
 for <tor-talk@lists.torproject.org>; Mon, 27 Oct 2014 23:32:08 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky-ip.org;
 s=20110108; t=1414452730;
 bh=CnFg9yylT5uxUNMr93iCd/NEJDhN2A7HAZVsMIf5Xhg=;
 h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References:
 In-Reply-To:Content-Type:Content-Transfer-Encoding;
 b=bIME7gb7nLkGTyM90oCujDnzAcbyV2kacRrLdwwFnKfJBqryKTn/ZkN35f92Z/2vl
 XbYMhFSQG/lXabcgLApj/MD6RonMpmSy2AS4BqiGM4Xa2180yY2WCrAK9u3m0LcTs+
 6ElwVw+Qu2SFPTAucjVKnjcfIng2QfZosPPquc1Y=
Message-ID: <544ED5F4.4030206@sky-ip.org>
Date: Tue, 28 Oct 2014 01:32:04 +0200
From: s7r <s7r@sky-ip.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <20141023191048.17a50660@meilong>
 <20141023232921.GF21428@torproject.org>
 <20141024103527.fd3ac8eff8862bf101b45d95@mega-nerd.com>
 <CAD2Ti2_QWc1Xq+uTvmurFLqjLVsSACMYYDzTAs7zk5SWyQE7Cw@mail.gmail.com>
 <544EA504.6070201@riseup.net> <544EC788.1010701@sky-ip.org>
 <20141027231908.GT4224@sescenties.(null)>
In-Reply-To: <20141027231908.GT4224@sescenties.(null)>
X-CTCH-RefID: str=0001.0A020201.544ED5FA.0084, ss=1, re=2.207, recu=0.000,
 reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 2.207
X-CTCH-Rules: C_4847,RISK_FREE,
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: s7r@sky-ip.org
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92
Subject: Re: [tor-talk]
 =?windows-1252?q?Bitcoin_over_Tor_isn=92t_a_good_idea_?=
 =?windows-1252?q?=28Alex_Biryukov_/_Ivan_Pustogarov_story=29?=
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Seth,

Totally agree about undermining decentralization by having to trust a
single provider. Nobody recommended that, the addresses were for
informative purpose only, to be used in parallel with other nodes run
by other operators / organizations. No user is forced to use
exclusively peers run by the same operator. An user is free to add as
many hidden nodes for bootstrapping as desired.  Once connected to a
node that node will exchange information about other nodes and so on.

I agree the hidden services are old. There is a nice proposal,
hopefully it will be analyzed more and implemented as soon as possible.


On 10/28/2014 1:19 AM, Seth David Schoen wrote:
> s7r writes:
> 
>> All use Bitcoin default port 8333. These servers are up all the
>> time and very fast.
>> 
>> Hidden services are end-to-end encrypted so the risk of MITM
>> between nodes does not exist. Also, if you run bitcoin in such a
>> way with onlynet=tor enabled in config, nobody listening your
>> wire can have a slight clue that you use bitcoin.
> 
> I don't mean to disparage the contribution of people who are
> running Bitcoin hidden service nodes.  I think that's a very
> useful contribution.
> 
> I do want to question three things about the benefits of doing so.
> 
> First, the security of hidden services among other things relies on
> the difficulty of an 80-bit partial hash collision; even without
> any new mathematical insight, that isn't regarded by NIST as an
> adequate hash length for use past 2010.  (There has been some
> mathematical insight about attacking SHA-1, which Tor hidden
> service names use, although I don't remember whether any of it is
> known to be useful for generating partial preimages.)  Tor hidden
> service encryption doesn't consistently use crypto primitives that
> are as strong as current recommendations, though I think they
> matched recommendations when the Tor hidden service protocol was 
> first invented.  That means that the transport encryption between a
> hidden service user and the hidden service operator is not as
> trustworthy in some ways as a modern TLS implementation would be.
> 
> Second, a passive attacker might be able to distinguish Bitcoin
> from other protocols running over Tor by pure traffic analysis
> methods.  If a new user were downloading the entire blockchain from
> scratch, there would be a very characteristic and predictable
> amount of data that that user downloads over Tor (namely, the
> current size of the entire blockchain -- 23394 megabytes as of
> today).
> 
> Not many files are exactly that size, so it's a fairly strong guess
> that that's what the user was downloading.  Even submitting new
> transactions over hidden services might not be very similar to,
> say, web browsing, which is a more typical use of Tor.  The amount
> of data sent when submitting transactions is comparatively tiny,
> while blockchain updates are comparatively large but aren't
> necessarily synchronized to occur immediately after transaction
> submissions.  So maybe there's a distinctive statistical signature
> observable from the way that the Bitcoin client submits
> transactions over Tor.  It would at least be worth studying whether
> this is so (especially because, if it is, someone who observes a
> particular Tor user apparently submitting a transaction could try
> to correlate that transaction with new transactions that the hidden
> services first appeared to become aware of right around the same
> time).
> 
> Third, to take a simpler version of the attacks proposed in the
> new paper, someone who _only_ uses Bitcoin peers that are all run
> by TheCthulhu is vulnerable to double-spending attacks, and even
> more devious attacks, by TheCthulhu.  (You might say that
> TheCthulhu is very trustworthy and would never attack users, but
> that does at least undermine the decentralization typically claimed
> for Bitcoin because you have to trust a particular hidden service
> operator, or relatively small community of hidden service
> operators, not to attack you by manipulating your view of the
> blockchain and transaction history.)
> 
> Using Bitcoin over Tor hidden services might be a good choice for
> most users today who want their transactions and private key
> ownership to be as private as possible, but it's not free of risk,
> and it's probably not an appropriate long-term solution to
> recommend to the general public without fixes to some of the
> technologies involved!
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUTtX0AAoJEIN/pSyBJlsRbQUIALs7C0PRT2IJa8OO5x+fVk9D
7bqL+1K1Aom62wyhBtkII2Z3/5yE6vMVmNgWfbn/oTfp1nLTmt1dGsJ7ZJmBwOXB
6tTchxeaphZzkTxGTAalE/TQ3Hdtpp0J3Z7kvXFWCyEnDfpAOc0ALF0sDNj56fGp
g9v5oifUBtu5s8XC6i+v+UkiKdZXEgZlvwHCPBTsJwNcSr64VYVu9m6bR45izfkI
RWH7dHsgxcnDsHaMd5p7oN4HFU8Gm2yooGHFdrHl5lNGtyfCHF2Jf7EnYBnzbHUN
B7J+NRR2wkj2WT6kTR4yRVr1vgeK0u66g0FPaRpMFinDT/h1MpKs5Rke15h6CKI=
=gHtN
-----END PGP SIGNATURE-----
-- 
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

