How does hmac md5 work




















However, if desired, a performance improvement can be achieved at the cost of possibly modifying the code of H to support variable IVs.

The idea is that the intermediate results of the compression function on the B-byte blocks K XOR ipad and K XOR opad can be precomputed only once at the time of generation of the key K, or before its first use.

These intermediate results are stored and then used to initialize the IV of H each time that a message needs to be authenticated. This method saves, for each authenticated message, the application of the compression function of H on two B-byte blocks i. Such a savings may be significant when authenticating short streams of data.

We stress that the stored intermediate values need to be treated and protected the same as secret keys. Choosing to implement HMAC in the above way is a decision of the local implementation and has no effect on inter-operability. Truncated output A well-known practice with message authentication codes is to truncate the output of the MAC and output only part of the bits e. The results in this area are not absolute as for the overall security advantages of truncation.

It has advantages less information on the hash result available to an attacker and disadvantages less bits to predict for the attacker. Applications of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the HMAC computation for some parameter t namely, the computation is carried in the normal way as defined in section 2 above but the end result is truncated to t bits.

We recommend that the output length t be not less than half the length of the hash output to match the birthday attack bound and not less than 80 bits a suitable lower bound on the number of bits that need to be predicted by an attacker. If the parameter t is not specified, e. Security The security of the message authentication mechanism presented here depends on cryptographic properties of the hash function H: the resistance to collision finding limited to the case where the initial value is secret and random, and where the output of the function is not explicitly available to the attacker , and the message authentication property of the compression function of H when applied to single blocks in HMAC these blocks are partially unknown to an attacker as they contain the result of the inner H computation and, in particular, cannot be fully chosen by the attacker.

These properties, and actually stronger ones, are commonly assumed for hash functions of the kind used with HMAC. In particular, a hash function for which the above properties do not hold would become unsuitable for most probably, all cryptographic applications, including alternative message authentication schemes based on such functions.

Informational [Page 5] RFC HMAC February Given the limited confidence gained so far as for the cryptographic strength of candidate hash functions, it is important to observe the following two properties of the HMAC construction and its secure use for message authentication: 1.

The construction is independent of the details of the particular hash function H in use and then the latter can be replaced by any other secure iterative cryptographic hash function. Message authentication, as opposed to encryption, has a "transient" effect.

A published breaking of a message authentication scheme would lead to the replacement of that scheme, but would have no adversarial effect on information authenticated in the past. This is in sharp contrast with encryption, where information encrypted today may suffer from exposure in the future if, and when, the encryption algorithm is broken. The strongest attack known against HMAC is based on the frequency of collisions for the hash function H "birthday attack" [ PV , BCK2 ], and is totally impractical for minimally reasonable hash functions.

How would the client know the message it received came from the legitimate source? When two parties exchange messages through those secure file transfer protocols, those messages will be accompanied by HMACs instead of plain hashes. An HMAC employs both a hash function and a shared secret key. A shared secret key provides exchanging parties a way to establish the authenticity of the message. That is, it provides the two parties a way of verifying whether both the message and MAC more specifically, an HMAC they receive really came from the party they're supposed to be transacting with.

The secret key enables this capability because it's generated during key exchange , a preliminary process that requires the participation of the two parties. Only those two parties who participated in the key exchange would know what the shared secret key is.

In turn, they would be the only ones who would be able to arrive at the same result if they compute the message's corresponding MAC using the shared secret key. Aside from its ability to enable data integrity and message authentication, another reason why HMAC is an excellent file transfer data integrity-checking mechanism is its efficiency. As discussed in the article Understanding Hashing , hash functions can take a message of arbitrary length and transform it into a fixed-length digest.

That means, even if you have relatively long messages, their corresponding message digests can remain short, allowing you to maximize bandwidth.

Because an HMAC's properties especially its crypto strength is highly dependent on its underlying hash function, a particular HMAC is usually identified based on that hash function.

You've probably heard about the collision-related vulnerabilities of MD5. So which HMAC should you use? You would normally choose an HMAC based on its underlying hash function. A MAC is a signature based on a secret key, providing similar assurances to a signature scheme based on public-key cryptography such as RSA-based schemes where the signature must have been produced by a principal in possession of the private key.

For example, suppose Alice keeps her secret key to herself and only ever uses it to compute MACs of messages that she stores on a cloud server or other unreliable storage media. If she later reads back a message and sees a correct MAC attached to it, she knows that this is one of the messages that she stored in the past.

An HMAC by itself does not provide message integrity. It can be one of the components in a protocol that provides integrity. For example, suppose that Alice stores successive versions of multiple files on an unreliable media, together with their MACs. Again we assume that only Alice knows the secret key. If she reads back a file with a correct MAC, she knows that what she read back is some previous version of some file she stored.

An attacker in control of the storage media could still return older versions of the file, or a different file. One possible way to provide storage integrity in this scenario would be to include the file name and a version number as part of the data whose MAC is computed; Alice would need to remember the latest version number of each file so as to verify that she is not given stale data.

Another way to ensure integrity would be for Alice to remember the MAC of each file but then a hash would do just as well in this particular scenario. HMAC is a computed "signature" often sent along with some data. The HMAC is used to verify authenticate that the data has not been altered or replaced. Here is a metaphor:. You are going to mail a package to Sarah which contains a photograph.

You expect her to open the package and view the photograph. At some point in the near future you expect her to send you back the package with that photograph in it. It's vital that she put the same photograph back in the package. You need to be absolutely sure she doesn't send you back an altered photograph even a little bit, or replace it with a different one. You've got hundreds of these packages going out daily with different photos; you'd never remember the photo in such detail that you could tell if she changed a small bit of it like if she airbrushed a small zit off her face.

Here's what you can do: Before you send her the package, place another copy of the photograph inside a small locked box. Keep the key. Place the small locked box inside the package along with the original photograph you are mailing her. Assume she knows she is not to remove the locked box from the package. When you receive the package back from her, open it, place the photo on the table.

Open the locked box, remove the copy, compare the two. If they are the same, then she has not altered the photograph it is "authentic".

If the locked box is not in the package or your key will not open it, then assume she has done something nefarious and throw the whole package in the trash. The beauty here is that you don't need to "remember" anything about what you originally sent her; everything you need to ensure legitimacy of the photo comes back inside the package.

In the example above, the small locked box represents an HMAC. Your key is the HMAC's key. The photograph is the data you are applying the HMAC to.

The above is a round trip metaphor where only you have a key. In a different situation, let's say you often send packages to Tommy. You're worried that the nosey mail carriers might be opening your packages and replacing the photographs or changing them.

You do the same thing with the locked box, except in this case, you let Tommy have a copy of the key, so that when he receives a package, he can open the locked box included and compare the photos himself. If upon receipt he finds the photos differ, his key doesn't open the box, or the box missing, he knows something is fishy. The above metaphors describe why HMACs are needed but not so much how they work. Let's change the metaphor again to get closer to how they work:.

Let's keep the mental imagery of the package with the photograph: you want to mail it, then receive it back again like before, ensuring the photo was not altered or replaced by the receiver, or during the round trip.

Before you close the package and mail it, you make a copy of the photograph. No locked box this time, instead you brush over the copy with a concoction of liquid chemicals. Only you know the recipe key for this mixture, and anytime you brush over a copy, you use the exact same brush strokes.



0コメント

  • 1000 / 1000