# Tag Info

46

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 ...

32

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 ...

30

The reason that salts are used is that people tend to choose the same passwords, and not at all randomly. Many used passwords out there are short real words, to make it easy to remember, but this also enables for an attack. As you may know, passwords are generally not stored in cleartext, but rather hashed. If you are unsure of the purpose of a ...

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

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 ...

24

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 ...

24

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 ...

24

SHA-512 truncated to 256 bits is as safe as SHA-256 as far as we know. The NIST did basically that with SHA-512/256 introduced March 2012 in FIPS 180-4 (because it is faster than SHA-256 when implemented in software on many 64-bit CPUs). SHA-224 is just as safe as using 224 bits of SHA-256, because that's basically how SHA-224 is constructed. What bits are ...

22

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. ...

22

These types of cryptographic primitive can be distinguished by the security goals they fulfill (in the simple protocol of "appending to a message"): Integrity: Can the recipient be confident that the message has not been accidentally modified? Authentication: Can the recipient be confident that the message originates from the sender? Non-repudiation: If ...

19

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 ...

19

I sent an email to Ron Rivest and got an answer back. The digits of $\pi$ are used as a sort of random number generator that is used in the Durstenfeld shuffle (see also Knuth vol 3, sec 3.4.2). Below is some pseudocode adapted from the description and code he sent me. S = [0, 1, ..., 255] digits_Pi = [3, 1, 4, 1, 5, 9, ...] # the digits of pi def ...

18

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) = ... 18 As a general rule, you should avoid SHA1 for new applications and instead go with one of the hash functions from the SHA-2 family. As far as truncating a hash goes, that's fine. It's explicitly endorsed by the NIST, and there are hash functions in the SHA-2 family that are simple truncated variants of their full brethren: SHA-256/224, SHA-512/224, ... 17 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. ... 17 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 ... 15 Well, the exact reason for an IV varies a bit between different modes that use IV. At a high level, what the IV does is act as a randomizer, so that each encrypted message appears to be encrypted to a random pattern, even if those messages are similar. In general, IVs disguise when you encrypt the same message twice (and more generally, when two messages ... 15 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 ... 15 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 ... 15 Not only we can turn block ciphers into hash functions, but we do. The usual hash functions (MD5, SHA-1, SHA-256...) use the Merkle-Damgård construction which relies on a block cipher E. A running state r is initialized to a conventional value. Then the input data is split into a number of chunks, each chunk being used as key for the block cipher: r is ... 15 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 ... 15 I do worry, but not for the resistance of SHA-3; I worry for its acceptance. Technically, what NIST wants to do is sound. They do want to somehow "break" a traditional rule, which is that a hash function with an output of n bits ought to resist collisions with strength 2n/2, and preimages (first and second) with strength 2n. Instead, NIST wants harmonized ... 15 The most efficient related-key attacks on AES-256 and resulting weaknesses AES-256-based hash functions are summarized in my PhD thesis. Though collision and preimage attacks on hash functions are out of reach yet, the components of these functions still expose some properties that are not expected of good hash functions or random oracles. Getting to the ... 15 Length extension attack The reason why$H(k || m)$is insecure with most older hashes is that they use the Merkle–Damgård construction which suffers from length extensions. When length extensions are available it's possible to compute$H(k || m || m^\prime)$knowing only$H(k || m)$but not$k$. This violates the security requirements of a MAC. Like all ... 14 Wikipedia has a reasonably good explanation about the Merkle–Damgård construction. 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 ... 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 A cryptographic hash function$f : \{0,1\}^{*} \to \{0,1\}^n\$ has three properties: (1) preimage resistance, (2) second-preimage resistance, and (3) collision resistance. Even further, these properties form a hierarchy where each property implies the one before it, i.e., a collision-resistant function is also second-preimage resistant, and a second-preimage ...

13

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 ...

13

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 ...

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