127
The simple answer is that hashes don't ensure uniqueness. Very broadly, hashes behave like "deterministic random numbers" – deterministic in the sense that hashing the same data always gives the same answer; random in the sense that the value of the hash is basically unpredictable without actually computing it. And sufficiently unpredictable that, ...
81
The risk of collision is only theoretical; it will not happen in practice. Time spent worrying about such a risk of collision is time wasted. Consider that even if you have $2^{90}$ 1MB blocks (that's a billion of billions of billions of blocks -- stored on 1TB hard disks, the disks would make a pile as large of the USA and several kilometers high), risks of ...
67
This specific situation is a central part of the analysis of password hashing functions. Indeed, for hashing a password, we want a function which is:
slow in a tunable way;
such that the most cost-effective hardware for evaluating many instances of the function is the hardware that the expected defender will use, i.e. a "normal PC".
"Cost" here means ...
60
This isn't necessarily unexpected. 32-bit platforms vs 64-bit platforms can make a significant difference, as well as the amount of data you're hashing.
$ uname -m
x86_64
$ openssl speed sha256 sha512
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha256 ...
56
SHA-256(SHA-256(x)) was proposed by Ferguson and Schneier in their excellent book "Practical Cryptography" (later updated by Ferguson, Schneier, and Kohno and renamed "Cryptography Engineering") as a way to make SHA-256 invulnerable to "length-extension" attack. They called it "SHA-256d". We started using SHA-256d for everything when we launched the Tahoe-...
52
A collision in any hash function gives a collision in a "squared" variant of the hash function. This is easy to see. If hash(x)==hash(y), then hashing the outputs will also be the same.
So the wiki entry is wrong. To see the real purpose of the double hash see this question and answers.
50
how can for example SHA-256 be unique if there is only a limited number of them?!
Where your issue occurs is that they're not unique. It's just very improbable that they'll reoccur. Unique in this context is not a mathematical definition, it's a humanist one.
In terms of human numbers, $ 2^{256} $ = ...
45
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 ...
40
SHA-512 has 25% more rounds than SHA-256. On a 64-bit processor each round takes the same amount of operations, yet can process double the data per round, because the instructions process 64-bit words instead of 32-bit words. Therefore, 2 / 1.25 = 1.6, which is how much faster SHA-512 can be under optimal conditions.
Of course there is memory overhead, ...
32
Would you use HMAC-SHA1 or HMAC-SHA256 for message authentication?
Yes.
That is a semi-serious answer; both are very good choices, assuming, of course, that a Message Authentication Code is the appropriate solution (that is, both sides share a secret key), and you don't need extreme speed.
How much HMAC-SHA256 is slower than HMAC-SHA1?
Those sorts of ...
30
SHA-256 is based on a Davies–Meyer compression function. Easy to find fixed-points are a known property of this construction.
A notable property of the Davies–Meyer construction is that even if the underlying block cipher is totally secure, it is possible to compute fixed points for the construction : for any $m$, one can find a value of $h$ such that $...
29
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 ...
29
Yes, if you hash the same input with the same function, you will always get the same result.
This follows from the fact that it is a hash-function. By definition a function is a relation between a set of inputs and a set of permissible outputs with the property that each input is related to exactly one output.
In practice there is no seed involved in ...
29
Firstly, some definitions;
Pre-image resistant: given a hash value $h$ find a message $m$ such that $h=Hash(m)$. Consider storing the hashes of passwords on the server. Eg. an attacker will try to find a valid password to your account.
Second Pre-image resistant: given a message $m_1$ is should be computationally infeasible to find another message $m_2$ ...
28
You are right, hashes won't be all unique as you already have shown. The important part are practical collisions - how many SHA-512 hashes can the whole earth generate in its lifetime? Definitely much less than $2^{512}$, it's even less than $2^{128}$.
Let's guess unrealistically high and say we generate these $2^{128}$ hashes from perfectly random input, ...
26
The result of SHA-256 of an empty string is:
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Accordingly to this and this
26
A common rationale for hashing twice is to guard against the length-extension property of the hash (if it has that property, as many hashes before SHA-3 did). For SHA-256, this property allows to compute $\operatorname{SHA-256}(X\|Y\|Z)$ knowing $\operatorname{SHA-256}(X)$ and the length of $X$, for some short $Y$ function only of the length of $X$, and some ...
23
$\text{SHA256}$ is designed to behave as a random function. Under that assumption, it is expected that for most 256-bit $v$, there is no positive integer $n$ with $\text{SHA256}^n(v)$ equal to $v$. Otherwise said, most $v$ do not belong to a cycle.
To illustrate this visually, in the following picture showing iteration of a 7-bit hash, I drew the points ...
23
How many hex digits do I need to compare when manually checking hash
functions?
If you actually want the full security guarantees of the hash function to apply: all of them.
I usually just look at the first/last 5 or 6 hex digits and call it
good enough.
This effectively reduces the security of the hash function to that of one that only outputs 10-...
22
Does this bias the hash in any way?
We want the avalanche criteria on the output bits, that is a change in the any of input bit must randomly affect half of the output bits. Each bit of the hash function must depend on the input bits; removing one bit doesn't affect the others.
My assumption is this would decrease the computational power needed to ...
19
I would use HMAC-SHA256.
While poncho's answer that both are secure is reasonable, there are several reasons I would prefer to use SHA-256 as the hash:
Attacks only get better. SHA-1 collision resistance is already broken, so it's not impossible that other attacks will also be possible in the future.
It allows you to depend on just one hash function, which ...
19
Short answer: 32 bytes of full-entropy key is enough.
Assuming full-entropy key (that is, each bit of key is chosen independently of the others by an equivalent of fair coin toss), the security of HMAC-SHA-256 against brute force key search is defined by the key size up to 64 bytes (512 bits) of key, then abruptly drops to 32 bytes (256 bits) for larger ...
18
The Bitcoin mining algorithm can not be simplified by exploiting any weakness in the SHA-2 hashing algorithm with the current state of the art.
The problem is manyfold. From the SHA-256 point of view, there is no (partial) preimage search algorithm that applies to the full hash function. Even worse, the attacks that penetrate a fewer number of rounds have ...
18
It's worth pointing out that in the case of SHA2 and most other hashes the compression function has a block cipher (keyed permutation) as its core.
Basically what you are asking is identical to asking how can block ciphers be resistant to known-plaintext attacks and chosen-plaintext attacks (arguably doesn't apply to SHA2 specifically because an attacker ...
16
This started as a comment to CodeinChaos's answer, but did not fit. I'm trying to regurgitate, in layman's terms, my understanding of the consequences on $\operatorname{SHA-256d}$ of the paper he quotes: Yevgeniy Dodis, Thomas Ristenpart, John Steinberger, Stefano Tessaro: To Hash or Not to Hash Again? (In) differentiability Results for H2 and HMAC, in ...
16
Introduction
BCrypt is a password-based KDF (far from state-of-the-art, but better than PBKDF2, because BCrypt requires sizable RAM, which greatly increases the cost of hardware-accelerated password search).
Bcrypt is based on the block cipher Blowfish, with the initial processing of the password reminiscent of Blowfish's key preprocessing. Bruce Schneier'...
14
If you want to use Skein (one of the SHA-3 candidates) anyway: it has a "mode of operation" (configuration variant) for tree hashing, which works just like your method 2.
It does this internally of the operation, as multiple calls of UBI on the individual blocks. This is described in section 3.5.6 of the Skein specification paper (version 1.3).
You will ...
14
Actually a tree-based hashing as you describe it (your method 2) somewhat lowers resistance to second preimages.
For a hash function with a $n$-bit output, we expect resistance to:
collisions up to $2^{n/2}$ effort,
second preimages up to $2^{n/2}$,
preimages up to $2^n$.
"Effort" is here measured in number of invocations of the hash function on a short, "...
14
The definitions given in FIPS 180-4 are
$$\begin{align}
\operatorname{Maj}(x,y,z)&=(x\wedge y)\oplus(x\wedge z)\oplus(y\wedge z)\\
\operatorname{Ch}(x,y,z)&=(x\wedge y)\oplus(\neg x\wedge z)
\end{align}$$
where $\wedge$ is bitwise AND, $\oplus$ is bitwise exclusive-OR, and $\neg $ is bitwise negation. The functions are defined for bit vectors (of 32 ...
Only top voted, non community-wiki answers of a minimum length are eligible
