3 ms·

> What do you mean, "flawed"? Merkle-Damgard-flavored hashes are extendable by design. Flawed as in "cryptographically insecure". Which in this case is "it let

> 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.
  - tptacek 3y ago
    Just a note that if jargon upsets you to the point where you self-consciously and deliberately avoid it, cryptography might not be the specialty for you. We're talking here about one of the very simplest tasks in cryptography, of simply encrypting a discrete message. To steal a rhetorical device from Watson Ladd, after a long discussion that started with a gravely broken system, we arrived at something that might work, and that would almost certainly get you a D in a first undergraduate course. The experience you'll have trying to design anything more complicated is that, even with a lot of effort and careful thought _and experience_, will be that the first cut of any system you come up with will have vulnerabilities. Of course they will. Look at the track record of (checks) everybody else that has ever tried to ship cryptography. But the problems you're going to run into aren't going to be described intuitively, in "plain language". Just like being a medical doctor, you need to be conversant with the terminology of the field to understand what the pitfalls are. Very serious vulnerabilities in schemes you come up with are going to be described in the literature in terms of acronyms related to proofs that are themselves stitched together with jargon and acronyms. Cryptography is hard! I solve this problem for myself by simply refusing to design cryptosystems for other people. It's much easier being a vulnerability researcher that dabbles in cryptography than it is to be a practicing cryptography engineer.
    - dataflow 3y ago
      I'm indeed neither a cryptographer nor planning to become one, don't worry ;)
      - tptacek 3y ago
        Let me again put a word in for being a cryptographic vulnerability researcher, which will enable you to thumb your nose at academic cryptography jargon all you want!

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.
- tptacek 3y ago
  Just a note that if jargon upsets you to the point where you self-consciously and deliberately avoid it, cryptography might not be the specialty for you. We're talking here about one of the very simplest tasks in cryptography, of simply encrypting a discrete message. To steal a rhetorical device from Watson Ladd, after a long discussion that started with a gravely broken system, we arrived at something that might work, and that would almost certainly get you a D in a first undergraduate course. The experience you'll have trying to design anything more complicated is that, even with a lot of effort and careful thought _and experience_, will be that the first cut of any system you come up with will have vulnerabilities. Of course they will. Look at the track record of (checks) everybody else that has ever tried to ship cryptography. But the problems you're going to run into aren't going to be described intuitively, in "plain language". Just like being a medical doctor, you need to be conversant with the terminology of the field to understand what the pitfalls are. Very serious vulnerabilities in schemes you come up with are going to be described in the literature in terms of acronyms related to proofs that are themselves stitched together with jargon and acronyms. Cryptography is hard! I solve this problem for myself by simply refusing to design cryptosystems for other people. It's much easier being a vulnerability researcher that dabbles in cryptography than it is to be a practicing cryptography engineer.
  - dataflow 3y ago
    I'm indeed neither a cryptographer nor planning to become one, don't worry ;)
    - tptacek 3y ago
      Let me again put a word in for being a cryptographic vulnerability researcher, which will enable you to thumb your nose at academic cryptography jargon all you want!