Re:The BitTorrent Protocol Specification v2
by loup-vaillant on Tuesday August 08, 2017 @03:05AM
(#14955196)
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
by simias on Tuesday August 08, 2017 @04:35AM
(#14955769)
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
by loup-vaillant on Tuesday August 08, 2017 @04:45AM
(#14955810)
> 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.
Re:The BitTorrent Protocol Specification v2
by derefr on Tuesday August 08, 2017 @03:59AM
(#14955516)
They're probably thinking something about which hashes will get hardware-accelerated instructions provided on x86 and ARM.
Re:The BitTorrent Protocol Specification v2
by loup-vaillant on Tuesday August 08, 2017 @04:46AM
(#14955816)
Yeah, I keep forgetting about Hardware acceleration…
[0] https://en.wikipedia.org/wiki/Length_extension_attack