[Dylan16807]

If you had no size based padding, you could fake a document having a few more zero bytes at the end. That's almost never dangerous, and it also requires very specific (mis)use to cause problems, just like a length extension. Unless you can name a killer use case, I stand by length extension problems being a significantly bigger deal and more "necessary" to stop.

> You're supposed to be able to remove the padding in cryptography

It's a hash. You can never access the post-padding version of the input in the first place.

[tialaramex]

> Unless you can name a killer use case, I stand by length extension problems being a significantly bigger deal and more "necessary" to stop.

"it works as a cryptographic hash" is certainly a "killer use case" for a cryptographic hash.

Your "Dylan16807 hash" without working padding does not work as a cryptographic hash, it's useless.

[Dylan16807]

It would work just fine. And if you call those messages equivalent then there is no cryptographic failing. You'll need better than that argument.

Nobody complains that RSA gives you the same result for 45 and 0045 after all.

Better, think of it like a hash algorithm that takes bits vs one that takes bytes. They both work fine and are secure. If your byte happens to be a really wide byte, that's not a fatal flaw.

[tialaramex]

> And if you call those messages equivalent then there is no cryptographic failing. You'll need better than that argument.

Defining failure as success is very, very stupid. Nobody needs to "do better" than calling your position out as wrong.

> Nobody complains that RSA gives you the same result for 45 and 0045 after all.

RSA doesn't give you "the same result for 45 and 0045" unless what you mean by "0045" is "Actually just 45 except for some reason I write that with extra zeroes as part of my bad faith argument".

Hash algorithms that don't work aren't "just fine" they're useless.

The reason algorithms like SHA-256 are defined for bits isn't arbitrary - bits are literally the unit of information, this is the obvious and natural way to define the function, so choosing to define a function over "really wide bytes" doesn't make any sense.

[Dylan16807]

> Nobody needs to "do better" than calling your position out as wrong.

It's not going to be convincing unless you can talk about a specific attack. And in particular, that attack should be more relevant to real-world use than a weakness like length extension.

Especially because you could look at this weakness as a sibling attack to length extension, one that's mildly easier to pull off but you can only append zeros. That seems safer overall to me. And it's not reasonable to completely excuse one flaw as needing "misuse" but not the other.

> The reason algorithms like SHA-256 are defined for bits isn't arbitrary - bits are literally the unit of information, this is the obvious and natural way to define the function, so choosing to define a function over "really wide bytes" doesn't make any sense.

A hash algorithm that takes an input in bytes is not a failure. If you think taking single bits is actually necessary, rather than just 'obvious and natural', then I really think you're not analyzing the security properly.