3 ms·

Right, I get that it's guarding against a bad hash. I was (obviously) assuming the hash and RNG aren't flawed. In which case an proper HMAC seems unnecessary in

Right, I get that it's guarding against a bad hash. I was (obviously) assuming the hash and RNG aren't flawed. In which case an proper HMAC seems unnecessary in this scheme. But thanks for clarifying.

akerl_ 3y ago
I think maybe the gap here is about what a "bad hash" is. The attack described in the design principles section is applicable to hashes like SHA1 and SHA2, which makes it a pretty big deal. You could just always use a truncated variant of SHA2, or use SHA3, and you'd be covered for this specific risk... but at some point it's way easier to just start with an existing AEAD scheme instead of trying to piece something together from parts.
- dataflow 3y ago
  The thing is, if I'm just referring to an unspecified hash in a cipher I'm proposing, it's coming with the implicit assumption that (a) the hash is sufficiently good to make the scheme work, and (b) such a hash is actually available. To me, in a discussion like this, "your scheme sucks because SHA2 would break it" is fundamentally the same as "your scheme sucks because CRC would break it": from a mathematical standpoint it's just nonsensical (you can always find a bad hash function to break a cipher), and from a practical standpoint, while I agree it's a "big deal" (e.g., if I were implementing such a cipher, I would surely put up guardrails to prevent people using such a hash), it's also the least interesting way to shoot down the cipher I'm trying to discuss.
tptacek 3y ago
What do you mean, "flawed"? Merkle-Damgard-flavored hashes are extendable by design. You could use a more recent hash, like SHA3 or Blake2, simply with a key; that's basically KMAC. The point is: you need a MAC, not a "hash". Most people in your situation would just use HMAC. You're not really optimizing anything by avoiding HMAC, but if you try to roll KMAC-SHA2, you've created a cryptographic vulnerability.
- dataflow 3y ago
  > What do you mean, "flawed"? Merkle-Damgard-flavored hashes are extendable by design. Flawed as in "cryptographically insecure". Which in this case is "it lets you predict something about the hash of one input from the hash of a different input". As I see it, a cryptographically secure (read: flawless) hash function is just another name for an RNG whose output is computationally impossible to predict without knowledge of its seed. Hash functions that are vulnerable to length extension don't satisfy that: their outputs on longer inputs can be predicted from their outputs on shorter inputs, without any knowledge of their keys. That's a pretty big flaw. To me they're similar to hashes that lack the avalanche effect. They're not cryptographically secure as far as I'm concerned. > you need a MAC, not a "hash" I hate jargon honestly. I just refer to these (cryptographically secure) hashes and move on with my day. To me a hash that's vulnerable to length extension isn't cryptographically secure. I kind of assume people understand I'm assuming sufficiently strong building blocks when proposing a way to compose them, otherwise it makes for an uninteresting discussion. > Most people in your situation would just use HMAC. You're not really optimizing anything by avoiding HMAC Totally agree, but I wasn't suggesting you can't or shouldn't. I just didn't see HMAC as a requirement, hence why I didn't specifically write HMAC.
  - akerl_ 3y ago
    It's weird to me to pick on "jargon" like "MAC", but then make up your own definition for what counts as a hash. A MAC is not a "cryptographically secure hash". Nor is SHA-2 somehow not a secure hash because it can't be directly used as a MAC.
    - dataflow 3y ago
      > It's weird to me to pick on "jargon" like "MAC", but then make up your own definition for what counts as a hash. This is probably because I completely forgot "cryptographically secure hash" is itself jargon with a wacky definition. To me it was an intuitive concept, but looking it up now, the technical definition isn't what I expected. In my mind I have both a formal definition of what a "cryptographically secure hash" is (the one I wrote above), and an informal definition: "a hash function that's safe to use anywhere a hash function is needed in cryptography". Regardless of what you think about the formal definition... I would've hoped everyone would agree about the informal one. It only seems reasonable to deduce that from its name. But I guess I'm too naive to think things mean what they say? So now that you point it out, I hate that definition too. Would be lovely if they changed it to mean what it says on the tin. I doubt that I'll even manage to remember to change my vernacular as a workaround for the wacky technical definition.

