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

The BitTorrent Protocol Specification v2

bittorrent.org

Post reply on HN
Print view View original

41–50 of 114 posts

Re: The BitTorrent Protocol Specification v2

#41

Post by mtgx »

AbacusAvenger wrote: post #28
RJIb8RBYxzAMX9u wrote: post #23

Earlier quoted context omitted.

Huh, I didn't know that's the case for x86. My quick search suggests that support is still quite limited though, and none of my HW (1~4 yrs old) support it. I suppose by the time the spec is finalized and widely adopted HW-accelerated SHA256 would be, too (and I should switch my zfs checksum back from SHA512/256 to SHA256).

I haven't found any Intel hardware with the SHA extensions actually implemented. I was expecting it in Skylake but apparently that's not the case... Not sure when we can expect to see them.

Intel has recently implemented SHA1 in hardware. So give it another decade or so.

Re: The BitTorrent Protocol Specification v2

#42

Post by loup-vaillant »

sha2throwaway wrote: post #38
userbinator wrote: post #15

Earlier quoted context omitted.

SHA256 truncated to 20 bytes What are the security implications of doing this? It seems it wouldn't increase the strength beyond the original 160 bits, no? Was there anything preventing redesigning the protocol to use full 32-byte SHA256 hashes throughout?

Actually you do get some added security, because it prevents the length extension attacks sha-2 and related hash functions have thanks to the Merkle-Damgard construction [0]. Specifically, by truncating the hash, the output no longer contains enough state to perform the attack. [0] https://en.wikipedia.org/wiki/Length_extension_attack

There are better ways to prevent length extension attacks, such as choosing Blake2b. With the current scheme, only 12 bytes are missing, so Length extension attacks only get 96 bits of security…

Replacing SHA-1 with SHA-2, what are they thinking? Blake2 is faster and more secure than either.

Re: The BitTorrent Protocol Specification v2

#43

Post by ko27 »

mtgx wrote: post #41
AbacusAvenger wrote: post #28

Earlier quoted context omitted.

I haven't found any Intel hardware with the SHA extensions actually implemented. I was expecting it in Skylake but apparently that's not the case... Not sure when we can expect to see them.

Intel has recently implemented SHA1 in hardware. So give it another decade or so.

SHA-1 & SHA-256 were both implemented at the same time.

https://en.wikipedia.org/wiki/Intel_SHA_extensions

Re: The BitTorrent Protocol Specification v2

#44

Post by derefr »

loup-vaillant wrote: post #42
sha2throwaway wrote: post #38

Earlier quoted context omitted.

Actually you do get some added security, because it prevents the length extension attacks sha-2 and related hash functions have thanks to the Merkle-Damgard construction [0]. Specifically, by truncating the hash, the output no longer contains enough state to perform the attack. [0] https://en.wikipedia.org/wiki/Length_extension_attack

There are better ways to prevent length extension attacks, such as choosing Blake2b. With the current scheme, only 12 bytes are missing, so Length extension attacks only get 96 bits of security… Replacing SHA-1 with SHA-2, what are they thinking ? Blake2 is faster and more secure than either.

They're probably thinking something about which hashes will get hardware-accelerated instructions provided on x86 and ARM.

Re: The BitTorrent Protocol Specification v2

#45

Post by sktrdie »

supergreg wrote: post #22
kpcyrd wrote: post #5

Earlier quoted context omitted.

It would be interesting to see how the new version compares to ipfs.

The tree structure seems very similar. It would be nice if torrent clients could interact with ipfs or gain ipfs capabilities. Think torrents that update themselves when the files change (thanks to ipns).

There's already such BEP: http://bittorrent.org/beps/bep_0046.html - "Updating Torrents Via DHT Mutable Items"

Re: The BitTorrent Protocol Specification v2

#46

Post by boyce »

jzelinskie wrote: post #6

This update to the spec is a modest change that's largely a preemptive reaction to SHA1 being broken; large portions of BitTorrent are designed around the 20-byte length of a SHA1 checksum. They've decided to move forward with SHA256 truncated to 20 bytes to avoid incompatibilities with existing infrastructure such as the Mainline DHT. Beyond the hashing algorithm, some important additions that were previously propos…

I'd love to see a p2p wikipedia and a p2p twitter alternative

Moving bittorrent away from it's present image could be achieved by making p2p useful beyond bluray rips

Re: The BitTorrent Protocol Specification v2

#48

Post by simias »

loup-vaillant wrote: post #42
sha2throwaway wrote: post #38

Earlier quoted context omitted.

Actually you do get some added security, because it prevents the length extension attacks sha-2 and related hash functions have thanks to the Merkle-Damgard construction [0]. Specifically, by truncating the hash, the output no longer contains enough state to perform the attack. [0] https://en.wikipedia.org/wiki/Length_extension_attack

There are better ways to prevent length extension attacks, such as choosing Blake2b. With the current scheme, only 12 bytes are missing, so Length extension attacks only get 96 bits of security… Replacing SHA-1 with SHA-2, what are they thinking ? Blake2 is faster and more secure than either.

Nobody gets fired for choosing SHA-256. It's the de-facto standard these days, it's the most likely to have hardware acceleration etc... I think it's a pretty conservative choice.

Furthermore I don't think hash performance is very critical for bittorrent, after all it's generally I/O bound.

Could you even exploit length extension with bittorrent? Given that it cuts files in chunks of the same size it sounds pretty hard to sneak extra bytes in there.

Re: The BitTorrent Protocol Specification v2

#49

Post by caf »

jacksonsabey wrote: post #27
Scaevolus wrote: post #16

1) Chunks don't span files . Each file is validated by the hash of its merkle tree. This is the biggest user-visible change, since it means you can download one file without downloading others. 2) SHA1 is replaced with SHA2-256 (2x longer hashes and not broken). 3) Files are represented by a tree structure instead of a list of dictionaries with paths-- this reduces duplication in deeply-nested hierarchies. 4) Backwar…

would 2 different torrents that contain a file with the same exact physical hash share the same torrent file hash? if torrent A and B both contain the exact same file, but torrent A only has the first half available, and torrent B has the second half available, could I combine both torrents to download that file? this could help fix old dead torrents or at least make the file searchable elsewhere by it's sha256 for e…

As long as they also have the same piece size.

Re: The BitTorrent Protocol Specification v2

#50

Post by loup-vaillant »

simias wrote: post #48
loup-vaillant wrote: post #42

Earlier quoted context omitted.

There are better ways to prevent length extension attacks, such as choosing Blake2b. With the current scheme, only 12 bytes are missing, so Length extension attacks only get 96 bits of security… Replacing SHA-1 with SHA-2, what are they thinking ? Blake2 is faster and more secure than either.

Nobody gets fired for choosing SHA-256. It's the de-facto standard these days, it's the most likely to have hardware acceleration etc... I think it's a pretty conservative choice. Furthermore I don't think hash performance is very critical for bittorrent, after all it's generally I/O bound. Could you even exploit length extension with bittorrent? Given that it cuts files in chunks of the same size it sounds pretty ha…

> hardware acceleration

Ah, that would explain a lot. (Not in this particular case, but why it seems to be the default choice in many settings).

> Could you even exploit length extension with bittorrent?

No Idea. I was just responding to a general point.

Post reply on HN