[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Bitcoin over Tor isn’t a good idea (Alex Biryukov / Ivan Pustogarov story)



-----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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk