Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BitTorrent v2 (2020)

blog.libtorrent.org

Post reply on HN
Print view View original

131–140 of 155 posts

Re: BitTorrent v2 (2020)

#131

Post by marcan_42 »

aumerle wrote: post #77
marcan_42 wrote: post #21

Earlier quoted context omitted.

This is not true. Modern cryptography is not breakable via brute force any more, nor will it ever be. You can prove that the amount of energy required assuming a thermodynamically ideal computer is more than will ever be available in our galaxy, with classical computing. Breaks of symmetric crypto or hashes that are practical require an actual cryptographic weakness, whose existence is not a given. Then there's quant…

That is not true. There is nothing provable about hash functions. The best that you can say is that there is no known algorithm that can calculate a pre-image for any given hash function in less than some super linear time. You certainly cannot prove that no such algorithm exists. If you can prove it please publish a paper you will be revolutionize mathematics.

> The best that you can say is that there is no known algorithm that can calculate a pre-image for any given hash function in less than some super linear time.

If your algorithm is not linear in the size of the key/hash space, it's not a brute force algorithm. It's a cryptographic break.

There is no proof that such algorithm does not exist, nor is there any proof that it does. Therefore you can't claim it definitely does. That's my point.

Re: BitTorrent v2 (2020)

#132

Post by hiq »

WithinReason wrote: post #124
hiq wrote: post #102

Earlier quoted context omitted.

Unfortunately BitTorrent is still heavily centralized when it comes to discoverability. Without a website hosting .torrent files or magnet links, it's very limited.

Not at all, a DHT crawler can gather Torrent links over time in a fully decentralized way.

Without curation it's not worth much.

Re: BitTorrent v2 (2020)

#133

Post by zinekeller »

capableweb wrote: post #118
MuffinFlavored wrote: post #107

Earlier quoted context omitted.

It kind of does if you choose to seed stuff that is ripe for DMCA takedowns/copyright infringement, right? That's not the protocol's fault, but it's pretty much one of the biggest reasons most common people use the protocol: to pirate. Get caught pirating? Probably get some fines, right?

DMCA and most copyright holders would only hold power over ~4.25% of the population in the world, as the rest of us lives outside the US and are not impacted by US laws. Some countries like to pretend they actually handle DMCAs as well, but if you push back they won't even take it to court.

> Some countries like to pretend they actually handle DMCAs as well, but if you push back they won't even take it to court.

Sheesh, please do a more thorough research. It's technically not DMCA (because it's not called DMCA), but Germany and Japan do have similar laws analogous to DMCA, and I'm pretty sure that further digging would reveal more countries that have an analogous process written in law.

Re: BitTorrent v2 (2020)

#134

Post by marcan_42 »

dooglius wrote: post #36
marcan_42 wrote: post #21

Earlier quoted context omitted.

This is not true. Modern cryptography is not breakable via brute force any more, nor will it ever be. You can prove that the amount of energy required assuming a thermodynamically ideal computer is more than will ever be available in our galaxy, with classical computing. Breaks of symmetric crypto or hashes that are practical require an actual cryptographic weakness, whose existence is not a given. Then there's quant…

Do you have a cite for this for SHA256? It surprises me a bit as our galaxy is big and we are far from physically ideal computers.

I did the math myself at one point, but I lost the link. However, here's a reference for the same kind of thing:

https://pthree.org/2016/06/19/the-physics-of-brute-force/

The total energy output of a supernova is enough to count up to 2^220, making a lot of generous (invalid) assumptions. You'd need 2^36 supernovas to just count up to 2^256, never mind actually running SHA256. At minimum.

There are circa 2^38 stars in the Milky Way, and they're not going to all go supernova. Add in the actual cost of compute and it just isn't happening, not in this galaxy.

For 128-bit crypto we can look at a more earthly calculation. Using the same math as that article, but at room temperature, and taking the total solar irradiance on the Earth as an energy source, it would take this long to count up to 128 bits (calculated using Google):

((2^128) * (1.38064852 * ((10^(−16)) (ergs / K))) * (298 K)) / ((1361 (W / (m^2))) * (pi * (radius of Earth^2))) = 8.04911615 seconds

Definitely more on the plausible side, but we're already moving away from 128-bit crypto and there's a staggering number of generous assumptions being made here; we aren't going to be getting thermodynamically ideal computers using a significant fraction of the total solar irradiance on the Earth any time soon.

Just to give you an idea of how far away we are from that, looking at actual SHA256 calculations:

https://www.iea.org/data-and-statistics/charts/efficiency-of...

