Cryptographic hash functions are hash functions that satisfy cryptographic requirements and can be used in encryption, signature or authentication procedures.
Hash functions are functions that convert an input of any length into an output that corresponds to a previously specified size. Hash functions always deliver the same output for two identical inputs. This is referred to as deterministic behavior.
Cryptographic hash functions are used in a variety of cryptographic procedures.
The strength, i.e. the resistance to attacks on cryptographic procedures such as an encryption protocol, depends heavily on the hash functions used in these algorithms. For this reason, high demands are placed on hash functions that are to be used in cryptographic procedures.
Such a hash function must be able to withstand all known cryptanalytic attacks, which would be used, among other things, in a vulnerability analysis. For this, the function must have the following three properties.
It must be difficult to find another input for a concrete input and its corresponding output of the hash function that gives the same output.
Again, 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 also consequently have a high second pre-image resistance.
These three requirements lead to the fact that a good hash function fulfills the property of the so-called avalanche effect. This property states that even minor changes to the input change the generated output very strongly. As a result, it is not possible to infer the corresponding inputs by analyzing different outputs.
58e769d6dede714bcfa1e3953b31d 8e575420fd10e9e187e77166dfd4 72173a2
6e085d38614a1b999dece462a1767 80b675dffd07de2f6381ec8400c5b 66e344
Procedures for checking and confirming passwords require cryptographic hash functions. It is not secure to store passwords in plain text and then match them directly with an entered password. In doing so, 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 exploited directly.
To prevent this, passwords must be stored as hash values. Because the passwords used cannot be calculated back from these hashes (property of the one-way function), the actual password cannot be calculated in a realistic time when a secure hash function and a good password are used.
Procedures for securely hashing passwords are known as key derivation functions. In these procedures, passwords are hashed repeatedly by a hash function, usually in conjunction with a salt. The output of the previous hash function is hashed again by the same function. The usual number of repetitions is 10,000, for example. The use of a salt is necessary to increase the security of the passwords and to prevent rainbow table attacks, for example.
When a password is created, this process is run through and the result and the corresponding salt value are stored. If a user now logs in with the assigned password, this is first combined with the stored salt and then runs 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.
Using the key derivation function PBKDF2 with the password "hunter22" and the salt "salt" at 10000 iterations:
787a933636cf2ffcb383b99365245ee 639db5a5a833e757c05fe36ac7b9a 1ff7
This value would subsequently be stored in a password database.
Using "simple" cryptographic hash methods is not secure for password confirmation. Passwords hashed with the MD5 algorithm, for example, can be partially linked to your inputs by simply Googling the hash value.
MD5 hash value for hunter22 = cb95015a436fe976eb38e45455372032
Confirming the authenticity and integrity of messages and files is made possible by cryptographic hash functions and their hash values their application. By forming a hash value of a transmitted message, it is possible to verify that the message when transmitted corresponds to the message that is received.
In this case, we are talking about HMAC (hashed message authentication codes). In this case, the sender of a message creates the hash value for this message with a previously determined hash function and also transmits this. The recipient uses the received message and the same hash function to generate 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 modified during transport. This procedure assumes that the transmitted HMAC cannot be modified by an attacker.
When using asymmetric cryptosystems, hash values of the messages to be signed are usually created. 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 hash value of the message formed by the partner itself, it can be confirmed that the message actually originated from this communication partner if the hash values are identical.
Known hashing methods that are currently state of the art and can therefore be used in cryptographic processes are SHA-2 and SHA-3. SHA stands for Secure Hash Algorithm. However, since SHA-2 is based on the same design principle as SHA-1, and SHA-1 is no longer considered secure, 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 presumably no longer correspond to the current state of the art. This suspicion does not exist for 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 algorithms MD5 and SHA-1 are considered insecure 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 precomputed values. The collision resistance of the procedure is thus no longer given, because attackers are able to exchange documents or messages without this being noticed when checking the hash values (e.g. HMAC).
In January 2020, a chosen-prefix collision attack on SHA-1 was published, which can be performed with a comparatively low computational effort. With a computational cost of about 45,000 USD at the current time, different inputs can be computed with the same resulting hash value. Thus, even for SHA-1, collision resistance is no longer a given. The developers of the attack were able to forge the digital signature for a key used in GnuPG and thus show that signatures based on SHA-1 can no longer be considered secure.
SHA-1 can still be used in ciphersuites even in the standard TLS 1.2. These suites should definitely be deactivated. 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 thus theoretically offers the possibility of injecting malicious code into Git repositories unnoticed by a check of the hash values.