Template talk:Comparison of SHA functions

table has no explanation of the colors it uses

[edit]

The table has no explanation of the colors it uses. Can someone please fix this? term: telephony — Preceding unsigned comment added by 75.141.118.68 (talk) 03:16, 28 March 2017 (UTC)[reply]

talk:192.2.198.23 — Preceding unsigned comment added by 75.141.118.68 (talk) 03:37, 28 March 2017 (UTC)[reply]

SHA-1 Collision

[edit]

Marc Stevens et al. note that they located a collision in the SHA-1 compression function, but did not find the external input necessary to produce the internal state necessary (and evidently does not plan to, as he has defended his thesis now). Should the table reflect the same status as it would if a full collision was found? — Preceding unsigned comment added by 98.249.69.197 (talk) 00:19, 10 November 2015 (UTC)[reply]

No, I don't think the SHA-1 status should be changed in the table until actual colliding inputs are found. It's still possible that there's an undiscovered or unpublished mistake in Stevens's work, or maybe practical constraints make the attack infeasible. Publishing of actual colliding inputs is the ultimate verification, this is the same criteria/color scheme I used in the hash function security summary article. -- intgr [talk] 13:17, 15 April 2016 (UTC)[reply]

"Capacity against length extension attacks" column in the table

[edit]

Who wrote this? Who or what provided the values for the bits of "capacity against length extension attacks"?

Can someone provide references for these, please.

2A02:C7D:1AAD:BB00:CD0:93D0:5A62:E2DF (talk) 19:12, 17 September 2017 (UTC)[reply]

Please see Talk:SHA-2#SHA-2 is vulnerable to the length extension attacks?. I think that this is at best highly misleading, as nobody uses the non-HMAC construct that is described in the lead of the Length extension attack article. In cryptography there are oh so many ways to misuse a primitive, it would be very strange to base security claims for a primitive on such misuse. I suggest to remove the column altogether, as the detailed explanation ("just don't do it") is non-numerical. Pinging non-anonymous editors involved: @ReaderCritic, Vecr, and Rtc:. Dimawik (talk) 08:01, 30 July 2025 (UTC)[reply]
It is a base security claim.
See the Flickr error.
Duong, Thai; Rizzo, Juliano (2009-09-28)
https://dl.packetstormsecurity.net/0909-advisories/flickr_api_signature_forgery.pdf
pp. 4
"This attack works on all Merkle-Damgård hash such as MD0-MD5 and SHA0-SHA2." That includes SHA-2's SHA-256 and SHA-2's SHA-512. SHA-224 has negligible resistance, and SHA-384 has some. All SHA-3 is safe. Look up how the resistant hashes throw away state. Vecr (talk) 23:23, 30 July 2025 (UTC)[reply]
  • Original image
    Original image
  • Using ECB allows patterns to be easily discerned
    Using ECB allows patterns to be easily discerned
  • Modes other than ECB result in pseudo-randomness
    Modes other than ECB result in pseudo-randomness
  • This appears to describe a bug in Flicker, no more. The hash should not be used this way, HMAC is there for a reason. RFC 2104 got out in 1997, the article by Bellare et al. preceded it by a year. There is no excuse for any security implementation to ignore HMAC 12 years later. Is there a solid source that states, in some form, ours - very strong - statement here (essentially, "widely used hash functions have no security against a particular attack")? By "solid" I mean cryptographers of Bellare's caliber stating so in a journal article/conference publication. If no such statement have been made, we might consider deleting the column, IMHO. For example, the use of the AES-ECB mode to encrypt limited-value data (results are above) is not a sign of low security of either ECB or (especially) AES, but an example of a wrong software design, a (hypothetical) column with 0 in the AES/ECB security for an "image attack resistance" would confuse readers. Our article, Block cipher mode of operation#ECB instead correctly states, more or less, "just don't do it". I would argue that a similar statement, along the lines of HMAC#Design principles is useful next to the template inclusions. Dimawik (talk) 01:24, 31 July 2025 (UTC)[reply]

    cpb

    [edit]

    The "tool tip" explaining cpb does not explain cpb.