[userbinator]

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?

[baby]

SHA-256 has a 256-bit output. Truncated to 20 bytes/160-bit you effectively reduce the collision resistance to 80-bit and the (second) pre-image resistance to 160-bit. (This mean for example that you have to do around 2^80 operations (hash computations) to find a collision.)

80-bit of collision resistance is usually the number accepted for legacy cryptosystems or for lightweight crypto. It's not great but it's not "too bad".

By removing 96 bits from the state you also prevent length extension attacks (which SHA-256 is vulnerable to, see [1]). Or rather, provide 96-bit of security against them. Which should be enough.

This is better than using SHA-1 because SHA-1 has "efficient" chosen-prefix algorithms to find collisions while SHA-2 currently does not.

Now if it were me I would have chosen a hash function like KangarooTwelve which is faster, provides parallelization for large inputs, allows you to customize the output length and has received a substantial amount of cryptanalysis.

[1]: https://cryptologie.net/article/417/how-did-length-extension...

[scrollaway]

The problem with SHA1 being broken is unrelated to the amount of bits in the hash, so the point of switching to sha256 isn't to "increase the strength beyond the original 160 bits" but to avoid Shattered and future potential attacks.

[the8472]

There are 2 uses of the hashes in bittorrent. a) integrity checking b) as unique identifier for the swarm.

The hash only gets truncated when used in places as unique identifier. When you start with a v2 magnet link or torrent file you get the full 32bytes hash, which means your integrity-checking is unaffected.

[nenreme]

You download 32 bytes hash and check it using 20 byte hash from the magnet link.

[the8472]

http://bittorrent.org/beps/bep_0009.html#magnet-uri-format

[snakeanus]

Is there any plan to allow base64, longer hashes and selecting the hash algorithm in the magnet uri format?

[the8472]

No such plans. What would be the motivation anyway? A different hash function for the infohash calculation wouldn't change anything since other parts of the protocol would still use sha256 (v2) or sha1 (v1). So if this is about security, you wouldn't be changing the weakest link.

Not to mention that this would not be compatible with other peers, there is no algorithm-negotiation in the network protocols, so how would they know which hash you're using? The magnet link is pretty much the far end of the process, you'd have to change a lot of other things first.

[sha2throwaway]

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

[loup-vaillant]

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.

[simias]

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.

[loup-vaillant]

> 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.

[derefr]

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

[loup-vaillant]

Yeah, I keep forgetting about Hardware acceleration…

[snakeanus]

Length extension attacks are a non-issue for torrents.