# Tag Info

18

Let hash be the raw hash function, as you're referring to. You mentioned that the attacker knows hash(message || length), but to be more precise, they know hash(message || padding || length). Let full_hash be the proper hash with padding and length, i.e. full_hash(message) = hash(message || padding || length). You're correct that if the attacker knows hash(...

13

Contrary to your assumption, this is done, and it is secure: For instance, the hash functions SHA-224 and SHA-384 are basically the same algorithms as SHA-256 and SHA-512! The only differences are in the initial values for the Merkle-Damgård construction used internally and, of course, in that only the first $224$ or $384$ bits of the resulting hash are ...

9

To attack a MAC in general, the attacker needs to find a valid MAC of a message that they do not have the MAC for (or find a message collision that allows a different message to have the same MAC digest). In this case, the attacker would be appending data to the original message, not the MAC itself, and trying to obtain a valid MAC for the new message. In ...

9

Bob compares the SHA256 checksum that he generated from fake ISO file to the checksum found on official linux distribution's home page. Because Bob's fake ISO checksum matches the official ISO checksum, Bob doesn't notice that he has downloaded fake ISO I highlighted the incorrect assumption: the checksums wouldn't match. What the length extension attack ...

7

If $H(x) = x$, $x$ is a fixed point. If for a value the output of the function is the same as the input, it is called a fixed point. A length extension attack is unrelated to the concept of fixed points. There is a good question about understanding length extension attacks here.

7

No, the length extension attack/property is not considered a collision. It does not allow to build a collision. The length extension property is that given the hash of a bitstring $M$ of given length $l$ (but arbitrary and unknown content), it is possible to compute the hash of $M\mathbin\|F(l)\mathbin\|E$ with $F(l)$ a short bitstring deduced from the ...

6

Yes. In this paper, Coron and al. showed that a plain MD construction is secure when it's inputs are prefix-free. They actually proved the indifferentiability of the construction. In other words messages need to be encoded in a prefix-free manner. Quoting the paper: A prefix-free code over the alphabet $\{0, 1\}^κ$is an efficiently computable injective ...

6

The objective of the construction $H'(m)=H(H(0^b\mathbin\|m))$ is not to strengthen $H$ against collision attacks; as noted in the question, that does not work. The objective is preventing a length-extension attack. In such attack, an adversary knows the hash $h=H(m_0)$ of some unknown $m_0$, and the length $l$ of $m_0$. Then from $h$ and $l$ s/he ...

6

Could is also be possible to generate $H(\text{message}[1..n-1])$ from $H(\text{message}[1..n])$ if I know the last byte? No, the length extension attacks are not working exactly like that. Let see how MD5 operates; MD5 divides a message into 512-bit blocks to operate1 in Merkle–Damgård fashion way. Every message is padded. The messages are padded with 1 ...

5

A length extension attack doesn't let you find a collision. It lets you predict the hash for an input with an unknown component in the prefix. If you have $h = H(x)$ for unknown (or partially unknown) $x$, you can generate $h_y = H(x \vert\vert y)$ for arbitrary $y$ (this is not strictly correct; I've ignored padding, but for the purposes of this discussion ...

5

Yes, if the length is formatted in a constant-size value (e.g. 64-bit field) or in an otherwise uniquely decodable manner. With such a length field, no hash input can be the the prefix of another valid input. Thus there is no length-extension attack. (Assumptions include that you reveal no intermediate values, of course.)

5

This is not possible in general, or for the specific case of SHA1 and SHA512. Length extension works because MD-hashes iterate the same function, so knowing the output you also know the intermediate state for some related longer inputs. Now there are some cases with "different" hashes where it could be possible. That its when the hashes are related. Like ...

5

Let's split your question into two parts: first the length extension attack problem with Whirlpool, and next your HMAC tool idea. 1. Is whirlpool vulnerable to length extension attack? Yes, Whirlpool by itself (as a plain hash, not HMAC) is indeed vulnerable to length extension attacks. Besides Crypto.SE Q&As like “Understanding the length extension ...

5

BLAKE2 is not open-source. BLAKE2 is a specification. The state is shuffled one last time after having set the final bit, ensuring that a small change, even a single bit, yields a completely different output, that cannot be reverted. A length extension attack means that knowing M and Hk(M), you may be able to compute Hk(M||E) without knowing the key k. ...

4

All from the BLAKE2 paper BLAKE2: simpler, smaller, fast as MD5 First of all BLAKE2b is optimized for 64-bit platforms — including NEON-enabled ARMs — and produces digests of any size between 1 and 64 bytes. and from the abstract of the article BLAKE2 is often faster than MD5, yet provides security similar to that of SHA-3: up to 256-bit collision ...

4

$$mac=\operatorname{SHA1}(\operatorname{SHA1}(secret\mathbin\|message))$$ is mac double-hashing enough to prevent length extension attacks? Double hashing is defined by Ferguson and Schneier in their book Practical Cryptography in Chapter 6.3.1 to countermeasure again length extension attacks (and SHA256D used in Bitcoin). The details in their book, I don'...

3

Fixed output filters like SHA-256d Keyed output filters like HMAC, envelope-MAC, etc. Truncation like SHA-512/256 Prefix-free message encoding like length-prefixed Non-MD designs like BLAKE2 with HAIFA, SHA-3 with a sponge

3

But is it necessary to use these bytes? Yes, it is, at least for most messages that you'll see in practice. MD5 works by taking the message, and applying a fixed padding to it. This fixed padding involves, for messages which are a number of bytes (as opposed to, say, a message of 119 bits) an 0x80 byte, and for not huge messages, 0x00 bytes (in the length ...

3

Actually, GOST R 34.11-2012 hash function doesn't work from the end. It defines M as a binary vector to be hashed. The binary number is usually printed with the least significant bit printed last. When they say M = M'||m, it means that m is a binary sub-vector containing 512 least significant bits of M. And since GOST standard uses big endian everywhere, it ...

3

I understand, that this approach is more secure and eliminate length extension attack Actually, just be processing the blocks backwards doesn't actually eliminate any attacks. Instead of 'length extension' attacks, we have 'prepend attacks' (where we add the extra blocks to the beginning rather than the end), which yield the same vulnerability. Now, this '...

3

With a little more information, an attacker can indeed get up to some funny business by abusing this "internal state-revealing" property of Merkle-Damgard style hash functions (this includes MD5 and SHA-1 and SHA-2 but not SHA-3). With hash(message1) and len(message1) but not message1 itself, there is one specific message2 such that an attacker can forge a ...

3

OK, lets go through this step by step: the message size of http://example.com/downloadfile=report.pdf is 10 bytes, as only the filename (report.pdf) is hashed according to the article; the key size is usually known and was explicitly set in the article to 11 bytes, not 15 (11 bytes is a bit short for a key size, by the way); so the length of the message is ...

3

I don't understand why you are talking about a 1-1 property; a pseudorandom function is not 1-1. As such, you can always just truncate in order to reduce the output size, and you can just truncate by taking the first $t$ bits that you want (you don't need to apply any other function). In order to extend, if $\ell$ is long enough to be the length of a seed in ...

