View source for Talk:HMAC

{{WikiProject banner shell|class=C|
{{WikiProject Cryptography|importance=High}}
}}
{{To do}}
{{High-traffic|date=November 15, 2007|site=Wired News|url=http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115|small=}}

== timing attacks ?! ==
"At least theoretically a timing attack could be performed to find out a HMAC digit by digit.[9]"
There are no such things as timing attacks on HMAC by itself: it might leak the key size but nothing more if the underlying hash function is not vulnerable to timing attacks. The reference probably refers to a timing attack made on the memcmp used to compare the stored mac with the evaluated mac. That would allow the attacker to forge a valid, stored, HMAC digit by digit. See http://beta.ivc.no/wiki/index.php/Xbox_360_Timing_Attack  <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/93.50.106.102|93.50.106.102]] ([[User talk:93.50.106.102|talk]]) 23:00, 17 July 2012 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->

:what is the correct key [[Special:Contributions/120.28.219.213|120.28.219.213]] ([[User talk:120.28.219.213|talk]]) 15:19, 12 June 2023 (UTC)

I have removed mention of the timing attack. as it was unsourced with respected to HMACs. If someone can find a good source for it then it can be put back in [[Special:Contributions/103.38.149.55|103.38.149.55]] ([[User talk:103.38.149.55|talk]]) 09:58, 3 April 2017 (UTC)

: i agree with the removal, but for a different reason: it is about "short circuit" comparison, which does not belong to this topic, because it is a more general concept. [[User:Krisztián Pintér|Krisztián Pintér]] ([[User talk:Krisztián Pintér|talk]]) 11:55, 3 April 2017 (UTC)

== added example usage for non-mathletes. ==

I added some text for readers that just want to know how to implement an HMAC without necessarilly understanding the math behind it.  I plan to add some example C or python code that displays how a message would be verified.
: I don't think we'd gain anything from programming language code, to be honest. There isn't a great deal of maths to understand for HMAC. It's just a short sequence of concatenations, XORs and hash function calls, and is readily comprehensible from the definition given in the article. I think it would be redundant to write it again out in C or Python. Compare, say, [[SHA-1]] or [[MD5]], which are complex algorithms which benefit from a pseudo-code treatment. [[User:Matt Crypto|&mdash; Matt <small>Crypto</small>]] 09:31, 5 November 2005 (UTC)
: Just passing by: the python example really ain't that easy to read, nor is it close to the pseudo-code sample: it uses a smart hack with translation tables to avoid XOR operations, which are quite expensive in Python. --[[User:Mistouille|Mistouille]] ([[User talk:Mistouille|talk]]) 08:49, 22 July 2013 (UTC)

== Blocksize on pseudo code ==

 blockSize: Integer   the block size of the underlying hash function (e.g. 32 bytes for SHA-256)

On SHA-256, the output size is 32 bytes, however the input block size is 64 bytes. In this example, using SHA-256, shouldn't block size be set to 64 instead ?  <!-- Template:Unsigned IP --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/164.40.221.237|164.40.221.237]] ([[User talk:164.40.221.237#top|talk]]) 13:39, 12 November 2017 (UTC)</small> <!--Autosigned by SineBot-->

== Bug in pseudo code?? ==

Existing Pseudo code

    if (length(key) > blocksize) then
        key = hash(key) // keys longer than blocksize are shortened
    else if (length(key) < blocksize) then
        key = key ∥ zeroes(blocksize - length(key)) // keys shorter than blocksize are zero-padded
    end if

At the end of this if statement key is hashed first branch is taken and not hashed otherwise.  Looking at algorithm I suggest the following:

    if (length(key) > blocksize) then
        key = left(key,blocksize) // keys longer than blocksize are shortened
    else if (length(key) < blocksize) then
        key = key ∥ zeroes(blocksize - length(key)) // keys shorter than blocksize are zero-padded
    end if

Tony Wallace (tony@tony.gen.nz)  <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/131.203.134.23|131.203.134.23]] ([[User talk:131.203.134.23|talk]]) 22:36, 19 April 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

: Your suggestion is irrelevant. What matters is the standard that defines HMAC. This standard was accurately described before you changed it. Hence, I'm reverting your proposal. [[Special:Contributions/83.78.173.160|83.78.173.160]] ([[User talk:83.78.173.160|talk]]) 23:51, 20 April 2010 (UTC)