22222 MH/J is the highest, or 4.5 × 10^-12 joules per hash. That's a factor of 2^30 worse, so if we used the total solar irradiance of the Earth to power Bitcoin miner style ASICs, it would take about 272 years to go through 128 bits' worth of brute forcing something of similar complexity to SHA-256.

The factor is more like 2^36 relative to the first "temperature of outer space" calculation. That happens to be about the number of galaxies in the observable universe, so using current technology, it would take somewhere on the order of all the stars in the observable universe going supernova to power through a single SHA-256 brute force.

Re: BitTorrent v2 (2020)

#135

Post by marcan_42 »

xoa wrote: post #29
marcan_42 wrote: post #21

Earlier quoted context omitted.

This is not true. Modern cryptography is not breakable via brute force any more, nor will it ever be. You can prove that the amount of energy required assuming a thermodynamically ideal computer is more than will ever be available in our galaxy, with classical computing. Breaks of symmetric crypto or hashes that are practical require an actual cryptographic weakness, whose existence is not a given. Then there's quant…

> Modern cryptography is not breakable via brute force any more Specifically, modern symmetric crypto (and hashing which is a related but different thing) is fine. It's public-key crypto that has always been the worry thanks to Shor's Algorithm, and all modern widely used crypto there is indeed vulnerable if an actual scalable general quantum computer could be constructed. There are a variety of post-quantum cryptogr…

I know about Grover's Algorithm, but the reason I didn't want to make any hard claims is that with hashes you also have to worry about collision attacks. Those give you an O(sqrt(n)) time advantage themselves in classical computing, at the expense of space for storing existing hashes (birthday attack), and you can play with the balance as a space-time tradeoff. I can't claim to have any idea how those interact with quantum crypto, plus once you introduce storage at a large scale I imagine you start running into speed of light and communication energy cost issues.

Re: BitTorrent v2 (2020)

#136

Post by twic »

dennis-tra wrote: post #12

I‘m wondering if they could avoid yet another breaking protocol change if SHA256 proves to be insecure (at some point in the future) if they made use of Multiformats [0]. At least IPFS went this way (Multiformats grew out of the IPFS development). [0] https://multiformats.io/

The magnet URL format is at least using multihash:

> Like the urn:btih: prefix for v1 SHA-1 info-hashes, there’s a new prefix, urn:btmh: for full v2 SHA0256 info hashes. For example, a magnet link thus looks like this:

> magnet:?xt=urn:btmh:&dn=&tr=

> The info-hash with the btmh prefix is the v2 info-hash in multi-hash format encoded in hexadecimal.

Re: BitTorrent v2 (2020)

#139

Post by ikt »

300bps wrote: post #13
ikt wrote: post #4

Earlier quoted context omitted.

i do love that it immediately goes into yet another crypto bashing comment chain while not realising that a crypto company owns bittorrent: https://torrentfreak.com/bittorrent-inc-confirms-acquisition... and that after the creator of bittorrent left he created his own cryptocurrency: https://en.m.wikipedia.org/wiki/Chia_(cryptocurrency)

That “crypto bashing comment chain” is just as relevant today as it was when it was posted 16 months ago. People are still struggling to articulate a legitimate use case for cryptocurrencies. I made some money mining BTC way back in the day with a GPU. I bought a new computer for $1,900 last year and much more than paid for it mining ETH. I’ve spent years now listening to all the claims from BTC, BCH, BSV and a dozen…

> But I’ll be damned if I can articulate a legitimate use for it

What's wrong with DeFi?

Re: BitTorrent v2 (2020)

#140

Post by gkfasdfasdf »

Dylan16807 wrote: post #113
SethTro wrote: post #108

Earlier quoted context omitted.

It is highly unlikely that the duplicate portions of the file will have an offset that's a multiple of 2^16 which would be required for chunks to have matching hashes. On the client side you could theoretically run lbfs over your files but on the swarm side this isn't going to happen

> It is highly unlikely that the duplicate portions of the file will have an offset that's a multiple of 2^16 which would be required for chunks to have matching hashes. That's exactly what chunking based on a rolling hash solves. You set the average size of chunks and the content controls the exact boundaries.

Right, exactly. Chunk boundaries are not determined by fixed size chunks, but rather when the rolling hash matches some prefix, which means chunk sizes will vary but by controlling the prefix can set the average size of the prefix. Besides the lbfs paper, another nice writeup here: https://moinakg.wordpress.com/2013/06/22/high-performance-co...
Post reply on HN