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

[s7r <s7r@xxxxxxxxxx>]

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



On 10/30/2014 6:30 PM, Seth David Schoen wrote:
> Gregory Maxwell writes:
> 
>> On Mon, Oct 27, 2014 at 11:19 PM, Seth David Schoen 
>> <schoen@xxxxxxx> wrote:
>>> 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
>> 
>> So?  80 bits is superior to the zero bits of running over the 
>> open internet?
>> 
>> (You should be imagining me wagging my finger at you for falling 
>> into the trap of seeming to advance not using cryptographic 
>> security at all since it's potentially not perfect)
> 
> I meant this only as a response to the previous poster's remark 
> that
> 
> Hidden services are end-to-end encrypted so the risk of MITM 
> between nodes does not exist.
> 
> I think the risk of MITM between nodes is extremely small.  But 
> 80-bit partial preimages are still a disturbingly small safety 
> margin today. It's kind of comparing apples to kumquats, but the 
> current Bitcoin network as a whole has a hashrate that (if it were 
> instead testing SHA1 hashes of RSA-1024 keys) could find such a 
> partial preimage in 25 days, on average.
> 
I still think that doing MITM over a Tor hidden service requires more
than just computing power to break 80-bit crypto security, as opposite
to if you were trying to MITM something with 80-bit security in the
clearnet. There are additional layers of encryption in Tor with better
security.

To be able to perform MITM over a Tor hidden service both the  HS
client and the HS server have to choose a total of 6 compromised
relays controlled by the same attacker. Someone has to be very very
unlucky, the odds in this context are insanely low.

Or maybe I am not understanding MITM as I should in this context - I
think MITM in the traditional way, not impersonating the HS,
performing DoS attacks on it or DoS attacks over the Hidden Service
Directory relays responsible for feeding HS descriptors to the clients.


> While replicating the hashing power of the entire Bitcoin network 
> is a truly staggering cost (to say nothing of the associated power 
> bill), that isn't where I'd like to see the order of magnitude 
> comparisons.
> 
>> Sure, though thats a one time transfer common to all Bitcoin 
>> users. Which the user may have already had most of previously,
>> or obtained from some other source.
>> 
>> At worst, that traffic has just identified you as someone who has
>> started up a Bitcoin node.
> 
> Well, here, I was responding to the previous poster's claim that 
> "nobody listening your wire can have a slight clue that you use 
> bitcoin".
> 

Having a hunch that someone might have started a bitcoin node and
downloaded the entire blockchain (if that someone didn't download it
via other means previously) is not equal to an observer being able to
see when you actually USE bitcoin (how often and other metadata, like
when you send a payment for example).

>> Bitcoin core intentionally obscures the timing of its transaction
>> relaying and batches with other transactions flowing through. It
>> could do much better, the existing behavior was designed before
>> we had good tor integration and so didn't work as hard at traffic
>> analysis resistance as it could have.
> 
> Cool, that sounds like a great area for an enterprising researcher
>  to investigate.
> 
>> In some senses Bitcoin transaction propagation would be a near 
>> ideal application for a high latency privacy overlay on tor, 
>> since they're small, relatively uniform in size, high value, 
>> frequent... and already pretty private and so are unlikely to 
>> gather nuisance complaints like email remailers do.
> 
> Do you have a sense of how it would affect payees' concerns about 
> double-spending attacks if the latency of transaction propagation 
> were increased?  Is the idea that privacy-enhancing latency 
> additions are only meant for cases where receivers are already 
> waiting for multiple confirmations?
> 
>> (New client software comes with foreknowledge of the work in the 
>> real network, so you cannot even provide a replacement 
>> alternative history without doing enormous amounts of 
>> computation, e.g. 2^82 sha256 operations currently to replicate 
>> the history).
> 
> That's a clever idea.
> 
>> As above, at least the 'trusted' operator has considerable costs 
>> to attack you... This is arguably a much stronger security model 
>> than using tor in the first place due to tor's complete reliance 
>> on directory authorities, for all you know you're being given a 
>> cooked copy of the directory and are only selecting among 
>> compromised tor nodes. This is one of the reasons that a some 
>> amount of work has gone into supporting multi-stack network 
>> configurations in bitcoin, so that you can have peers on each of 
>> several separate transports.
> 
> Tor's directory decentralization needs a lot of work, but the most
>  practical sybil attack in Tor is just the original -- making a
> lot of compromised nodes and hoping a user will repeatedly pick
> them. It still seems pretty clear that this can work against many 
> randomly selected Tor users at comparatively low cost (I'd agree 
> that that's cheaper than attacking randomly-selected 
> Bitcoin-over-Tor users with Bitcoin-related attacks, for the 
> reasons you mention).  On the other hand, I don't think we have a 
> clear path for a would-be Tor directory / consensus subverter to 
> follow.
> 
>> Normally when used with tor bitcoin nodes will use both HS and 
>> non-HS peers, and if non HS peers are available it will not use 
>> more than 4 non-HS peers.
>> 
>> However, because of the way tor's exit selection works the non-HS
>> peers usually end up entirely connecting through a single exit,
>> which is pretty pessimal indeed. We'd certainly like more control
>> of that, but the ability to create hidden services over the
>> control port would be a higher priority IMO... since right now
>> it's almost pointless to improve robustness to HS sybils when so
>> few people go through the considerable extra configuration to 
>> enable running a hidden service.
> 
> I wonder if anybody is working on that on the Tor end (or whether 
> it has any unexpected security consequences).  I guess it would 
> mean that someone who can compromise even a heavily sandboxed Tor 
> Browser would become able to use it as a hidden service server (at 
> least while it was still running) without the knowledge of the 
> browser's user.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUUm8sAAoJEIN/pSyBJlsRP/QH/isqAJk1G8Ub1Q4/K9GnOKTU
54+PF7OK2U0RxJOIGORekHfJh9gVNh1F+/mQnnUBc0LYCmMel9sRicw/Upk3kOGn
YTqfULcUpvOmz3n5NyBHzfb0uLZnMr34Pdxk+3pMl/FPOYZ9x+7eCducGWVf2Z3x
C/+96uBoyOpgqeE4spjRtc8H/WH5KP/YgPnV5fn5Eyd1nYugza6UTXRxNpKK/rLh
+BzXEObiV8NHLin2JdGO9+nkk/G3OLSnHCJil67VGKyKWi2awxFwZ8rvlGzr9kek
0yA3pd6wcBOt6rKMEGEn0JpyeBZhEpUhYAgDPZrdK1H7UD6nRRUwotEw8KAXQaQ=
=MALM
-----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