== Advantages over a pure hash ==

Can someone please explain why using HMAC(hashfunc, k, v) is better than using doing hashfunc(k||v)? It seems like this is a key question. (If you do answer this, I'd appreciate it if you leave a note on my talk page.) [[User:AaronSw|AaronSw]] 15:32, 13 April 2006 (UTC)

:Read the references in the article.  Knowing F(k||v) means you can compute F(k||v||u||...) trivially.  Nesting prevents this [http://www-cse.ucsd.edu/users/mihir/papers/kmd5.pdf] (page 16, at the bottom).  [[User:Mdf|mdf]] 13:44, 16 May 2006 (UTC)

::Except that all hash algorithms used with HMAC in practice already defeat this attack by including the original message length in the hashing process (ie. you can't construct H(k||v||u) from H(k||v); you must already know k and v). Was this added just to support theoretical hash functions that don't have this property?  The other question that arises is: why are the two keys (k1, k2) derived by XORing the key k with those magic numbers (0x36 and 0x5c)? Are the two keys required to be different (why?) and is there a motivation for using XOR (other than that it's fast) or would some random operation like k1 = k, k2 = (k + 1) mod 2^|k| work just as well?  If you feel qualified to answer these questions, please add them to the article (instead of only replying here). Thanks in advance! [[User:130.89.167.52|130.89.167.52]] 21:17, 16 February 2007 (UTC)

:::AIUI, because the message length and padding are known to the attacker, you can "back up" those hash functions to the previous (before finalize) state in order to do the concatenation attack.  [[User:121a0012|121a0012]] 21:43, 27 February 2007 (UTC)

:::The length being included doesn't help, because an attacker can include the length code in the extension data (u = original_length_code || new_data), which limits the choices for the extension data somewhat, but not enough to make attacks impractical at all. [[Special:Contributions/2001:470:D08D:0:0:0:0:1|2001:470:D08D:0:0:0:0:1]] ([[User talk:2001:470:D08D:0:0:0:0:1|talk]]) 20:23, 6 July 2013 (UTC)

== Typical usage?! ==

A pizza restaurant that suffers from attackers that place bogus orders is a typical usage of HMAC? Why won't anyone mention SMTP for God's sake? &mdash; '''212.76.37.162''' 11:57, 18 March 2006 (UTC)

Right...I'm sure this would be a great business model, for the 0.01% of customers who could be bothered to do such nonsense - as opposed to just calling. &mdash; '''24.8.120.181''' 18:41, 21 May 2006 (UTC)

Maybe the example was not explained properly. If you translate it to a normal use case scenario, the customer would be forced to provide a password along with the order on pizza company's webpage, and a applet on the browser would computer the hmac based on the password as the key, before passing it to the server.

== Padding ==

In the described pseudocode implementation of a HMAC, the padding of the key, if it is shorter than the blocksize of the message input of the specific hashfunction, is missing! 
How do you want to operate a XOR function if you don't have the same amount of bits on each sides?
--> If key's size is less than 512 bit long(after ipad) the fingerprint / hash of the key couldn't be the the initial key for the hashfunction (each 512 bit blocksize) of the message appended to the key!

: The pseudocode is fine. It alters ipad and opad, which have been set up to have the right length, by XORing the bytes of the key into the beginning of ipad and opad, leaving the final bytes (if any) unchanged at their original values. Remember that XORing with zero doesn't do a thing. [[User:Hanche|Hanche]] ([[User talk:Hanche|talk]]) 08:22, 2 January 2009 (UTC)

:: This is the problem with pseudocode... it's fine or not fine depending on how your pseudo xor is defined. If it's defined as padding the short operand with zeros to the length of the long one, then you get a valid HMAC. If it's defined as truncating the long operand to the length of the short one, you get something else. These are 2 reasonable interpretations; there may be more. (In fact, I think "xor on different length strings throws an exception" would be reasonable too.) The pseudocode and the Definition section both require the reader will guess the correct interpretation. [[Special:Contributions/67.162.91.170|67.162.91.170]] ([[User talk:67.162.91.170|talk]]) 19:11, 11 February 2017 (UTC)

::: the pseudocode never xors different length data. the only case it could happen if the hash produced more bits than the blocksize. but using such a hash would not make much sense, considering that it is there to shorten the long key. if either the original or the hashed key is shorter than the blocksize, 0's are appended. [[User:Krisztián Pintér|Krisztián Pintér]] ([[User talk:Krisztián Pintér|talk]]) 19:22, 11 February 2017 (UTC)

== Block Size ==
The pseudocode could use some help as to the clarity of L from RFC2104, being the output length of the Hash function used. While the code is written correctly it does kind of gloss over the fact that if length(key) > blocksize happens, length(key) < block size can and will also happen after key = hash(key) when using MD5; because B=64 and L=16.[[Special:Contributions/199.34.4.20|199.34.4.20]] ([[User talk:199.34.4.20|talk]]) 00:46, 2 June 2016 (UTC)
: it is in the definition of K' in the previous section. i don't think there should be more explanation in the pseudocode section. explanations belong to the definition section. [[User:Krisztián Pintér|Krisztián Pintér]] ([[User talk:Krisztián Pintér|talk]]) 08:07, 2 June 2016 (UTC)

: I was also confused by the definition of K'. But I could not think of a succinct enough way to state the definition.  [[User:Cowlicks|Cowlicks]] ([[User talk:Cowlicks|talk]]) 21:34, 9 December 2016 (UTC)

== Illustration ==

The illustration is really bad, I think. Utterly confusing. First, it appears to show HMAC(k,m) to be the two inputs rather than the output. Second, it shows the hash function h with two inputs and two outputs, with one of the two outputs feeding back into one of the inputs. You have to read the text to realize that the vertical direction is one application of h and the horizontal direction another. The two applications of h should have been drawn as separate boxes for clarity. [[User:Hanche|Hanche]] ([[User talk:Hanche|talk]]) 08:28, 2 January 2009 (UTC)

== Security Section ==

This section is very poorly written.  No mention of an NMAC is given.  This seems to be a summary of one paper on the security analysis of HMACs, this requires cleanup.--[[User:Chrismiceli|Chrismiceli]] ([[User talk:Chrismiceli|talk]]) 06:37, 20 July 2009 (UTC)

I have taken the liberty of performing the cleanup myself.  Please comment if desired. --[[User:Chrismiceli|Chrismiceli]] ([[User talk:Chrismiceli|talk]]) 05:02, 21 July 2009 (UTC)

There is the problem? If the hash is secure, it is impossible to find too different arguments with the same hash. That means, it is impossible to find to different messages or keys with the same HMAC. If the hash ist a one way function the HMAC is a one way function of message and key. It means HMAC is secure, if the hash is secure. --[[Special:Contributions/95.222.228.77|95.222.228.77]] ([[User talk:95.222.228.77|talk]]) 21:37, 28 July 2010 (UTC)
: No. The requirements for a secure hash function and a secure HMAC are different. A secure hash function must be collision resistant. For the HMAC to be secure it is according to the paper by Bellare sufficient if the underlying hash function is a "privacy preserving pseudorandom function". As far as I know neither security requirement implies the other one. In particular, Bellare's paper points out that collision resistant is not a necessary requirement for a secure HMAC and he does not use collision resistance in his security reductions. It is also not a problem if two HMACs ever are the same. Otherwise it would not be possible to truncate HMACs. [[Special:Contributions/85.1.138.140|85.1.138.140]] ([[User talk:85.1.138.140|talk]]) 07:27, 29 July 2010 (UTC)

::If the hash function is collision resistent, the securty is free of doubt. It should be possible to truncate the HMAC to 128 bits or 16 bytes, since it is only required, that for given key and message no second key or message can be found with the same HMAC. Even if the key is known, a second message never can be found by brute force testing a large number of messages with a 128 bit HMAC. --[[Special:Contributions/95.222.228.77|95.222.228.77]] ([[User talk:95.222.228.77|talk]]) 18:08, 30 July 2010 (UTC)

::: No. This is wrong. The security requirement is that an attacker can neither find the key nor find the correct HMAC for a new message. This requirement does not follow from collision resistance. Because MACs are an important application of hash functions, the SHA-3 submission are also examined for their resistance against so called "key recovery attacks" besides resistance against collision attacks. [[Special:Contributions/83.78.82.132|83.78.82.132]] ([[User talk:83.78.82.132|talk]]) 19:34, 30 July 2010 (UTC)
:::: In principle you are right, the hash function should not only be collision resistent, but also one way, meaning that there is no way to find the key from the HMAC (besides brute force). In practise collision resistent hash functions are allways believed to be one way. If it is impossible to find the key from the whole HMAC and message that is certainly true, if the HMAC is truncated. If the hash is not collision resistent it might be possible to calculate the HMAC for some special messages. That is probably not possible if the HMAC is truncated.  <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/95.222.228.77|95.222.228.77]] ([[User talk:95.222.228.77|talk]]) 10:38, 2 August 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->
:::::I'm sorry, but most of that is wrong.
:::::* <math>h</math> collision resistant and one-way <math>\nRightarrow</math> HMAC instantiated with <math>h</math> is a secure MAC: Assume <math>h':\{0,1\}^*\rightarrow\{0,1\}^n</math> is a random oracle. Let <math>h:\{0,1\}^{\geq n}\rightarrow\{0,1\}^{2n}, h(m)=h(m_{1}\cdot m_{2})=m_{1}\cdot h'(m_{2})\ </math>   where   <math>m=\ m_{1}\cdot m_{2}\ </math> and <math>\ |m_{1}|=n</math> i.e. <math>m</math> is split into the first block and the rest of the input. The first two blocks are copied to the output in clear, the rest is hashed securely. <math>h</math> is certainly collision resistant, but HMAC instantiated with <math>h</math> outputs the key in the clear. Also note that <math>h</math> is one way for inputs <math>m</math> with <math>|m|\geq 2n</math>. Oh and you can also truncate the HMAC and it will still be insecure.
:::::* <math>h</math> not collision resistant <math>\nRightarrow</math> HMAC instantiated with <math>h</math> is is insecure: For example MD5 is still acceptable for use with HMAC. As a more formal counterexample consider <math>h\left(m\right)=h\left(m_{1}\cdot m_{2}\right)=\begin{cases}
0^{n} & \; m_{1}=0^{\frac{n}{2}}\\
h'\left(m\right) & \;\text{otherwise}
\end{cases}</math>
:::::The property you really need is pseudo randomness of <math>h</math>, i.e. you cannot distinguish the output of <math>r: m\mapsto h(k||m) </math> from a completely random function without the key <math>k</math>. --[[User:Eta Aquariids|Eta Aquariids]] ([[User talk:Eta Aquariids|talk]]) 06:19, 9 August 2012 (UTC)
One possiblity would be to choose randomly 80 of the 160 bits from [[SHA-1]] HMAC. I guess this is very secure. --[[Special:Contributions/95.222.228.77|95.222.228.77]] ([[User talk:95.222.228.77|talk]]) 10:48, 2 August 2010 (UTC)
:MACs have to be deterministic to be of any use. Choosing the bits at random kind of defeats it's purpose. Also, as SHA1 tries to be a pseudorandom function itself, any 80 bits are as good as any other, as long as there is no serious attack on SHA1 found. --[[User:Eta Aquariids|Eta Aquariids]] ([[User talk:Eta Aquariids|talk]]) 11:42, 8 August 2012 (UTC)

== Problems displaying Unicode characters ==

Let me show you what your italicized unicode characters look like on my computer:<br />
[http://img222.imageshack.us/i/firefoxn.png/ In Firefox]<br />
[http://img80.imageshack.us/i/86223115.png/ In IE]<br />
--[[Special:Contributions/66.168.1.178|66.168.1.178]] ([[User talk:66.168.1.178|talk]]) 18:56, 2 December 2009 (UTC)

: What this person is complaining about appears to be the characters ∥ (U+2225 PARALLEL TO) and ⊕ (U+2295 CIRCLED PLUS) used in the article (though not in italics). They show up fine in firefox, but become boxes in IE. (Oddly, in the fonts his and my firefox are using, U+2225 shows up as two slanted parallel lines, hence the “italics” misunderstanding, I think. In the Unicode code charts, the lines are vertical.) Maybe one should use standard mathematical formating instead? (I lightly edited the anonymous user's entry, improving the headline for clarity.) [[User:Hanche|Hanche]] ([[User talk:Hanche|talk]]) 00:06, 3 December 2009 (UTC)

== order of XOR in pseudo code ==

The definition and the pseudo code don't use the same order in the XOR operation.

In the definition: HMAC(K,m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m))

In the pseudo code:
<pre>
o_key_pad = [0x5c * blocksize] ⊕ key
i_key_pad = [0x36 * blocksize] ⊕ key
</pre>

My guess is that the latter is wrong and should be instead:
<pre>
o_key_pad = key ⊕ [0x5c * blocksize]
i_key_pad = key ⊕ [0x36 * blocksize]
</pre>

: The order is irrelevant since XOR is commutative. But possibly, it might be worth changing the order for notational concistency. [[User:Hanche|Hanche]] ([[User talk:Hanche|talk]]) 19:37, 30 September 2010 (UTC)

== Copy ==

The Intro seems entirely copied from this source:
http://everything.explained.at/HMAC/  <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/118.208.214.179|118.208.214.179]] ([[User talk:118.208.214.179|talk]]) 21:51, 6 November 2011 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
: Nope, 'everything explained' looks like a wikipedia clone to me. [[Special:Contributions/81.62.78.223|81.62.78.223]] ([[User talk:81.62.78.223|talk]]) 08:20, 7 November 2011 (UTC)

Can any one provide full Psuedocode for HMAC? [[Special:Contributions/119.154.6.10|119.154.6.10]] ([[User talk:119.154.6.10|talk]]) 12:45, 25 April 2012 (UTC)

I've just removed a comment by 192.153.142.154 from the bottom of the intro section that read:
''[Great introduction of HMAC, largely plagiarized from "CCNA Security," Cisco Press (Michael Watkins & Kevin Wallace, 2008) pages 470-471]''. I haven't got a copy of that book, but if the comment's right the intro needs to be changed to avoid copyright infringement. If it qualifies under fair use, the book needs to be in the references. [[User:Wocky|Wocky]] ([[User talk:Wocky|talk]]) 10:22, 16 May 2015 (UTC)

== Image ==

The  file associated with the article (<tt>File:Shahmac.jpg</tt>) uses "''N'' byte" where it should use "''N'' bits".
[[User:JPGoldberg|JPGoldberg]] ([[User talk:JPGoldberg|talk]]) 15:06, 8 June 2012 (UTC)

== ipad and opad not important? ==

In the article, it says "''The values of ipad and opad are not critical to the security of the algorithm''". Is it safe to leave them out entirely? What is the significance of ensuring the inner and outer keys have few bits in common? [[User:Fresheneesz|Fresheneesz]] ([[User talk:Fresheneesz|talk]]) 18:38, 8 August 2012 (UTC)

The underlying idea of the HMAC security reduction requires the use of two different inner and outer keys. This is replaced with <math>k\oplus OPAD</math> and <math>k\oplus IPAD</math> with the argument that the first iteration of <math>h</math> (<math>h</math> is assumed to hash the data iteratively in a Merkle–Damgård construction) will act as a pseudo random function and generate two - for practical purposes independent - keys. This works as long as the two inputs to the first iteration of the hash function are different and that will be the case as long as IPAD and OPAD differ in at least one bit. 
Thus, although it is probably still secure to leave them out entirely, it is a bad idea as you have no formal argument ''why'' it is still secure. --[[User:Eta Aquariids|Eta Aquariids]] ([[User talk:Eta Aquariids|talk]]) 06:40, 9 August 2012 (UTC)

== "Hashed" redirect ==

Are there any objections to the creation of a redirect from [[Hashed message authentication code]] to this article? I believe it is a "sufficiently confusable" title since, for example, RFC 4635 expands the abbreviation that way. [[User:SoledadKabocha|SoledadKabocha]] ([[User talk:SoledadKabocha|talk]]) 00:50, 26 September 2012 (UTC)

== Replace Image ==

Someone registered may replace the image by this reworked png-version done by me.
http://www.imgbox.de/users/public/images/ZIehXcr0yA.png  <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/193.175.119.11|193.175.119.11]] ([[User talk:193.175.119.11|talk]]) 10:59, 11 January 2013 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->

== External links modified ==

Hello fellow Wikipedians,

I have just added archive links to {{plural:2|one external link|2 external links}} on [[Hash-based message authentication code]]. Please take a moment to review [https://en.wikipedia.org/w/index.php?diff=prev&oldid=685946727 my edit]. If necessary, add {{tlx|cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{tlx|nobots|deny{{=}}InternetArchiveBot}} to keep me off the page altogether. I made the following changes:
*Added archive https://web.archive.org/20100604234324/http://citeseerx.ist.psu.edu:80/viewdoc/summary?doi=10.1.1.34.3855 to http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.3855
*Added archive https://web.archive.org/20090223134840/http://citeseerx.ist.psu.edu:80/viewdoc/summary?doi=10.1.1.42.8908 to http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.8908

When you have finished reviewing my changes, please set the ''checked'' parameter below to '''true''' to let others know.

{{sourcecheck|checked=false}}

Cheers. —[[User:Cyberbot II|<sup style="color:green;font-family:Courier">cyberbot II</sup>]]<small><sub style="margin-left:-14.9ex;color:green;font-family:Comic Sans MS">[[User talk:Cyberbot II|<span style="color:green">Talk to my owner</span>]]:Online</sub></small> 00:30, 16 October 2015 (UTC)

== Pseudo code does not match functionality of definition ==

In the definition section, the following three elements are concatenated:
<pre>
K' ⊕ opad
H( K' ⊕ ipad )
message
</pre>

However in the pseudocode the following two elements are concatenated:
<pre>
K' ⊕ opad
H( K' ⊕ ipad , message )
</pre>

Is the problem in the Documentation or in the Pseudocode?

[[User:Dotancohen|Dotancohen]] ([[User talk:Dotancohen|talk]]) 16:26, 5 November 2016 (UTC)

:i think you lost track of parens. the definition is not what you describe here, and is identical to the pseudocode.[[User:Krisztián Pintér|Krisztián Pintér]] ([[User talk:Krisztián Pintér|talk]]) 23:52, 5 November 2016 (UTC)


== Please add check algorithm for clients receiving the message and HMAC ==
I understand that clients will have the public key associated to the private key used for signing prior to receiving the message and HMAC.
The validation must then check that the HMAC match some sort of operation using the message and the public key as input.
 What's the exact algorithm?  <!-- Template:Unsigned IP --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/13.94.145.70|13.94.145.70]] ([[User talk:13.94.145.70#top|talk]]) 08:31, 17 August 2017 (UTC)</small> <!--Autosigned by SineBot-->

: don't confuse hash based signatures with hash based MACs. this is not a public key algorithm, there is no public key here. the private key is shared by the two parties. [[User:Krisztián Pintér|Krisztián Pintér]] ([[User talk:Krisztián Pintér|talk]]) 09:25, 17 August 2017 (UTC)


== Sha-1 is mentioned a lot, is it safe? ==
I'm no security expert, but I remember [https://en.wikipedia.org/wiki/SHA-1#The_SHAppening the shappening] and was under the impression that sha-1 is no longer strong enough for Internet encryption. If this is the case, shouldn't this article use ex. sha-256 in its examples and references?  <!-- Template:Unsigned --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Finnjohnsen|Finnjohnsen]] ([[User talk:Finnjohnsen#top|talk]] • [[Special:Contributions/Finnjohnsen|contribs]]) 09:24, 15 February 2018 (UTC)</small> <!--Autosigned by SineBot-->

== External links ==

[[User:Cherkash]] I trimmed the clearly excessive buildup of implementations in multiple languages EXT links per [[WP:EXT]] [[WP:ELNO]]. A couple of reference ones like Python and Java are useful, but bitbucket.org for Picolisp obviously isn't, in keeping with other articles and [[WP:CODE]], where advised to use LiteratePrograms or Rosetta Code if needed to cover lots of implementations. <span class="vcard"><span class="fn">[[User:Widefox|Widefox]]</span>; [[User talk:Widefox|talk]]</span> 11:29, 14 December 2018 (UTC)

:{{u|Widefox}}. My concern is that this choice of which languages to leave and which to remove, is fairly arbitrary, and while it's probably dictated by your personal preferences, others' preferences may be quite different – so if you insist on trimming the list down (not sure why, but ok), I would suggest to retain more languages. [[User:Cherkash|cherkash]] ([[User talk:Cherkash|talk]]) 12:10, 14 December 2018 (UTC)

::Ultimately any finite list will be arbitrary which also applies to 100, 10, or 1 items yes. But, instead of guessing about other editor's motivations, I suggest you check what languages are used for teaching, or other metrics such as [[TIOBE index]] [https://www.tiobe.com/tiobe-index/] 1. Java 2. C 3. Python. There was no C link. Those two EXT links also are from reference implementations, rather than pastbin / bitbucket, so I hope you agree it's both considered in language and quality of source, and in keeping with other articles - random example [[Quicksort]] which has no (zero) code links in the EXT. Keep up the good work, regards <span class="vcard"><span class="fn">[[User:Widefox|Widefox]]</span>; [[User talk:Widefox|talk]]</span> 12:21, 14 December 2018 (UTC)

:::{{u|Widefox}}: There actually was a C implementation. I've just added it back. [[User:Cherkash|cherkash]] ([[User talk:Cherkash|talk]]) 00:03, 18 December 2018 (UTC)
:::: OK, I'm corrected. It's entirely possible I'd just thought C less educational and not remembered that. (Python replacing Java in graduate teaching is what I actually considered rather than TIOBE, and covered both). https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/crypto/hmac.c may be an alternative at half the code (caveat: kernel C). Not sure if you've noticed that the Java link is misleading - it's not to the implementation? <span class="vcard"><span class="fn">[[User:Widefox|Widefox]]</span>; [[User talk:Widefox|talk]]</span> 01:48, 18 December 2018 (UTC)
:::: Yes, my edit summary was just a couple of implementations. I was surprised that Rosetta Code didn't have code, no idea how much code is in Wikibooks per [[WP:CODE]] but https://en.wikibooks.org/wiki/Cryptography/Hashes doesn't. (the Python link like the Java isn't to the implementation, but to using the builtin, but I think it does link through to the implementation.) <span class="vcard"><span class="fn">[[User:Widefox|Widefox]]</span>; [[User talk:Widefox|talk]]</span> 01:59, 18 December 2018 (UTC)

::{{u|Cherkash}} How about an Implementations section like some others have, then they can be refs? <span class="vcard"><span class="fn">[[User:Widefox|Widefox]]</span>; [[User talk:Widefox|talk]]</span> 15:50, 15 December 2018 (UTC)
:::I don't mind. Feel free to implement it that way if it makes sense to you. [[User:Cherkash|cherkash]] ([[User talk:Cherkash|talk]]) 00:03, 18 December 2018 (UTC)

== Kitar aplicasion ==

Kitar la aplicasion [[Special:Contributions/2806:103E:23:5AC0:E027:CF36:D618:4286|2806:103E:23:5AC0:E027:CF36:D618:4286]] ([[User talk:2806:103E:23:5AC0:E027:CF36:D618:4286|talk]]) 06:45, 29 January 2023 (UTC)

:@ [[Special:Contributions/177.239.39.199|177.239.39.199]] ([[User talk:177.239.39.199|talk]]) 08:07, 26 April 2023 (UTC)

== Possible Typo ==
Possible typo in the section that says "For example, SHA-256 operates on 512-bit blocks. The size of the output of HMAC is the same as that of the underlying hash function (e.g., 256 and 512 bits in the case of SHA-256 and SHA3-512, respectively), although it can be truncated if desired." I think SHA-256 operates on 256-bit blocks, not 512, as the paragraph itself later implies. [[User:Metacosm|Metacosm]] ([[User talk:Metacosm|talk]]) 10:41, 21 March 2023 (UTC)

:No, 512 bits is the correct block size for SHA-256. [[User:Yawkat|Yawkat]] ([[User talk:Yawkat|talk]]) 19:35, 28 March 2023 (UTC)

== Quantum computing risks ==
A discussion as to the safety of HMAC encrypted data relative to future quantum computer attacks is needed.

:HMAC security reduces to the security of the underlying hash function. If that hash function is vulnerable to quantum computer attacks, HMAC may be too. However most hash functions used in practice (such as the SHA family) are not particularly vulnerable. [[User:Yawkat|Yawkat]] ([[User talk:Yawkat|talk]]) 11:13, 7 September 2023 (UTC)

:Thanks. [[User:Countercheck|Countercheck]] ([[User talk:Countercheck|talk]]) 18:49, 5 December 2023 (UTC)
::Hlow [[Special:Contributions/143.44.164.13|143.44.164.13]] ([[User talk:143.44.164.13|talk]]) 00:17, 17 December 2023 (UTC)
:::@Umerhuse [[Special:Contributions/196.191.156.148|196.191.156.148]] ([[User talk:196.191.156.148|talk]]) 13:09, 13 September 2024 (UTC)
::::0944320003 [[Special:Contributions/196.191.156.148|196.191.156.148]] ([[User talk:196.191.156.148|talk]]) 13:11, 13 September 2024 (UTC)