Why did Hashable fail

HMAC: Encrypted hashing

In RFC 2104 a procedure for authentication is described, which works without an RSA procedure. For this purpose, the generation of a hash value is made dependent on a key.

The task is to check a received document to see whether it was deliberately falsified during transmission. An active attacker could falsify the document and generate a new hash value. DSA and similar methods encrypt this hash value with a private key. HMAC inserts a secret key into the document and hashes the resulting new document. This cannot be traced by an attacker. At most, he could falsify the hash value, but this would mean that the authentication would fail completely, i.e. a forged document would not be recognized as genuine. If the secret key is only known to two parties, they can use this key to prove the authenticity of a message. This also applies if an instance wants to make sure that a saved document has not been deliberately falsified.

RFC 2104 states the following design goals:

  1. Be able to use existing hash functions unchanged, which are available in hardware or software, and whose code is freely available.
  2. Use the speed of the hash functions without sacrificing performance.
  3. To be able to handle the keys in a simple way
  4. Know a well-understood cryptographic analysis of the strengths of the algorithm, based on reasonable assumptions about the underlying hash functions.
  5. To be able to easily replace the underlying hash function if faster or more secure hash functions are found or needed.

The procedure is based on the security of well-known hash procedures such as MD5, SHA-1 or RIPEMD. The idea is to add a key to a text so that the fingerprint depends not only on the text but also on the key.

The following values ​​are introduced:

H: hash algorithm,
B: input block length of the hash algorithm H (e.g. 64 bytes for MD5 and SHA-1),
L: Length of the hash value (fingerprint) of the hash algorithm H (e.g. L = 16 bytes for MD5 and L = 20 bytes for SHA-1),
S: key of length k<B,
K = S + (0016)B-k, or if k> B: K = H (S) + (0016)B-L
IPAD = (0011 01102)B. = (3616)B., inner pad,
OPAD = (0101 11002)B. = (5C16)B., Outer pad.

The key must not be longer than the length of an input block. If it is longer, the value of the key is first hashed with H and the fingerprint of length L is used as the key. If a key shorter than B is used, the key on the right must be filled with 0 bytes, i.e. in the following K = S + (0016)B-k or if k> B, K = H (S) + (0016)B-L.

The algorithm calculates the following hash value:

Digest = H (K xor OPAD + H (K xor IPAD + text)).

Thus, K is linked to the iPad (xor) and hung in front of the text, whereupon the hash algorithm is applied. The result of the length L is attached to K xor OPAD and this value is hashed again. The strength of the algorithm essentially depends on the strength of the hash algorithm H, as long as the key length is not chosen to be shorter than L bits. Please note that the values ​​(K xor OPAD) and (K xor IPAD) can be calculated independently of the text, which RFC 2104 expressly recommends.

RFC 2104 considers this procedure to be secure, provided the following prerequisites are met:

  1. HMAC is implemented correctly.
  2. The keys are generated purely randomly or with a cryptographic random number generator.
  3. The key exchange mechanism is secure.
  4. The keys are changed frequently.
  5. The keys are kept safe.

Please note that breaking a key at HMAC does not mean that all previous applications become unsafe; only new hash algorithms or new keys will have to be used in the future.