collisions VS bao

That is still an attack on the second preimage or a collision resistance properties of the hash function. Most collisions do work this way, for example see [1].

[1] https://github.com/corkami/collisions

it's easy to do if you have a few hours to spare

remelem nem checksum ellenorzesre https://github.com/corkami/collisions !

Sure, here are two different screenshots of your comment made with this tool:

Hash collisions and exploitations – Instant MD5 collision\ (4 comments)

Thanks! I've added a note about this here: https://github.com/oconnor663/bao/issues/41#issuecomment-119.... Does that sound like an accurate summary to you?

I mostly agree with you, but there are a couple other bullet points I like to throw in the mix:

- Length extension attacks. I think all of the SHA-3 candidates did the right thing here, and we would never accept a new cryptographic hash function that didn't do the right thing here. But SHA-2 gets a pass for legacy reasons. That's understandable, but we know we need to replace it with something eventually.

- Kind of niche, but BLAKE3 supports incremental verification, i.e. checking the hash of a file while you stream it rather learning whether it was valid at the end of the stream. https://github.com/oconnor663/bao That's useful if you know the hash of a file but you don't necessarily trust the service that's storing it.

Sadly, for domain separation between the Cyclist calls, it needs to touch the capacity, right? So Ascon can’t be retrofitted without being modified. Too bad, it could have enabled bao-style shenanigans.