The BLAKE3 cryptographic hash function

Re:The BLAKE3 cryptographic hash function by Dylan16807 on Friday January 10, 2020 @01:33AM (#22008802)

They're probably right to be upset by that change. Collisions require a lot more resources than simply trying every input on a GPU/ASIC, and as https://news.ycombinator.com/item?id=22007810 points out, an attacker that can only cover some fraction of the key space is massively more disadvantaged when they're performing a collision attack. You need more raw bits of preimage resistance to make the attacks equally hard.

I don't know if you need twice as many bits of preimage resistance, but I'd feel a lot more comfortable with an extra 32.

[ Parent | on HN ]

Re:The BLAKE3 cryptographic hash function by Thorrez on Friday January 10, 2020 @01:45AM (#22008860)

> Collisions require a lot more resources than simply trying every input on a GPU/ASIC

Would a 128 bit difficulty preimage attack against SHAKE128(256) be as simple as trying every single input? Trying every single input would be a 256 bit difficulty attack I would assume. To get it to a 128 bit attack I would think the attack would need something more advanced.

[ Parent | on HN ]

Re:The BLAKE3 cryptographic hash function by Dylan16807 on Friday January 10, 2020 @02:42AM (#22009151)

Yeah, I should have stuck with my initial wording about having major space requirements and not just time requirements.

You do need a more complex calculation to try to mount a preimage attack. But from what I can figure out it still tends to use big blocks of standalone arithmetic, something that's still very easy to accelerate with limited I/O.

[ Parent | on HN ]