Talk:SHA-1

message: Is it possible to find two messages that have the same SHA(1 or 2) and MD5 hashes? What is the probability of coming across such a file by chance (compared to that for SHA and MD5 individually)? 58.152.239.68 (talk) 13:49, 27 July 2010 (UTC)
replies: text: My answer probably isn't as clear as you would want it to be, but Wikipedia is not a Q&A site (you might want to try for instance Stack Overflow). But you can have a look at birthday paradox, birthday attack, collision attack. -- intgr [talk] 16:06, 27 July 2010 (UTC)
thread_title:  SHA and MD5 

message: In the pseudo code, how are the words XORed together? XORing a string? Would you just use ASCII values?  — Preceding unsigned comment added by 212.183.128.96 (talk) 12:44, 4 July 2011 (UTC)
replies: text: Bitwise. 84.209.89.214 (talk) 13:02, 21 February 2012 (UTC)
replies: text: XOR is a bitwise operation, which doesn't care what the contents of the bits are, as long as all bit combinations are allowed. Gah4 (talk) 19:13, 5 March 2017 (UTC)

text: FWIW "word" refers to several bytes, usually 4 or 8,  processed as a unit by a microprocessor. 91.148.224.66 (talk) 16:43, 1 October 2022 (UTC)
thread_title:  XOR strings? 

message: I am not a native english speaker, but this does not seem right. Avalanche effect is not *cause*, its name for earlier part of sentence.
"Even a small change in the message will, with overwhelming probability, result in a completely different hash due to the avalanche effect."
I think this should be rewritten as 
"Even a small change in the message will, with overwhelming probability, result in a completely different hash (a.k.a. avalanche effect)." wiki+tomas.rozkov@gmail.com 89.103.132.159 (talk) 10:54, 20 September 2011 (UTC)
replies: text: "due to avalanche effect" can be read either as "caused by avalanche effect" or as "resulting from avalanche effect".  — Preceding unsigned comment added by 84.209.89.214 (talk) 13:15, 21 February 2012 (UTC)
thread_title:  due to avalanche effect ? 

