Content deleted Content added
removed wrong comma (minor edit)→Classical Hash Functions - Practical Approach to Security |
m Replaced 1 bare URLs by {{Cite web}}; Replaced "Archived copy" by actual titles |
||
(34 intermediate revisions by 27 users not shown) | |||
Line 1:
{{Short description|None}}
In [[cryptography]], [[cryptographic hash functions]] can be divided into two main categories. In the first category are those functions whose designs are based on
In the second category are functions
==
Generally, the ''basic'' security of [[cryptographic hash functions]] can be seen from
* '''Pre-image resistance''': given a hash {{Mvar|h}}, it should be ''hard'' to find any message {{Mvar|m}} such that {{Math|1=''h'' = hash(''m'')}}. This concept is related to that of
* '''Second pre-image resistance''': given an input
* '''Collision resistance''': it should be ''hard'' to find two different messages
* '''Pseudo-randomness''': it should be ''hard'' to distinguish a pseudo-random number generator based on the hash function from true random number generator; for example, it passes usual [[randomness tests]].
===
The basic question is the meaning of
However, non-existence of a polynomial time algorithm does not automatically ensure that the system is secure. The difficulty of a problem also depends on its size. For example, [[RSA public key cryptography|RSA public-key cryptography]] (which relies on the difficulty of [[integer factorization]]) is considered secure only with keys that are at least 2048 bits long, whereas keys for the [[ElGamal encryption|ElGamal cryptosystem]] (which relies on the difficulty of the [[discrete logarithm]] problem) are commonly in the range of 256–512 bits.
▲The basic question is the meaning of "'''hard'''". There are two approaches to answer this question. First is the intuitive/practical approach: "hard means that it is almost certainly beyond the reach of any adversary who must be prevented from breaking the system for as long as the security of the system is deemed important."
===Password case===
If the set of inputs to the hash is relatively small or is ordered by likelihood in some way, then a brute force search may be practical, regardless of theoretical security. The likelihood of recovering the preimage depends on the input set size and the speed or cost of computing the hash function. A common example is the use of hashes to store [[password]] validation data. Rather than store the plaintext of user passwords, an access control system typically stores a hash of the password. When a person requests access, the password they submit is hashed and compared with the stored value. If the stored validation data is stolen, then the thief will only have the hash values, not the passwords. However, most users choose passwords in predictable ways, and passwords are often short enough so that all possible combinations can be tested if fast hashes are used.<ref>{{cite web
| url=https://arstechnica.com/information-technology/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/
| title=25-GPU cluster cracks every standard Windows password in <6 hours
| date=2012-12-10
| first=Dan
| last=Goodin
| publisher=[[Ars Technica]]
| access-date=2020-11-23}}</ref> Special hashes called [[key derivation function]]s have been created to slow searches. ''See'' [[Password cracking]].
==Cryptographic hash functions==
{{Main article|Cryptographic hash function}}
Most hash functions are built on an ad
▲Most hash functions are built on an ad hoc basis, where the bits of the message are nicely mixed to produce the hash. Various [[bitwise operation]]s (e.g. rotations), [[Modular arithmetic|modular additions]] and [[One-way compression function|compression functions]] are used in iterative mode to ensure high complexity and pseudo-randomness of the output. In this way, the security is very hard to prove and the proof is usually not done. Only a few years ago, one of the most popular hash functions, [[SHA-1]], was shown to be less secure than its length suggested: collisions could be found in only 2<sup>51</sup><ref>http://eprint.iacr.org/2008/469.pdf</ref> tests, rather than the brute-force number of 2<sup>80</sup>. The search for a "good" hash function has thus become a hot topic.
In other words, most of the hash functions in use nowadays are not provably collision-resistant. These hashes are not based on purely mathematical functions. This approach results generally in more effective hashing functions, but with the risk that a weakness of such a function will be eventually used to find collisions.
In this approach,
A cryptographic hash function has ''provable security against collision attacks'' if finding collisions is provably [[Polynomial-time reduction|polynomial-time reducible]] from a problem ''P'' which is supposed to be unsolvable in polynomial time. The function is then called provably secure, or just provable.
▲In this approach, we base the security of hash function on some hard mathematical problem and we prove that finding collisions of the hash functions is as hard as breaking the underlying problem. This gives much stronger security than just relying on complex mixing of bits as in the classical approach.
However, this only indicates that finding collisions is difficult in ''some'' cases, as not all instances of a computationally hard problem are typically hard. Indeed, very large instances of NP-hard problems are routinely solved, while only the hardest are practically impossible to solve.
▲=== Hard problems ===
* Current{{When|date=August 2024}} collision-resistant hash algorithms that have provable security [[Reduction (complexity)|reductions]] are too inefficient to be used in practice. In comparison to classical hash functions, they tend to be relatively slow and do not always meet all of criteria traditionally expected of cryptographic hashes. [[Very smooth hash]] is an example.▼
▲Examples of problems, that are assumed to be not solvable in polynomial time
* Constructing a hash function with provable security is much more difficult than using a classical approach where
▲* [[Discrete logarithm|Discrete Logarithm Problem]]
* The proof is often a reduction to a problem with asymptotically hard [[Worst-case complexity|worst-case]] or [[average-case complexity]]. Worst-case complexity measures the difficulty of solving pathological cases rather than typical cases of the underlying problem. Even a reduction to a problem with hard average-case complexity offers only limited security, as there still can be an algorithm that easily solves the problem for a subset of the problem space. For example, early versions of [[Fast Syndrome Based Hash]] turned out to be insecure. This problem was solved in the latest version.▼
▲* [[Quadratic residue|Finding Modular Square Roots]]
▲* [[Integer factorization|Integer Factorization Problem]]
▲* [[Subset sum problem|Subset Sum Problem]]
[[SWIFFT]] is an example of a hash function that circumvents these security problems. It can be shown that, for any algorithm that can break SWIFFT with probability
▲=== Downsides of Provable Approach ===
▲* Current collision-resistant hash algorithms that have provable security [[Reduction (complexity)|reductions]] are too inefficient to be used in practice. In comparison to classical hash functions, they tend to be relatively slow and do not always meet all of criteria traditionally expected of cryptographic hashes. [[Very smooth hash]] is an example.
▲* Constructing a hash function with provable security is much more difficult than using a classical approach where we just hope that the complex mixing of bits in the hashing algorithm is strong enough to prevent adversary from finding collisions.
▲* The proof is often a reduction to a problem with asymptotically hard [[Worst-case complexity|worst-case]] or [[average-case complexity]]. Worst-case measures the difficulty of solving pathological cases rather than typical cases of the underlying problem. Even a reduction to a problem with hard average complexity offers only limited security as there still can be an algorithm that easily solves the problem for a subset of the problem space. For example, early versions of [[Fast Syndrome Based Hash]] turned out to be insecure. This problem was solved in the latest version.
===Example of (impractical) provably secure hash function===
▲[[SWIFFT]] is an example of a hash function that circumvents these security problems. It can be shown that for any algorithm that can break SWIFFT with probability P within an estimated time T, we can find an algorithm that solves the ''worst case'' scenario of a certain difficult mathematical problem within time T' depending on T and P.
But the algorithm is quite inefficient because it requires on average 1.5 multiplications modulo
▲Hash(''m'') = ''x''<sup>''m''</sup> mod ''n'' where ''n'' is hard to factor composite number, and ''x'' is some prespecified base value. A collision ''x''<sup>''m1''</sup> congruent to ''x''<sup>''m2''</sup> reveals a multiple ''m1 - m2'' of the order of ''x''. Such information can be used to factor ''n'' in polynomial time assuming certain properties of ''x''.
===More practical provably secure hash functions===
▲But the algorithm is quite inefficient because it requires on average 1.5 multiplications modulo ''n'' per message-bit.
* [[Very smooth hash|VSH
▲=== More practical provably secure hash functions ===
▲* [[Very smooth hash|VSH - Very Smooth Hash function]] - a provably secure collision-resistant hash function assuming the hardness of finding nontrivial modular square roots modulo composite number <math>n</math> (this is proven to be as hard as [[Integer factorization|factoring]] <math>n</math>).
* [[MuHASH]]
* [[Elliptic curve only hash|ECOH]]—[[Elliptic
* [[Fast Syndrome Based Hash|FSB]]—[[Fast
* [[SWIFFT]]
* [[Chaum, van Heijst, Pfitzmann hash function]]
* [[Knapsack-based hash functions]]
* [[The Zémor-Tillich hash function]]
| last1 = Petit | first1 = C.
| last2 = Quisquater | first2 = J.-J.
Line 67 ⟶ 76:
| contribution = Hard and easy Components of Collision Search in the Zémor-Tillich hash function:new Attacks and Reduced Variants with Equivalent Security
| contribution-url = http://www-rocq.inria.fr/secret/Jean-Pierre.Tillich/publications/CTRSA.pdf }}</ref>
* [[Hash functions from Sigma Protocols]]
==References==
|