Hot answers tagged hash
38
For password-hashing, you should not use a normal cryptographic hash, but something made specially to protect passwords, like bcrypt.
See How to safely store a password for details (this article advocates the use of bcrypt).
The important point is that password crackers don't have to bruteforce the hash output space ($2^{160}$ for SHA-1), but only the ...
27
You are correct that it is a "bad hash". In fact it is not a hash at all. I've worked at a company that used a slightly different scheme for obfuscating database keys/numbers in URLs. And I also worked for another company that used a scheme that looked surprisingly similar for unlock codes for electronic devices.
The formula for converting "hashes" back ...
25
Combining is what SSL/TLS does with MD5 and SHA-1, in its definition of its internal "PRF" (which is actually a Key Derivation Function). For a given hash function, TLS defines a KDF which relies on HMAC which relies on the hash function. Then the KDF is invoked twice, once with MD5 and once with SHA-1, and the results are XORed together. The idea was to ...
16
You were right with your ideas in the the original question. If what you want to protect against is pre-images then chaining hash functions produces a function at least as strong as the strongest of its two components:
H∘(x) = H₀(H₁(x))
If what you want to protect against is collisions, then concatenation is at least as strong as the strongest of its two ...
16
It would be very freakish if it turned out to be true. It is not an expected property of SHA-512 to have such bijectivity. It would be worrisome, even, because that's a kind of structure that should not appear in a proper cryptographic hash function.
Actually proving that SHA-512, for 512-bit blocks, is not bijective, would already be a kind of a problem. ...
15
If I get the suggested construction correctly, it is to
1) hash n values (with SHA-256);
2) add theses hashes, perhaps mod 2256;
3) hash the sum (with RIPEMD-160).
This would be potentially unsafe: creating a collision or even second pre-image at step 2) reduces to a knapsack problem, and this has a poor safety record; it might be workable when the ...
14
If taking the first or last bits of a SHA-256 output made any difference, it would be viewed as a serious blow against the security of SHA-256. Right now, no such weakness is known in SHA-256. So, as far as we know, you can use whatever bits you want.
If you need a more "administrative" answer, have a look at SHA-224 (also specified in FIPS 180-3). This is ...
14
The emerging consensus seems to be that the "crypto.se" site is best suited for more theoretical questions, while more practical questions like this which really turn on the question of risk management are more suited for the broader audience at http://security.stackexchange.com/
I recommend looking at the many password-hashing-related questions there, e.g. ...
14
The XOR is indeed meant as a protection against hypothetical short cycles. For a given password P, the sequence of Ui should make a "rho" structure: at some point in the sequence, a cycle is entered. For a n-bit hash function and random password, on average, there will be a single "big" cycle of size about 2n/2 and for almost all possible salt values, that ...
14
There exists something which is one step further than your idea. Look up SRP: this is a Password-Authenticated Key Exchange protocol; the two parties (client and server) who run the protocol end up with a newly generated shared key (which can be used to derive encryption and integrity-check keys), with mutual authentication with regards to a shared ...
14
We call a primitive broken, if there is any attack faster than bruteforce/what we expect of an ideal primitive. Broken does not mean that there are practical attacks.
There are no known collisions in SHA-1. Still we call collision resistance of SHA-1 is broken, because there is a theoretical attack that can find collisions using fewer than $2^{80}$ calls to ...
12
If your system already has some other unique user identifier (be it an ID, user-name, or an EmailAddress) is there any effective decrease in your security if you simply use that value as your salt?
The salt in a hash actually forms two different purposes. Generally, it is acceptable for a salt to be known, so let us consider H() a hash function, S, some ...
12
SHA-1 processes data by 512-bit blocks (64 bytes). For a given input message m, it first appends some bits (at least 65, at most 576) so that the total length is a multiple of 512. Let's call p the added bits (that's the padding). The padding bits depend only on the length of m (these bits include an encoding of that length, but they do not depend on the ...
12
What you want is called a chosen prefix collision. Given p1, p2 you want to find m1, m2 such that hash(p1 || m1) = hash(p2 || m2).
Generic attack
The generic attack to find this, is creating messages starting with p1 and just as many starting with p2. Thanks to the birthday problem you'll find a match after around 2n/2 messages.
For a 128 bit hash like ...
12
No. The wikipedia article is in my honest opinion misrepresenting this article on a reduced round attack on the SHA-2 family of hashes.
Although these attacks improve upon the existing reduced round SHA-2 attacks, they do not threaten the security of the full SHA-2 family.
In other words, no collisions have been found in any of the SHA-2 hashes.
The ...
11
There is a reasonably good explanation in Wikipedia. The idea is the following: SHA-1 is built around an internal "compression function" which takes as input the 160-bit state and a 512-bit message block, and returns a new state. The padding is designed so that it can be proven that a collision over the hash function necessarily implies at some point a ...
11
Usually, when the user registers, you will generate a random value to become the salt. Then, in the user database, you store the user's name, salt, and hash generated using the password and salt (and whatever else is relevant for a user table).
Note that doing it this way allows each user to have a unique salt. Each user having a unique salt greatly ...
11
The word "secure hash function" usually means (for a function $H$)
Preimage resistance: Given a value $h$, it is hard to find a message $x$ so that $h = H(x)$.
Second preimage resistance: Given a message $x$, it is hard to find a message $x' \neq x$ such that $H(x) = H(x')$.
Collision resistance: It is hard to find two messages $x$, $x'$ such that $H(x) = ...
11
To the best of my knowledge there is no formal distinction, since "password hashes" aren't formally defined.
That said, if you look at this presentation from the author of scrypt you'll see that he wanted:
Password hashing to be CPU hard (i.e. to require significant amounts of CPU processing, in a manner that cannot be optimized away).
Password hashing to ...
11
By using the file's hash as IV, you also divulge the file's hash. This allows an attacker to make an exhaustive search on the file contents. It is not difficult to imagine situations where there are only a few millions or billions of possible file contents (e.g. the file contents are an encrypted SAN or password), in which case showing the data hash is an ...
10
I was already wondering why you would need 2048 bits, because brute forcing a 512 bit output hash takes already a $2^{256}$ operations on average (w.r.t to collision resistance, due to the Birthday Paradox – preimage and second-preimage attacks take on average $2^{511}$ hashes), which is secure enough, for all kinds of hardware available today.
I assumed ...
10
Finding a decent explanation of rainbow tables was something I struggled with, so firstly I'll cover what they are. I will get to your question in the end. My sources for this are this guide and the wikipedia article.
Why can't I just use a big bucket of hashes?
Firstly the naive way to build a reverse lookup table is this. Let's say we want to generate ...
10
What you suggest is valid. Here is a way to show it:
In a fully implemented signature system (things are similar for asymmetric encryption), there are three modules:
a key pair generator, which produces a pseudo-random key pair;
a signature generator, which uses the private key to produce a signature over some piece of data;
a signature verifier, which ...
10
There is no proof that every output of common hash functions is reachable for some input, but it is expected to be true. No method better than brute force is known to check this, and brute force is entirely impractical.
By the coupon's collector argument, it is expected to require $2^n\cdot(n\cdot\ln(2)+\gamma)+1/2+o(1)$ random values to reach all $n$-bit ...
10
That depends on what you want to use the hash function for.
For signing documents, sha2 (e. g. sha512) is considered secure.
For storing passwords, you should use one of the algorithms dedicated for this purpose: e. g. bcrypt, sha512crypt or scrypt. In order to slow down an attacker, these algorithms apply the hash functions many times with an input that ...
10
I would recommend phasing out SHA-1 in any scenario where collision-resistance of a hash is required, for there is a wide consensus that an attack with $2^{69}$ complexity would work, it would already be feasible by a resourceful entity, and attacks only get better.
I'm still confident that SHA-1 is preimage and second-preimage resistant for all practical ...
9
The general justification is several years of cryptographic research in trying to "break" hash functions. As far as I know there is no "proof" that finding pre-images of a hash are hard. It is just assumed to be hard based on the history of effort trying to invert it.
A hash function considered secure today may well turn out to be weak tomorrow.
This ...
9
This approach, at a high level, is actually fairly common; many stream ciphers operate on this very principle. For instance, Salsa20 uses what is effectively a hash function (a PRF) to convert a secret input (that includes a counter) into the keystream which is XORed with the plaintext. However, this kind of function can be much faster than a secure ...
9
Yes, SHA-256 is currently the de facto standard. The "why" is that MD5 and SHA-1 are unsafe and the only algorithm left which has been extensively studied and deployed and which nobody has found a significant attack against is SHA-256. (There is also SHA-512, but people seem to regard it as being overkill.)
There is widespread uncertainty about whether ...
9
Well, as far as we know, the mode you suggest should be secure. Now, to be honest, AES256 versus your mode isn't quite a fair comparison; your mode gives somewhat less theoretical security; if you encrypt a known $2^n$ block message, the key can be recovered with $2^{256-n}$ effort; however, this observation doesn't really affect the practical security.
...
Only top voted, non community-wiki answers of a minimum length are eligible
