4 ms·

Or design your protocols to be safe from length extension attacks in the first place.

by kobeya 10y ago

baby 10y ago
Some people don't understand crypto. That's where SHA-3 could save them.
- gpvos 10y ago
  FTFY: s/Some/Most/
jeffdavis 10y ago
Can you please explain?
- kobeya 10y ago
  E.g. Use an HMAC construction.
- aseipp 10y ago
  EDIT: I realized you were asking about "design your protocols against length extension", not "what is length extension". Sorry. Ignore this, but I'll leave the response for anyone else who is curious --- SHA-{1,2} are vulnerable to length extension attacks, because of the way their Merkle-Damgard construction works. Basically, if you have the result HASH(X), you can calculate HASH(X+P), knowing only 'HASH(X)', without knowing 'X' itself. This is problematic because it means you can effectively "extend" some cryptographically hashed data with an arbitrary suffix. You can immunize SHA-2 in one of two ways to a length extension attack: - Truncate the hash value. For example, use SHA-512, but truncate the result to 256 bits (this is called "SHA-512/256"). This works because the output of your HASH function which is 256-bits, cannot be reused as the initial starting state for a new round of HASH (e.g. SHA-512 needs a 512-bit starting value, but the output is only 256, so this makes it impossible) - Although it is not standard SHA-2 anymore, you can use a trick from Neils Ferguson and John Kelsey (from 2001!) to immunize it -- simply XOR a constant into the final block round before running the final compression function. Unfortunately this suggestion was not adopted for SHA-2: http://www.cs.utsa.edu/~wagner/CS4363/SHS/dfips-180-2-comments1.pdf http://www.cs.utsa.edu/~wagner/CS4363/SHS/dfips-180-2-commen... Alternatively just use a modern hash design like BLAKE2, SHA-3, or a number of others -- these avoid the entire problem. I'd suggest just sticking to one of those two.
  - tptacek 10y ago
    I object to the notion that SHA-3 and Blake2 are "modern" hash functions and that SHA-2 isn't. SHA-2 remains a first-line hashing recommendation among crypto designers. The Noise protocol framework, for instance, includes it, as does Nacl; the authors of both of these systems had hashes available that didn't have length extension. If I had to rank those three hash functions, SHA-2 wouldn't be in last place.

Or design your protocols to be safe from length extension attacks in the first place.

by kobeya 10y ago

Or design your protocols to be safe from length extension attacks in the first place.

baby 10y ago

Some people don't understand crypto. That's where SHA-3 could save them.

gpvos 10y ago
FTFY: s/Some/Most/

jeffdavis 10y ago

Can you please explain?

kobeya 10y ago
E.g. Use an HMAC construction.
aseipp 10y ago
EDIT: I realized you were asking about "design your protocols against length extension", not "what is length extension". Sorry. Ignore this, but I'll leave the response for anyone else who is curious --- SHA-{1,2} are vulnerable to length extension attacks, because of the way their Merkle-Damgard construction works. Basically, if you have the result HASH(X), you can calculate HASH(X+P), knowing only 'HASH(X)', without knowing 'X' itself. This is problematic because it means you can effectively "extend" some cryptographically hashed data with an arbitrary suffix. You can immunize SHA-2 in one of two ways to a length extension attack: - Truncate the hash value. For example, use SHA-512, but truncate the result to 256 bits (this is called "SHA-512/256"). This works because the output of your HASH function which is 256-bits, cannot be reused as the initial starting state for a new round of HASH (e.g. SHA-512 needs a 512-bit starting value, but the output is only 256, so this makes it impossible) - Although it is not standard SHA-2 anymore, you can use a trick from Neils Ferguson and John Kelsey (from 2001!) to immunize it -- simply XOR a constant into the final block round before running the final compression function. Unfortunately this suggestion was not adopted for SHA-2: http://www.cs.utsa.edu/~wagner/CS4363/SHS/dfips-180-2-comments1.pdf http://www.cs.utsa.edu/~wagner/CS4363/SHS/dfips-180-2-commen... Alternatively just use a modern hash design like BLAKE2, SHA-3, or a number of others -- these avoid the entire problem. I'd suggest just sticking to one of those two.
- tptacek 10y ago
  I object to the notion that SHA-3 and Blake2 are "modern" hash functions and that SHA-2 isn't. SHA-2 remains a first-line hashing recommendation among crypto designers. The Noise protocol framework, for instance, includes it, as does Nacl; the authors of both of these systems had hashes available that didn't have length extension. If I had to rank those three hash functions, SHA-2 wouldn't be in last place.