145
[Update, 2019-09-12: Upon being exposed, and/or after taking advantage of market manipulation by their fraudulent announcements, the scam artists of Treadwell Stanton DuPont have retracted their claim, with more meaningless waffling technobabble about ‘laboratory equipment flaws’ and ‘ambiguous results’—yet they are still selling the same snake oil! I leave ...
answered Sep 11 '19 at 15:23
Squeamish Ossifrage
44.1k3 gold badges92 silver badges188 bronze badges
131
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, ...
70
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 ...
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 ...
57
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} $ = ...
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.
45
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, ...
40
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 ...
37
The result of SHA-256 of an empty string is:
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Accordingly to this and this
35
This is firmly in "put up or shut up" territory.
It's easy to prove this claim. I will provide them with a string and its hash. They must provide a collision.
They could also mine bitcoin and earn a large bounty without actually doing harm to the block chain. They could mine faster with less energy than the competition. This wouldn't hurt anyone and would ...
33
No, it is not a good idea to hash phone numbers. There are only a limited number of phone numbers, so it is pretty easy for an adversary to try and hash all of them. Then you can simply compare the hash of each with the stored hash. Generally you don't have to deal with all telephone numbers, only a subsection of phone numbers anyway (for a specific country ...
32
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 ...
32
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$ ...
31
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 $E_m(...
31
The main differences between the older SHA-256 of the SHA-2 family of FIPS 180, and the newer SHA3-256 of the SHA-3 family of FIPS 202, are:
Resistance to length extension attacks.
With SHA-256, given $H(m)$ but not $m$, it is easy to find $H(m \mathbin\| m')$ for certain suffixes $m'$. Not so with any of the SHA-3 functions.
This means, e.g., that $m \...
answered Mar 26 '19 at 15:21
Squeamish Ossifrage
44.1k3 gold badges92 silver badges188 bronze badges
30
$\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 ...
30
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 ...
30
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, ...
29
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 ...
24
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 ...
23
Theoretically, since the domain of SHA-256 contains $2^{2^{64}-1}$ different messages and the value set only contains $2^{256}$ different message digests, there must exist at least one possible output that has more than one possible pre-image.
Another important point is that SHA-256 is a deterministic function. This means that if you hash the same message ...
22
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 ...
22
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
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 ...
22
As of today (12th September 2019) Tradwell Stanton DuPont have retracted their claim:
Sorry for the image link, but the text on their site doesn't seem to be permalinkable, and I wanted a more permanent source, it says:
NEW YORK, NEW YORK, UNITED STATES, September 12, 2019
The Wall Street fintech Treadwell Stanton DuPont again broke silence today as it ...
21
The only rule for the key is that it should at least contain 256 bits of randomness. If the key is smaller you may not get the full security of HMAC-SHA-256. The full security of HMAC is basically identical to the output size. Unless you are trying to protect yourself against quantum computers you should be able to get away with a key that contains 128 bits ...
21
This depends on what kind of hash function you mean and what kind of security you want.
Poly1305 is an almost-universal hash family, which, when used with a uniform random key for a single message, has forgery probability for messages of $L$ bytes bounded by $8\lceil L/16\rceil/2^{106}$. This means that an adversary, given $(m, a)$ where $a = \operatorname{...
answered May 20 '18 at 18:11
Squeamish Ossifrage
44.1k3 gold badges92 silver badges188 bronze badges
21
First of all, the output of SHA-256 is binary and consists of 32 bytes (256 denotes the output size in bits). What you are talking about is apparently the hexadecimal encoding of these bytes.
The possibility that you are talking about is called (1st) pre-image resistance (Wikipedia):
Given a hash value $h$, it should be difficult to find any message $m$ ...
20
Strictly speaking, all hash functions are compressing since the output can be smaller than the input, but I imagine you're asking about compressing data that can later be losslessly decompressed.
This is impossible due to the pigeonhole principle. The fact that the fixed output space of a hash algorithm is smaller than the input space means that there will ...
Only top voted, non community-wiki answers of a minimum length are eligible