3 ms·

My recollection was that by definition an HMAC crucially performs 2 rounds of hashing layered over the message... something like h(key || h(key || msg))? Wherea

My recollection was that by definition an HMAC crucially performs 2 rounds of hashing layered over the message... something like h(key || h(key || msg))? Whereas in my mind I was imagining something with one layer over the message (like h(f(key) || msg)) could work; I didn't actually see the need to do two layers of hashing over the message in what constituted (or at least I understood to constitute) a proper HMAC. Not sure if I had a misunderstanding of either the concepts or the terminology here, but if I did, please do let me know.

akerl_ 3y ago
https://en.wikipedia.org/wiki/HMAC#Design_principles https://en.wikipedia.org/wiki/HMAC#Design_principles addresses the rationale for performing 2 rounds of hashing.
- dataflow 3y ago
  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.
        3y ago

akerl_ 3y ago

https://en.wikipedia.org/wiki/HMAC#Design_principles https://en.wikipedia.org/wiki/HMAC#Design_principles addresses the rationale for performing 2 rounds of hashing.

dataflow 3y ago
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.
      - 3y ago