# Tag Info

11

Expanding then shrinking in SHA-1 refers to the process, performed for each round (each 512-bit block of padded message), of message expansion from 512 bits to 2560 bits; keeping only 160 bits of state for the next round. The later directly follows from the construction of SHA-1 as a Merkle-Damgård hash of 160 bit. The former occurs because SHA-1's ...

7

The entropy for the output of SHA-256 truncated to its first $128$ bits when fed a random $128$-bit input is about $127.173$ bit, down from very close to $128$ bit before truncation (see final note). The truncation does not halve the entropy, because the halves are not independent. The right line of thought is that SHA-256 truncated to its first $128$ bits ...

5

Here are some hints on how it's done on Mega: The password provided is passed through a KDF to derive a key, that is used to en-/decrypt the master key (later provided by the server through an API call). To bring it down to the crucial bits: The KDF applies $2^{16}$ rounds of AES-128 with it. The details can be found in the function prepare_key() of the ...

4

Yes, these notations always seem to mean that H^n(x) (or $H^n(x)$ in mathematical notation) means that $x$ is the first input, and that the next outputs are a hash of the previous output: H^0(x) = x // just defined as x below H^1(x) = H(x) H^2(x) = H(H^1(x)) = H(H(x)) H^3(x) = H(H^2(x)) = ... = H(H(H(x))) H^4(x) = ............... = H(H(H(H(x)))) ...

3

Indeed hashing is used to ensure integrity, but not this way. What you have in mind it seems is sending (msg, Hash(msg)). Indeed this is not secure because of the attack you describe. The first step starts with something you say by yourself: hashing algorithms are universal algorithms The name is not univesal but public, it means anyone knows it. ...

3

Your math is wrong — not the numerical calculation, but your interpretation of it. There are $256^{17}$ possible inputs and $256^{16}$ possible outputs. On average, there are $256$ inputs for each output. But there are no guarantees that this is the case for all outputs: it's in fact overwhelmingly likely that some outputs have more and others have fewer. ...

3

I know SHAKE128 and 256 are part of the SHA-3 standard but is the SHA3 standard officially released yet? i can only find a draft of the publication, does this mean it's not official and therefor not proven to be secure? No, SHA-3 has not been formally approved. On the other hand, what do you mean "not proved to be secure"? Do you really thing that ...

2

I'll consider only a non-adversarial model for the requirement of a low collision probability; that is, we are considering naturally-occurring strings only (which implies they are of bounded size; I'll limit it to $2^{64}-1$ bits, over 2305 Petabyte). However I'll consider that we need to reliably detect strings that differ only in a small consecutive ...

2

If I understand your question correctly, you want to generate a short value $v(T)$ from a table $T$ such that if $T_1$ and $T_2$ have the same size and the same elements in each corresponding cell, then $v(T_1) = v(T_2)$, and if the tables have different sizes or different elements then $v(T_1) \ne v(T_2)$. What you need for that is two ingredients: A ...

1

Using simply a hash function is not strong enough, even if the key is not stored. We the users tend to choose very crappy passwords, such as "1234" or "password". If you only use a hash function for generating the key, then there are a lot of chances that the generated keys are SHA256("1234") or SHA256("password"). That is, this method is very vulnerable to ...

1

It all depends on whether the rest of the input is guessable. The best attack we know for finding the input to SHA1, given the output and partial knowledge about the input, is a brute-force attack: For each candidate at the full input, try hashing that input with SHA1 and see if it matches the known output. So, the running time of the attack will be ...

1

It seems to me that you don't need a cryptographic hash function, that is, a function that provides preimage resistance, collision resistance, etc. or at least to the degree that cryptographic applications require. Anyway, it seems that you could use a hash function that follows the Merkle-Damgard construction, but without doing the length padding at the ...

1

It depends. If you have full control over the whole system, all components and can use whatever algorithm you want to deploy, you can stick to the one giving you the best efficiency which fulfills your security requirements. In this case, it would be Tiger. However, Tiger has a 192 bit output. If that is not enough for you, go for SHA256. However, if the ...

1

Yes, there's an issue: you're adding needless complexity, which gives you absolutely no benefit. The whole point of a PBKDF is to be slow; passwords are low-entropy, and the only way to mitigate brute-force is to make it take time to compute hashes. It can't take too long to log in, so you have to balance "fast for a user" and "slow for an attacker." ...

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