message: For sha1("The quick brown fox jumps over the lazy dog") I get be417768b5c3c5c1d9bcb2e7c119196dd76b5570 which differs from the article. However, for sha1("") I do get the published value of da39a3ee5e6b4b0d3255bfef95601890afd80709. Could someone verify the first two example hashes? 199.29.247.15 (talk) 22:05, 30 April 2012 (UTC)
replies: text: The hashes are expressed in :hexadecimal which uses two characters per eight bits of hash data.  This is much more convenient than writing the hash is "�6�W0ᒦ��>���2"���[E�" (for example).   40 characters is needed to represent 160 bits:  160 bits divided by 8 bits per byte is 20 bytes.  20 bytes is represented by 40 hexadecimal characters.  —EncMstr (talk) 19:27, 6 September 2012 (UTC)
thread_title:  Example Hashes wrong? 

message: While there have been several published theoretical attacks on SHA-1, the last I heard no one has produced a collision, so putting it in the Category Broken Cryptographic Hashes may be premature. At the least, a notable citation saying it is considered broken is needed.--agr (talk) 01:02, 11 June 2012 (UTC)
replies: text: Premature in 2012, but not in 2017. Gah4 (talk) 19:16, 5 March 2017 (UTC)
thread_title:  Broken? 

message: I think there's a typo in the pseudo code.  On page 9 of the FIPS 180-2 document, it says:
:ft  (x,y,z)=Ch(x,y,z=(x^y) xor (~x^z)    0 ≤ t ≤ 19
(Other values for the function continue for t > 19.)
And the pseudocode shows:
:f = (b and c) or ((not b) and d)
Shouldn't that or, be an xor?
:f = (b and c) xor ((not b) and d)
140.101.84.1 (talk) 17:38, 26 October 2012 (UTC)
replies: text: It does not matter. They are both the same function. 178.195.225.28 (talk) 18:02, 26 October 2012 (UTC)
thread_title:  SHA-1 Pseudocode Typo 

message: "The use of plain or salted hashes for password storage is a bad idea, they are not designed for this, and key-derivation algorithms like PBKDF2 or Bcrypt or similar should be used instead." - Is this true? There's no citation for such a qualitative statement, And even if so, does it belong in an article about a specific hash function? I'm no expert so I don't feel qualified to edit the article. Dominic Sayers (talk) 10:06, 4 December 2012 (UTC)
thread_title:  General comment in the article about hash algorithms versus key derivation algorithms 

message: I just had a read of this article and happened to note the section on MS-Office screaming out at me as being irrelevant - many if not most applications can use SHA1 so I don't think the article should contain a section on MS Office's use of SHA1. Alex Harvey (talk) 05:23, 7 January 2013 (UTC)
thread_title:  relevance of MS-office section 

message: "Although no successful attacks have yet been reported on SHA-2, they are algorithmically similar to SHA-1."
The sentence says that no successful hacks have been reported; what is the "they" referred to here? Unsuccessful hacks? (Edit: er, I mean attacks, not hacks.)
--150.101.105.198 (talk) 23:31, 14 March 2013 (UTC)
thread_title:  Phrasing query 

message: The first paragraph contains the statement 
 SHA-2 on the other hand significantly differs from the SHA-1 hash function.
The third paragraph states
  Although no successful attacks have yet been reported on SHA-2, they are algorithmically similar to SHA-1.
How to reconcile the statements ??
* they significantly differ
* they are algorithmically similar  — Preceding unsigned comment added by 173.73.158.94 (talk) 13:13, 8 May 2013 (UTC)
replies: text: I wanted to add the same. Except without 'apparent': DEAR WIKIPEDIANS, your article is fucking stupid. Correct it or stop calling WP an 'encyclopedia'. An 8 year old could write things that make more sense--are you below that age? 5.12.154.157 (talk) 07:04, 1 May 2014 (UTC)
thread_title: Apparent Inconsistency - Relationship of SHA-1, SHA-2 Algorithms

message: Hi, Stépane Manuel, author of the 2^51 attack, removed this claim from the final paper (see here). The best attack is today the one from Stevens (here). Do you have any other information that I may have missed? 
--Dduuhh (talk) 15:52, 22 May 2013 (UTC)
thread_title:  Collision Attack 

message: In the section Comparison of SHA functions, the table lists bitwise functions that include "rot".  The bitwise function article has no mention of "rot".  Now I assume that rot means some form of rotation (covered in the bitwise function article) but which one is it?  Or is it more than one form of rotation?  A simple footnote clarifying the "rot" term would suffice.  99.245.230.104 (talk) 20:46, 30 April 2014 (UTC)
replies: text: It refers to Rotate no carry (Circular shift). I don't know if a footnote is necessary since this is really the standard set of bitwise operations, and I'm not sure what else "rot" could be reasonably confused with. But I have no real objection to someone adding one. Mlkj (talk) 09:04, 29 May 2016 (UTC)
replies: text: Rot is not quite as common as many other bitwise operations. It exists in some computer architectures, where it allows one to use it to build up other operations. Rotate through carry allows for a multiple register shift, for example.  Architectures that include a multiple register shift, such as IBM S/360 and successors, don't have it.  (It might have been added more recently, I can't keep track of all the new instructions.) I suspect that it could use a little documentation. Gah4 (talk) 20:01, 7 January 2018 (UTC)
thread_title:  What is rot? 

message: The performance column only refers to a CPU used, and smacks of Original Research.  Although some might be pedantic, I don't mind.  But these numbers differ from what I see using OpenSSL - I find that SHA-1 is almost as fast as MD5 (within ten or twenty percent, perhaps), but that SHA-256 is substantially (four times?) slower.  Anybody know what algorithms were benchmarked here, or ideally, external references to benchmarks?
Ketil (talk) 06:30, 14 April 2015 (UTC)
replies: text: Oh, I see there was an external link, but from 2009.  Time for an update, perhaps? Ketil (talk) 06:44, 14 April 2015 (UTC)
thread_title:  Performance column in table 

message: I added a footnote, for the benefit of readers years later when the terms are no longer current, explaining that "The SHAppening" is a reference to The Fappening (and, I should have added, Snapchat#The Snappening).  User:Intgr reverted it on the grounds that it lacked a WP:reliable source.  I hadn't included one because, per WP:V, I hadn't expected the statement to be challenged.
The problem is, due (I believe) to a combination of not wanting to be condescending to readers and the unsavoury nature of the nude photo leaks, I haven't managed to track down a source explicitly documenting that fact.
So per the WP:BOLD, revert, discuss cycle, I'd just like to canvas other people's opinions.  Do y'all feel:
# It's not true that it's a deliberate reference to those terms, or at least there's a reasonable chance it's not.  (E.g. it might be a reference to The Happening (2008 film) instead.)
# It is a deliberate reference, but that fact isn't WP:notable enough to be worth mentioning at all.
# It would be worth mentioning if we could find a WP:RS, but if we can't, it should be omitted per policy.
# It is worth mentioning.  (FWIW, User:Intgr has expressed a willingness to be persuaded by consensus here to drop the challenge.)
Personally, I think it's very marginally notable (which is why I put it in a footnote and not the main text), but in a spirit of inclusionism, might be informative to a non-native English speaker or future reader when the terms have faded from people's awareness.
71.41.210.146 (talk) 09:31, 27 October 2015 (UTC)
replies: text: The discussion between OP and me is at User talk:71.41.210.146#Your edits to SHA-1. -- intgr [talk] 10:09, 27 October 2015 (UTC)
thread_title:  Document SHAppening/Fappening/Snappening name relationship? 

message: The section "Comparison of SHA functions" is indicating that collisions for SHA-1 have been found. As far as I understand the quoted source this is only true for the compression function within SHA-1. No two inputs for SHA-1 have been found (yet) that produce the same hash value. --KommX (talk) 09:06, 15 December 2015 (UTC)
replies: text: Thanks! You are correct, as per the source: "freestart collisions do not directly lead to actual collisions for SHA-1". The table is now hidden away in a separate template page, that's why editors watching the article probably didn't notice this IP address edit. -- intgr [talk] 09:23, 15 December 2015 (UTC)
replies: text: I agree no collisions have been found for SHA1, AIUI the attach has been demonstrated by attacking the compression function only which is not the same as finding a collision. The reference seems clear about this. I edited the template to no collisions found and included the SHAppening cost estimate to give indication of near term risks of finding collision with explanation that less than 80 is not a good representation of none. My template edit has been reverted and I don't see any good reason for this. I think it should be reverted back to my version or something better unless someone has good reason to support "<80" crandles (talk) 10:12, 16 December 2015 (UTC)
replies: text: Should the template have security bits in one column and security information in a separate column? crandles (talk) 10:36, 16 December 2015 (UTC)
thread_title:  Collisions not yet found (Dec 2015) 

message: Revision control systems such as Git and Mercurial use SHA-1 not for security but for ensuring that the data has not changed due to accidental corruption. 
Am I the only one who thinks this is nonsense? When you sign a git commit, what really is signed is the SHA-1 id of the commit, thus the security clearly relies on SHA-1 not being broken.
  However Git does not require the second preimage resistance of SHA-1 as a security feature, since it will always prefer to keep the earliest version of an object in case of collision, preventing an attacker from surreptitiously overwriting files.
This is only true as long as you pulled the commit in question first from a trusted source. But this is not always the case, for example when using Gittorrent. Even worse seems to be the situation when a malicious actor is able to get commits merged upstream. Then the security not only depends on second-preimage resistance of SHA-1 but also on collision resistance.
O.mangold (talk) 11:11, 16 August 2016 (UTC)
thread_title:  Revision control 

message: How is "sha" pronounced?  — Preceding unsigned comment added by 72.37.140.38 (talk) 13:51, 29 September 2016 (UTC)
thread_title:  Pronounciation 

message: Re : To me, "announced an attack" could refer to mathematically proving that a collision is feasible, which had already been done several years ago, without actually committing the processing resources to do it. Furthermore, the article collision attack clearly shows that the phrase can be used to refer to just finding a collision, whether or not the collision was used for an "advantage". Smyth (talk) 14:29, 5 March 2017 (UTC)
replies: text: See if anyone else wants to say, one way or the other.  I was thinking in terms of a physical attack.  (Country X) attacked (country Y) usually doesn't mean that they just collected enough guns and ammo, and even went to live rounds practicing, but that they actually used them in the country.  But maybe the analogy isn't right. It was really close when I decided to do the rv, and maybe others will add to the discussion.  Thanks. Gah4 (talk) 17:11, 5 March 2017 (UTC)

text: OK, for now I reverted the change.  Unlike countries, there can be an attack against SHA-1 vs. an attack using SHA-1.  This distinction isn't so easy to make in words.  As in the paper, one could make two copies of a document, for example with different monetary values.  Verifying using SHA-1 would allow one to cheat using the second document.  As far as I know, that hasn't happened.  The form of the collision documents makes detection fairly easy, though, if one decides to check.  Gah4 (talk) 20:00, 5 March 2017 (UTC)
thread_title:  "Announced an attack" vs "performed an attack" 

message: There seems to be something against linking to SHA-1 calculators, but if it could be done in Javascript, it could be done from this page.
Not that JS is a very convenient language for it, but it is nice for embedded web pages, without linking to somewhere else. Gah4 (talk) 21:54, 17 May 2017 (UTC)
thread_title:  Javascript 

message: There is a comment that some browsers will stop accepting SHA-1 certificates in 2017.  Since it is now 2018, this should be known.  Did they, or didn't they?  Gah4 (talk) 20:03, 7 January 2018 (UTC)
thread_title:  2017 

message: Not sure if it's quite notable enough to mention it, but there is a "hardened" SHA1 hash function that produces identical SHA1 hashes in almost all cases (2^-90 chance of different hash), except when it detects collision attempts occurring. https://github.com/cr-marcstevens/sha1collisiondetection
Apparently this is now on the mainline git (from v2.13) so if you were to put the SHAttered pdf files into git, it would not cause any issues.
If this sees wider adoption it would certainly be worth mentioning in the article. --Nanite (talk) 16:11, 5 August 2018 (UTC)
thread_title:  Hardened SHA1 

message: A few days ago I added coverage of the Leurent-Peyrin attack based on skimming the paper in question and referenced papers. One particular sentence I wrote is "This method is also capable of finding chosen-prefix collisions in the MD5 function, but at a complexity of 246.3 does not surpass the prior best available method at a theoretical level (239), though potentially at a practical level (≤249)." This was based on the belief that references to MD5 attacks with a specific block count referred to basing the search for solutions on a given number of blocks there is information for, making smaller numbers of blocks more difficult to solve theoretically than larger numbers (as reflected in the complexity for 3-block solutions and general solutions). But now I'm doubting this assumption, thinking they were referring to hashing messages of that number of blocks length, where shorter messages are much easier to analyze to find collisions for than longer messages (though that doesn't really explain why the attack against a 3-block message would take longer than the theoretical attack in general); if true, the claim that the Leurent-Peyrin attack is more practical than the prior best attack is completely wrong.
Justin.olbrantz (talk) 10:11, 18 May 2019 (UTC)
thread_title:  Request for Review in Leurent-Peyrin Attack Section 

message: I have just published a (the?) second public pair of colliding files. https://privacylog.blogspot.com/2019/12/the-second-sha-collision.html Thought you might be interested Full Decent (talk) 06:33, 31 December 2019 (UTC)
replies: text: Right in time for it to still be in 2019, I see. "Processing power used: none. No brute force processing was necessary to generate these two files based on the other files above." Which other files were these based on? BernardoSulzbach (talk) 16:15, 31 December 2019 (UTC)

text: This is not new -- the same 320 byte vectors were used to win the Bitcoin SHA1 collision challenge, back in 2017. (See 'sigscript' here https://www.blockchain.com/btc/tx/8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc ). I'd link to the bitcointalk thread but that site is blacklisted on wikipedia. --Nanite (talk) 23:44, 1 January 2020 (UTC)

text: All you did was to take the first 320 bytes of the two files of Stevens et al! As is clear from their paper, you can put whatever you want after those 320 bytes, so long as you put the same thing in both files. You just left that part out! Big deal. Eric Kvaalen (talk) 08:36, 23 February 2020 (UTC)
thread_title:  Second attack 

message: The SHA-1 article claims 2015, but the SHA-3 article claims 2016. 85.230.7.52 (talk) 16:41, 30 November 2022 (UTC)
replies: text: I wonder if the Data integrity section rather should be put here in Talk instead. Feilretter2468 (talk) 20:59, 16 December 2022 (UTC)
thread_title:  When was SHA-3 first published? 

message: Looks like someone modified the page from Rivest to Guinness. Not sure if there's other fake edits too Silversplash (talk) 05:21, 13 July 2023 (UTC)
thread_title:  Edit needs to be reversed