3

No, there is no known way. It would actually be rather surprising if there were even a theoretical way; the SHA-256 and the SHA-512 compression functions are rather different (for one, one works with 32 bit words and the other works with 64 bit words); one wouldn't expect them to share any sort of relation.

3

You should think of the attack as being directed against the hash function as a whole. What you are calling $$\mathrm{hash}(\mbox{message} + \mbox{length})$$ is really $$\mathrm{Hash}(\mbox{message})$$ where I've used the capitalization to distinguish the two. $\mathrm{Hash}$, not $\mathrm{hash}$, is the actual "hash function", and this is what is ...

3

You forget one little step of how Merkle–Damgård construction works; the padding, here SHA-1 padding: append the bit $\texttt{1}$ to the message e.g. by adding $\texttt{0x80}$ if message length is a multiple of 8 bits. append $0 \leq k < 512$ bits $\texttt{0}$, such that the resulting message length in bits is congruent to $$−64 \equiv 448 \pmod{... 3 No, currently not even MD5 is broken enough for this. MD5 and SHA-1/2 all use a simple Merkle-Damgard construction. In an MD construction basically what you get is (for a message split into two message blocks):$$H(M) = H'(H'(C, B'_1), B'_2) where $C$ is a known constant and $B_i$ consists of the message blocks, with a padded last block. Now if $H'$ was ...

3

This is a complementary answer to the Model Nest's answer, and will concentrate on how to achieve the constant size for messages. We assume that the files have confidentiality, integrity, and authentication while sending/ receiving. First of all, in the security proofs like the CPA game, we assume the messages have the same length, otherwise, the advantage ...

2

No, scrypt in not vulnerable to password extension attacks. Internally, scrypt passes the password to PBKDF2, which uses it as a key for the HMAC function -- hence they've effectively already done the workaround you thought of.

2

How can he do that? He could take api_signature = h = md5(m) and use it as the Initialization Vector of the hash function and hash the extra data and another padding. This is the idea behind the hash length_extension attack, isn't it? Correct. My question: The api_signature will change then because it is calculated like: md5(extra || padding) with the ...

Only top voted, non community-wiki answers of a minimum length are eligible