Cryptographic hash functions are hash functions that meet cryptographic requirements and can be used in encryption, signature or authentication processes.
Hash functions
Hash functions are functions that convert an input of any length into an output that corresponds to a predetermined size. Hash functions always deliver the same output with two identical inputs. One speaks here of deterministic behavior.
What is a cryptographic hash function?
Cryptographic hash functions are used in a large number of cryptographic processes.
The strength, i.e. the resistance to attacks on cryptographic processes such as B. an encryption protocol depends heavily on the hash functions used in these algorithms. Therefore, high demands are made on hash functions that are to be used in cryptographic processes. Such a hash function must be able to withstand all known cryptanalytic attacks that would be used in a vulnerability analysis, among other things. For this, the function must have the following three properties.
Pre-image resistance:
A hash value that was generated through the use of a hash function should be very difficult to calculate back into the value that served as input for the hash function. This means that hash functions must behave like one-way functions, in which the function should work very simply and as efficiently as possible in one direction, but reversing the function is very difficult and involves high (computing) effort.
Second pre-image resistance:
It must be difficult to find another input that delivers the same output for a specific input and its corresponding output of the hash function.
Collision resistance:
Here, too, it must be difficult to find two different inputs that produce the same output from the hash function. Hash functions that have a high collision resistance consequently also have a high second pre-image resistance.
These three requirements mean that a good hash function fulfills the property of the so-called avalanche effect. This property means that even minor changes to the input change the output generated very significantly. This means that it is not possible to draw conclusions about the associated inputs by analyzing different outputs.
Example
SHA3_256 Hashes:
ProSec
ProSek
= 58e769d6dede714bcfa1e3953b31d8e575420fd10e9e187e77166dfd472173a2
= 6e085d38614a1b999dece462a176780b675dffd07de2f6381ec8400c5b66e344
= ac8192b8f83f38b89762f747c9171849eaaaaeb24c4fcfc532db6cfcf5403e06
Applications of cryptographic hash functions
Password confirmation:
Procedures for checking and confirming passwords require cryptographic hash functions. It is not safe to save passwords in plain text so that they can then be compared directly with an entered password. There is a risk that the database in which such passwords are stored will be hacked and the passwords will be publicly available. As a result, these passwords could be used directly.
To prevent this, passwords must be saved as hash values. Because the passwords used cannot be recalculated from these hashes (property of the one-way function), the actual password cannot be calculated in a realistic time if a secure hash function and a good password are used. Method for securely hashing passwords is known as key derivation functions. With this method, passwords, usually combined with a so-called salt, are hashed repeatedly using a hash function. The output of the previous hash function is hashed again by the same function. For example, 10,000 repetitions of this process are common here. The use of a salt is necessary to increase the security of the passwords and e.g. B. to prevent rainbow table attacks.
When creating a password, this process is run through and the result and the corresponding salt value are saved. If a user logs in with the assigned password, this is first combined with the stored salt and then goes through the same process again. If the correct password is used, the hash value obtained from the process corresponds to the previously stored hash value and the password entered is correct. Examples of common key derivation functions that are currently considered secure are PBKDF2 or scrypt.
Example:
Use of the key derivation function PBKDF2 with the password “hunter22” and the salt “salt” for 10000 iterations:
Hunter22
= 787a933636cf2ffcb383b99365245ee639db5a5a833e757c05fe36ac7b9a1ff7
This value would then be saved in a password database.
The use of “simple” cryptographic hash procedures is not secure for password confirmation. Passwords that are hashed with the MD5 algorithm can e.g. For example, you can link the hash value to your inputs by simply searching for a Google search.
Example:
MD5 hash value for hunter22 = cb95015a436fe976eb38e45455372032
Hashing procedures (SHA-2, SHA-3) that are considered secure are also not suitable for simple use in password hashing, because in this case rainbow tables can be created that can efficiently “calculate back” the hash values in the password.
Authenticity of messages and files
Confirmation of the authenticity and integrity of messages and files is made possible by cryptographic hash functions and their hash values. By forming a hash value of a transmitted message, it is possible to check whether the message when transmitted corresponds to the message that is received. In this case we are talking about so-called HMAC (hashed message authentication codes). Here, the sender of a message forms the hash value for this message with a previously determined hash function and also transmits this. With the received message and the same hash function, the recipient also forms the hash value of the message and compares this hash value with the transmitted hash value. If both values are identical, it can be assumed that the message was not changed during transport. This procedure assumes that the transmitted HMAC cannot be changed by an attacker.
Creation of digital signatures and their verification:
When using asymmetric cryptosystems, hash values are usually created for the messages to be signed. These are then encrypted with the private key of the signing communication partner. By decrypting the hash value with the public key of the signing partner and comparing it with the message’s own hash value, it can be confirmed that the message actually originates from this communication partner if the hash values are identical.
Known hashing methods and vulnerabilities
Known hashing methods that currently correspond to the state of the art and can therefore be used in cryptographic methods are SHA-2 and SHA-3. SHA stands for Secure Hash Algorithm. Since SHA-2 is based on the same design principle as SHA-1, and SHA-1 is no longer considered safe, it can be assumed that it will also be possible to successfully attack the SHA-2 procedure in the near future. SHA-2 will then probably no longer correspond to the current state of the art. This suspicion does not exist in the case of SHA-3, because the Keccak algorithm standardized in SHA-3 is based on a fundamentally different design principle and is therefore not susceptible to the same attacks.
The widely used MD5 and SHA-1 algorithms are considered unsafe because successful attacks have been published for both methods. In 2012 a so-called chosen-prefix collision attack was published for MD5. With such an attack it is possible to generate the same hash value for two different documents or messages by combining them with certain precalculated values. The collision resistance of the method is no longer given because attackers are able to exchange documents or messages without this being noticed when checking the hash values (e.g. the HMAC).
In January 2020 a chosen-prefix collision attack was published on SHA-1, which can be carried out with comparatively little computing effort. With a computing power that is currently associated with costs of around 45,000 USD, different inputs can be calculated with the same resulting hash value. This means that SHA-1 is also no longer collision-resistant. The developers of the attack were able to forge the digital signature for a key used in GnuPG and thus show that the signatures based on SHA-1 can no longer be considered secure.
SHA-1 can still be used in cipher suites in the TLS 1.2 standard. It is important to disable these suites. TLS 1.3 no longer allows SHA-1.
The version control system Git also uses SHA-1 for file verification. The possibility of the chosen-prefix collision attack theoretically offers the possibility of smuggling malicious code unnoticed into Git repositories, which is not noticed by checking the hash values.