akerl_ 3y ago

I think maybe the gap here is about what a "bad hash" is. The attack described in the design principles section is applicable to hashes like SHA1 and SHA2, which makes it a pretty big deal. You could just always use a truncated variant of SHA2, or use SHA3, and you'd be covered for this specific risk... but at some point it's way easier to just start with an existing AEAD scheme instead of trying to piece something together from parts.

dataflow 3y ago
The thing is, if I'm just referring to an unspecified hash in a cipher I'm proposing, it's coming with the implicit assumption that (a) the hash is sufficiently good to make the scheme work, and (b) such a hash is actually available. To me, in a discussion like this, "your scheme sucks because SHA2 would break it" is fundamentally the same as "your scheme sucks because CRC would break it": from a mathematical standpoint it's just nonsensical (you can always find a bad hash function to break a cipher), and from a practical standpoint, while I agree it's a "big deal" (e.g., if I were implementing such a cipher, I would surely put up guardrails to prevent people using such a hash), it's also the least interesting way to shoot down the cipher I'm trying to discuss.

tptacek 3y ago

What do you mean, "flawed"? Merkle-Damgard-flavored hashes are extendable by design. You could use a more recent hash, like SHA3 or Blake2, simply with a key; that's basically KMAC. The point is: you need a MAC, not a "hash". Most people in your situation would just use HMAC. You're not really optimizing anything by avoiding HMAC, but if you try to roll KMAC-SHA2, you've created a cryptographic vulnerability.

dataflow 3y ago
> What do you mean, "flawed"? Merkle-Damgard-flavored hashes are extendable by design. Flawed as in "cryptographically insecure". Which in this case is "it lets you predict something about the hash of one input from the hash of a different input". As I see it, a cryptographically secure (read: flawless) hash function is just another name for an RNG whose output is computationally impossible to predict without knowledge of its seed. Hash functions that are vulnerable to length extension don't satisfy that: their outputs on longer inputs can be predicted from their outputs on shorter inputs, without any knowledge of their keys. That's a pretty big flaw. To me they're similar to hashes that lack the avalanche effect. They're not cryptographically secure as far as I'm concerned. > you need a MAC, not a "hash" I hate jargon honestly. I just refer to these (cryptographically secure) hashes and move on with my day. To me a hash that's vulnerable to length extension isn't cryptographically secure. I kind of assume people understand I'm assuming sufficiently strong building blocks when proposing a way to compose them, otherwise it makes for an uninteresting discussion. > Most people in your situation would just use HMAC. You're not really optimizing anything by avoiding HMAC Totally agree, but I wasn't suggesting you can't or shouldn't. I just didn't see HMAC as a requirement, hence why I didn't specifically write HMAC.
- akerl_ 3y ago
  It's weird to me to pick on "jargon" like "MAC", but then make up your own definition for what counts as a hash. A MAC is not a "cryptographically secure hash". Nor is SHA-2 somehow not a secure hash because it can't be directly used as a MAC.
  - dataflow 3y ago
    > It's weird to me to pick on "jargon" like "MAC", but then make up your own definition for what counts as a hash. This is probably because I completely forgot "cryptographically secure hash" is itself jargon with a wacky definition. To me it was an intuitive concept, but looking it up now, the technical definition isn't what I expected. In my mind I have both a formal definition of what a "cryptographically secure hash" is (the one I wrote above), and an informal definition: "a hash function that's safe to use anywhere a hash function is needed in cryptography". Regardless of what you think about the formal definition... I would've hoped everyone would agree about the informal one. It only seems reasonable to deduce that from its name. But I guess I'm too naive to think things mean what they say? So now that you point it out, I hate that definition too. Would be lovely if they changed it to mean what it says on the tin. I doubt that I'll even manage to remember to change my vernacular as a workaround for the wacky technical definition.