Talk:SHA-1/Archive 1

message: In the "comparison" section, the primitive operations listed include "rot" and "shr".  If this is rotation (i.e. left bit shift) and shift-right, then these abbreviations should, I think, be clearer.  If they're something else ... then that should be clearer, too.  --Jim Mahoney (talk) 14:42, 28 April 2009 (UTC)
thread_title:  rot? shr? 

message: (80 000/24)/7 = 476.190476190476.. Slightly more than a year.
Has such itanium2-based supercomputers even existed for that long???
:The computer had 256 processors running in parallel, so you'll have to divide the time by that number. Fredrik | talk 23:38, 7 Apr 2005 (UTC)
replies: text: Which gives a number slightly less than two days of continuous running assuming that such a multi-core network has no loss of efficiency. That said, the cost of such a supercomputer would be rather large. --I (talk) 06:15, 28 January 2009 (UTC)
thread_title:  80 000 CPU hours?! 

message: This article is about five or six different variants of SHA, which is fine, but we could probably do with a slightly more general name. Suggestions include:
* SHA
* Secure Hash Algorithm
* SHA family
* Secure Hash Algorithm family
— Matt 07:50, 4 Aug 2004 (UTC)
replies: text: Matt, One problem will be that people will have only heard of (or read about) SHA or SHA-1 or something. Perhaps a forest of redirects? ww 20:48, 4 Aug 2004 (UTC)
replies: text:  Oh certainly (moving, of course, automatically creates a redirect from the old location anyway). I think SHA might be best, as it's short. — Matt 12:15, 5 Aug 2004 (UTC)
replies: text: The problem with SHA is that it will very likely end up being a disambiguation page, as there are other things it can stand for (e.g., the Society for Historical Archaeology, which is currently the first Google hit for SHA). So Secure Hash Algorithm seems like a better option. --Zundark 13:02, 5 Aug 2004 (UTC)
replies: text:  Good point; any nay-sayers to Secure Hash Algorithm? — Matt 13:34, 5 Aug 2004 (UTC)
replies: text: I suppose the best choice would be SHA family as there are several, including the insecure SHA-0. Or maybe Secure Hash Algorithm Family, maybe. ww 18:32, 6 Aug 2004 (UTC)
replies: text:  OK, I've gone with SHA family, and made a few redirects from the other suggestions. — Matt 13:26, 13 Aug 2004 (UTC)
thread_title:  Naming 

message: There seems to be an error in the Pseudocode:
The assignments:
:a = h0
:b = h1
:c = h2
:d = h3
:e = h4
must be done for every 512 bit chunk, not only at initial startup of the algorithm.
At least that's what I had to change when implementing this algorithm before it produced the same results as the SHA-1 checksum tool I already had. 11:25, 10 Aug 2004 80.129.56.5
:You're exactly right...  I fixed it.  You can fix it too, you know =^_^= -- Myria 05:38, 2 Nov 2004 (UTC)
thread_title:  Pseudocode error 

message: Hi folks, do you find it useful to have additional testvectors for the SHA-2 variants on the page?
I don't want to add them until I have heard some opinions.
Jonelo 08:04, 6 Oct 2004 (UTC)
thread_title:  SHA-2 hashes 

message: The article really doesn't explain why there are so many SHA versions, is SHA-512 better (but slower to do) then SHA-1?  If someone knows, please add it in. --ShaunMacPherson 12:52, 6 Nov 2004 (UTC)
replies: text: (I'll try and check this then add it to the article): As I understand it, I believe that the different SHA versions are used to correspond to different block cipher key lengths, so that all the components in a cryptosystem provide the same level of security. Say you have a block cipher with an n-bit key size, then to match that security with a hash function that you use in the same system, you need a hash size of 2n, because even a perfect hash function is subject to birthday attacks with a complexity corresponding to the square root of the hash size — i.e. n if the hash size is 2n. So SHA-1 has 160-bits, which matches Skipjack (cipher) (keysize 80 bits). SHA-256, SHA-384 and SHA-512 match AES with its possible key sizes of 128, 192 and 256 bits. SHA-224 was introduced to match the security of two-key Triple DES (2×56=112-bit key). — Matt 17:58, 6 Nov 2004 (UTC)
thread_title:  Explanation 

message: Does anyone have any insight into why one of the arguments of the rotations in the compression function is a factor of the other, and why the 30-bit left rotation (taken as a 2-bit right rotation) divides the 32-bit word size?  I don't have time to analyze it in depth at the moment, but it seems under casual inspection that you would get better mixing if the arguments were coprime...  User:Inkling 10:51, 17 Jan 2005 (UTC)
thread_title:  Design questions 

message: An anonymous user has kindly contributed pseudocode for SHA-256, in addition to the pseudocode for SHA-1. This is great to have, but I'm concerned that the article is a little over-burdened with pseudo-code at present. We don't want to lose this information, so perhaps we could move the SHA-256 description elsewhere: maybe a SHA-256 pseudocode page, or onto WikiSource...what do people think? — Matt Crypto 19:18, 14 Mar 2005 (UTC)
thread_title:  Extra SHA-pseudocode 

message: I'd like to know more about how these functions are used and why they are important. Is it true that you run one of these algorithms over some text and have a code that cannot be converted back to the text? How is that useful? What are some common applications? 
If this is is explained elsewhere perhaps you could link me in the right direction.
:How about the cryptographic hash function article, and the hash function article linked from there? Lunkwill 07:38, 8 September 2005 (UTC)
thread_title:  QUESTION 

message: This line in the code (both versions) is unclear.
"append length of message, in bits as 64-bit big-endian integer to message"
Does it refer to the original message length, or the message length after it has been padded and had the length added? I assume it is probably the original length. If so can someone change it to "appeng length of original message, in bits...."?
:I thought it was pretty obvious when I wrote it.  Yes, it's the length of the original message.  What do others think about this request?  -- Myria 04:30, 26 September 2005 (UTC)
replies: text: I think "...append original length..." is better than "...append length...". Nahaj 12:24, 28 October 2005 (UTC)
thread_title:  Pseudocode clarification 

message: Taken from the article 25/09/05:
"SHA-0 and SHA-1 produce a 160-bit digest"
If it's 160 bit, what does that mean ? does it mean that a input like "Red juice" has 160 bit diffrent outputs?
Taken from the article 25/09/05:
"from a message with a maximum size of 2^64 bits"
so i cant digest a message above 2^64 bit (2,3 exabytes) ?
Taken from the article 25/09/05:
"At CRYPTO 98, two French researchers presented an attack on SHA-0 (Chabaud and Joux, 1998): collisions can be found with complexity 2^61; less than the 2^80 for an ideal hash function of the same size."
Where does 2^80 come from ? SHA0 is 160 bit, that would be 2^160 right ?
:160 bit output means that the function mashes, stretches and squishes any input string into a 160-bit (20 byte) long output string.  Correct, the hash functions won't work on messages longer than 2^64 bits (which, I might add, are rather hard to come by...).  And 2^80 comes from the birthday paradox. Lunkwill 20:58, 25 September 2005 (UTC)
thread_title:  Numbers, cant figure them out. 

message: There are machines where a rotate or shift by N eats N cycles.
Obviously the rotate left 30 could be replaced by a rotate right 2, speeding it up on such machines, and not slowing it on any machines I'm aware of. (: And there is a Validated implementation that does the rotate right 2 :)
How much optimization is worth doing on pseudo code? (comment by Nahaj, tagged by Myria)
* I personally draw the line at the point at which it ought to be the compiler's responsibility.  The optimizations to the F-functions are universal - they improve the calculation on all systems, or at least grant a theoretical advantage (such as the associativity of addition).  No reasonable compiler could look at the original F-functions and immediately deduce the rather odd changes needed to remove a boolean operation.  However, using the symmetry of the rotate commands is very obvious and is easy to program a compiler to do. -- Myria 07:16, 28 October 2005 (UTC)
thread_title:  Optimizations 

message: I'm assuming the SHA-1 collisions were done without adding a salt to the original message. Does anyone know how much a salt of a given size would add to the difficulty of creating a collision? e.g. would adding a 16 bit salt to the original message increase the best collision algorithm iterations from 2 to the 63 power to maybe 2 to the 66 power? -- Jweiler 19:24, 10 January 2006
:These answers are based on the attack they found in 2005. But note that I don't know how the new optimised attack works, but I heard it is similar. Also note that I am not a cryptanalyst so I might be totally wrong about this.
:Short answer: No, in some usage cases adding a salt does not make the attack harder. But under some circumstances a salt can stop the attack entirely. It depends on when and where the salt is added.
:Long answer: As I understood it the attack they found in 2005 on SHA-1 is similar to the MD5 attack from the same year. That means they are changing some bytes in a special position close to the beginning of the message. That is, the attack method changes the same position, no matter what message you are working with at the moment. That means if the attacker creates the message, then he can change bytes in that position to create two messages that collide. 
:Due to the nature of hashes if you append something to the end of two colliding messages you will get a new hash, but the same hash for both messages. So still a collision. Thus appending the same salt to both messages will keep the collision and thus not protect you.
:If you prepend anything to the two messages the position of the changed bytes will move. That means the attack won't work at all. So the two messages will not collide any more. So if you insert a salt or a message header or whatever to the very beginning of the message then you are sort of ok. At least against the 2005 attack.
:However, if the attacker at the time he creates the two messages knows what header you are going to prepend to the message he can take that into account when he makes the message pair. That is, he will add the same header and then manipulate bytes in the proper position to find colliding messages. (And then of course remove the header before he gives you the messages.)
:So this means that you must create an unpredictable random salt AFTER the messages are given/uploaded/sent to you by the attacker. And prepend it to the message, not append it.
:Another approach is to prepend a fixed header that is so long that it runs over the bytes that the attacker needs to manipulate to do the attack. Thus he can not manipulate those bytes. And the header can be well known and public.
:But note, now that they found two attacks it is likely that they will find more attacks. For instance, I think there are many more positions further into the message where you can manipulate bytes. So these "fixes" are not even worth the trouble. You better use something better instead. I think the wise thing is to do like the TLS standard does: Use two different hashes and combine them. That approach is probably still secure even if there are some attacks against both the used hashes.
:Oh, but of course salts are a good thing for many other reasons.
:--David Göthberg 19:48, 30 October 2006 (UTC)
thread_title:  How much does adding salt increase security 

message: There are 370 implementations of SHA-1 according to the article.  We can't list them all, and the most notable ones are the ones we don't need to link to because they are bundled with Perl, Python, Java and so forth.  The only reasonable way to avoid this section growing without bound is to remove it altogether.
I think the same goes for "web-based tools" which I also removed, but perhaps I'm wrong? — ciphergoth 21:40, 19 February 2006 (UTC)
replies: text: It would be nice if someone could find an online directory that lists the web-based tools, and link to that instead. While the section was getting quite cluttered, I did find the links useful. ~MDD4696 01:38, 20 February 2006 (UTC)
replies: text: I don't see any reason why we can't arbitrarily pick one or two good implementations and web based tools. It's a natural next step for people reading the article. Lunkwill 08:07, 20 February 2006 (UTC)
replies: text: I think that would have some advantages, but it's very hard to be arbitrary here.  When someone wants to add their pet implementation to the list, what reason can we give for reverting it? — ciphergoth 09:28, 20 February 2006 (UTC)
replies: text: See WP:EL. We can't link arbitrarily, and there are too many good online hashers available to list them all. ~MDD4696 23:44, 20 February 2006 (UTC)

text: The thing is, Wikipedia isn't a repository for any data that might be useful to someone; it's first and foremost an encyclopedia. An infinitely better place to list and maintain web links is the Open Directory Project; it's simply outside our scope. — Matt Crypto 19:13, 24 February 2006 (UTC)
replies: text:  I suspect that the 370 number comes from NIST's list of validated implementation at the time (Up to 450 now... although the removed implimentations list leaned to unvalidated versions for some reason.  There are at least two open source implementations in NIST's list, so I'd expect that if you were going to list one or two they would be good candidates. (Disclaimer, I'm the author of one.)  (My bias towards validated ones are because a number of flat out missimplementations exists on the net.) My personal opinion is that the article shouldn't have an implementations section, it should just link to  NIST's list, since they have a legal mandate to keep it up to date...  any list in the article is going to be rapidly out of date.Nahaj 02:24, 5 April 2006 (UTC)
thread_title:  Removed "implementations" section 

message: Can I derive proprietary code from the psuedo code on this page? I am concerned that the Free Document License won't allow it, but what is psuedo code for if not to be derived from? 168.215.177.66 21:37, 6 July 2006 (UTC)
thread_title:  Licensing of the pseudocode 

message: I am a cryptography novice, but wonder given the recent break of SHA1 and break of MD5 if the security of both can be improved by combining them?
For example, if the function SHA1(data+MD5(data)) were used (i.e. append the MD5 of the data to the data, and take the SHA1 of the combination), would it be a lot harder to find collisions?  My (rudimentary) understanding of the collision finding process is that to break the algorithm a data stream to fill the internal state with specific data is desired - and that the complexity of finding this data stream depends on the size of the internal state.  Thus by effectively adding MD5 internal state onto SHA1 this problem would become much harder.
This would be practical in the following (common) situation : you have to interface with a legacy application that does not support newer hash functions (e.g. SHA-2 family), and yet you are worried about the potential for a SHA-1 break (you don't use MD5, because breaking that is far easier according to the above quoted articles).  A good example would be MySQL, which has internal functions for MD5 and SHA1, while stating in the manual "Exploits for the MD5 and SHA-1 algorithms have become known. You may wish to consider using one of the other encryption functions described in this section instead" - without providing any other cryptographic hash functions in version 5.0.
I assume (possibly naively) that the combination will be at least as strong as the outer function. Is this a reasonable assumption? Second, I intuitively think (which probably means it is wrong) that the combination will be stronger than the outer function. Any thoughts?
Shamus Husheer - s dot husheer at cantab dot net - 22:46, 30 August 2006
:I've asked the gurus at sci.crypt under the thread "Probably naive question - SHA1 + MD5 combination" on 31 Aug 2006, and had the following answer:
:(1) See http://ai.stanford.edu/~xb/crypto06b/index.html Boneh and Boyen's paper `On the impossiblity of efficiently combining collision resistant hash functions', which shows that if both functions are good hash functions, then combining them in this way is not useful,
:(2) The only "at least as strong as" construction I [Kristian Gjøsteen] know of is "g(m) = h_1(m) || ... || h_n(m)" [appending one to the other].  If you find a collision in this hash function, you've also found a collision for all the constituent hash functions.  Kristian also suggested a way to more practically break the SHA1(data+MD5(data)) function in the discussion.
:Hopefully this helps anyone who has come searching for the same information.
:Shamus - 06:59, 4 September 2006
::Hi Shamus. I am not a cryptanalyst or so but have some knowledge. To me the method you suggest to combine two hashes seems pretty good: SHA1(data + MD5(data) ). But there is a better variant of it, see below. Another well known method is SHA1(data) XOR MD5(data). Of course, the most secure one is to concatenate the two hashes: SHA1(data) + MD5(data). However that gives a rather big hash and some systems don't use the whole result but instead just chop off enough bytes they want. Thus it is nice if all bits in the result depends on both hashes. So the two first methods here seems better for normal use. For the XOR method there is a slight problem that MD5 gives a 16 byte hash while SHA1 gives a 20 byte hash. If a program then chops of and uses the wrong end of the result then not all bits depend on both hashes. But that can be handled by reusing 4 bytes of the MD5 to XOR over the other part of the SHA1. I have seen many other suggested methods too. Here I list some of them including the three above:
::hash = SHA1( data + MD5(data) )
::hash = SHA1(data) XOR MD5(data)
::longhash = SHA1(data) + MD5(data)
::tmp = MD5(data), hash = SHA1(tmp + data + tmp)
::hash = MD5(SHA1(data)) XOR SHA1(MD5(data))
::hash = SHA1(MD5(data) + SHA1(data))
::"+" here means concatenation.
::Oh, and shamus and every one else, if you like to talk more about crypto come to the IRC chat #crypto on irc.freenode.net.
::--David Göthberg 22:27, 21 September 2006 (UTC)
thread_title:  Combining SHA1 / MD5 

message: I just wanted to thank everyone worked on this page because it's probably one of the bests I've found on the wiki.
In particular, I needed to implement a checking routine for file integrity (non critical performance) and obviously started from CRC and Md5. I was very surprised SHA-512 to be "so easy" to implement (I'm not in cryptography at all) so I guess I'll give it a try.
As another note, maybe it would be good to note other methods to be "somewhat surpassed"... i bounced on many links before getting this one. I would do this myself, but I'm not really sure what's the best way to do it.
81.211.227.153 20:11, 21 September 2006 (UTC)
thread_title:  Great job! 

message: Hi, I've got what is probably a basic question: Can you key SHA hashes?  That is, using a secret key of some sort in the hash algorithm so that no one can calculate the hash in question without knowing the key used in the hashing? (That might be what the initializations are for in the pseudocode.) -- Joebeone (Talk) 16:15, 14 October 2006 (UTC)
replies: text: I've poked around some more and it appears that hash functions are generally unkeyed... sorry for the clutter. -- Joebeone (Talk) 18:06, 14 October 2006 (UTC)
replies: text: Don't be sorry, it is a good question. Yes, you can key any cryptographic hash function and that turns it into a message authentication code (MAC). The most popular (and also very secure) method to do that is the HMAC method. Usually when we send or store messages we do MAC them and thus make it "impossible" for an attacker to tamper with (change) our messages without us detecting it. --David Göthberg 05:32, 16 October 2006 (UTC)
thread_title:  Are SHA hashes keyed? 

message: Hi,
in the pseudocode for SHA-2, someone changed "for i from 16 to 63" to "for i from 16 to 63ccv" again (I had removed "ccv"); before reverting it, does anyone think that it has a meaning? —Gennaro Prota•Talk 23:23, 26 November 2006 (UTC)
thread_title:  ccv? 

message: Hi again,
would anyone object to delinking all year-only dates in the article? I don't think the links add anything relevant in this context (see Partial dates). —Gennaro Prota•Talk 06:27, 2 December 2006 (UTC)
thread_title:  Date linking 

message: For all these various tech acryonyms, providing a clue as to the common pronounciation would be helpful.  Eg, for SHA-1, it's /shah-one/ or /shaw-one/ or the like.  Perhaps providing the IPA or whatever the standard is for pronunciation. (I'll defer this to those more knowledgeable of wikipedia standards on the issue.) - Michael (talk|contrib) 02:08, 19 January 2007 (UTC)
replies: text: Good question. How do you guys really pronounce SHA-1 etc in English? I know how we pronounce it in Swedish but not really what the most common way is in English. (In Swedish we spell it out so translated to English that would mean this pronunciation: Ess Eich Ei One. But it is much harder to say that in English.) --David Göthberg 12:40, 28 January 2007 (UTC)
thread_title:  Pronunciation 

message: Professor Xiaoyun Wang, the same person who found the SHA-1 vulnerability in August 2005, has recently published a paper  that appears to make it feasible to find SHA-1 collisions in practice. I don't have the technical understanding to make sense of the paper myself, but perhaps someone else here can read it and update the article appropriately. 71.224.239.10 23:50, 20 January 2007 (UTC)
replies: text: There is an (English) article about the subject. --JVersteeg 10:43, 21 January 2007 (UTC)
replies: text: This article is useless and misleading, it doesn't mention a single relevant detail about the attack itself. -- intgr 15:23, 21 January 2007 (UTC)

text: The paper that you refer to, does not even talk about SHA-1. Rather it shows attaks against MD5, RIPEMD and SHA-0. How is this supposed to show a new SHA-1 vulnerability? The article in epochtimes is so badly written that it is not possible to determine whether they are talking about a new attack or one that has already been published. If there are no other reports of a new attack, then it is probably safe to assume that epochtime is just recycling an old story. 85.2.45.127 21:59, 27 January 2007 (UTC)

text: I've updated the page with my paper explaining the details of Wang's 2^63 attack on SHA-1.  After over 2 years of lack of details about the methods, I decided to figure it out myself from her slides and type it up. Martin.cochran (talk) 23:49, 6 February 2008 (UTC)
thread_title:  New SHA-1 vulnerabilities 

message: The crypto analysis is not exactly a cogent explanation of how the algorithm works. This article says nothing about the actual working of the SHA-1. I think this needs to be included. -Weedrat 09:40, 21 May 2007 (UTC)
replies: text: Did you notice the pseudocode close to the end of the article? It looks good enough to me to actually implement SHA-1. 84.73.231.90 10:25, 21 May 2007 (UTC)
thread_title:  SHA-1 Expansion

message: The introduction describes SHA-1 as "a condensed digital representation...that is, to a high degree of probability, unique for a given input data sequence."  Shouldn't it say "unique *to* a given input..." (i.e. there is likely only a single input that goes with that output) rather than "unique for" (i.e. there likely is only a single output for a given input)?  The current use of "for" says simply that there's just one output for each input, which is true of many mathematical functions...
MacScoop 18:27, 23 May 2007 (UTC)
replies: text: Agreed, sounds better to me, though I am not a native English speaker. -- intgr #%@! 21:11, 23 May 2007 (UTC)
replies: text:  Sounds incorrect to me. Since there are many more possible inputs than outputs it is very likely that for every possible output there exists many inputs mapping to that output. The whole first sentence is incomprehensible. Hash functions are defined as functions for which it is computationally infeasible to invert them and to find collisions (as described later). 84.73.231.90 21:34, 23 May 2007 (UTC)
thread_title:  Basic language question 

message: The draft version of FIPS 180-3 is available at http://csrc.nist.gov/publications/drafts/fips_180-3/draft_fips-180-3_June-08-2007.pdf. he comment period closes on September 10, 2007. Reid Hochstedler 19:11, 2 July 2007 (UTC)
thread_title:  FIPS 180-3 Draft 

message: How do commitment schemes work? They seem handy, but complicated. How do I get a committed identity? ionas68224|talk|contribs|email 11:03, 21 July 2007 (UTC)
thread_title:  Question 

message: Hi. There are probably different links for SHA-1, SHA-2, SHA-512, etc. The problem is, what exactly are those links? The Template:User committed identity gives the link to SHA-1, and the article gives the links to a few, but where are the links to all the SHA websites, say for example where is the link for calculating SHA-512? Can someone list me the links of those websites, and where you got it from? I don't want links to sites other than those used to directly calculate a string into a hash code, so I don't want any sites with info about the SHA websites, I want the actual links themselves. I will also ask this question on the refernce desk. Thanks. ~AH1(TCU) 20:41, 4 October 2007 (UTC)
thread_title:  Where are the links of the different SHA websites? 

message: Is there a specific reason why the TOC is on the right?
It could be considered a minor issue, though when I opened the article, for a second I was like "errrrm... Where's the TOC?" (spatial memory anyone?), then I saw it was on the right, and it just seemed odd.
It's also not underneath the intro, but rather beside it. It seems inconsistent with about every other article I ever saw in WP (and I've been here for years) --W2bh 20:40, 15 November 2007 (UTC)
replies: text: You're right—It should be on the left:  default.  The manual of style suggests right TOC placement for articles where a photo appears at the left (suggested for biographical articles with a right facing headshot).  But there is no such consideration in this article.  —EncMstr 20:47, 15 November 2007 (UTC)
replies: text: I agree. --Morten LJ 09:31, 16 November 2007 (UTC)
thread_title:  TOC on the right? 

message: The sentence "Gilbert and Handschuh (2003) have studied the newer variants and found no weaknesses" has a fact tag.  It looks like it's referring to a paper, I did a quick search, and I think this might be it:
:Henri Gilbert, Helena Handschuh: Security Analysis of SHA-256 and Sisters. Selected Areas in Cryptography 2003: 175-193.
Anyway, I did a quick google search and didn't find any other 2003 papers by them.  Can someone with more knowledge on the topic who maybe is able to access the paper take a look and see?  It'd be nice to get rid of that fact tag.  Thanks, 4.21.209.231 (talk) 04:19, 1 January 2008 (UTC)
thread_title:  This might be it... 

message: I suggest that sha1sum be merged into this article, under an "implementations" section, or similar.
--Jerome Potts (talk) 19:01, 22 March 2008 (UTC)
replies: text: I'm not opposed to this in theory, but the content should be seriously revised upon the merge.  most of the content is meaningless uninformative or redundant, especially in the context of a subsection of this article.  The revised content should also make an effort to establish that this is one of the most common tools used for calculating sha1 hashes at the execution level (a presumption on my part).  Similar merges could be possibly proposed for md5sum and chksum.  Those are my thoughts anyway. -Verdatum (talk) 20:37, 23 April 2008 (UTC)
replies: text: I don't think a merger is appropriate. This article discusses a Unix utility for calculating SHA1 check sums. There are similar utilities for other operating systems and many other programs that calculate SHA hashes. The main article on SHA is not a suitable place for all this information.--agr (talk) 17:25, 20 August 2008 (UTC)
thread_title:  Merger proposal 

message: Is "rotfl" a binary operation? I'd suggest to revise the alg/operation table :(  —Preceding unsigned comment added by 81.182.160.76 (talk) 07:08, 7 April 2008 (UTC)
thread_title:  Operations 

message: I'm only vaguely familiar with the subject matter so I hesitate to edit, but I think the first sentence under Cryptanalysis, "For a hash function which violates the first criterion listed above..." should have read, "For a hash function that does NOT violate the first criterion above..."
Here is where I'm on shakier ground, but does that statement not apply to all hashes, whether they violate the first criterion or not? I think 2^L is an upper bound, isn't it? A hash function that violates the first criterion (do they have names? if so we should use them instead of "first criterion" etc...) allows you to find a message for a given hash value in less than 2^L.
If that's correct, then the first sentence should read, "For a hash function which meets the first criterion listed above, finding a message that corresponds to a given message digest requires a brute force search in 2^L..."
Eshafto (talk) 15:34, 23 May 2008 (UTC)
thread_title:  Unclear/incorrect verbage 

message: The "Collision" column is not clear at all; what is this supposed to represent? Surely not whether the hashing function has collisions or not, since that is a given from /being/ a hashing function. Some more commentary or a better header would be good. W (talk) 10:35, 2 September 2008 (UTC)
replies: text: It means whether an attack or an actual collision sample has ever been published. I renamed the column header to "Collisions found", is this any better? -- intgr [talk] 16:57, 3 September 2008 (UTC)
thread_title:  Comparison of SHA functions table 

message: Under "Cryptanalysis and Validation," the phrase "the first criterion listed above" refers to some text which is no longer present in the article (see the intro paragraphs in this revision: http://en.wikipedia.org/w/index.php?title=SHA_hash_functions&oldid=213893308). The paragraph should be rewritten in light of this missing antecedent.
131.179.192.130 (talk) 20:12, 14 October 2008 (UTC)
thread_title:  Bit-rotted text 

message: I see this article was tagged as "fancruft" briefly -- as containing details almost nobody cares about.  Interesting -- the most detailed part I can see is the pseudocode, which matches what we have for other important algorithms (e.g., RC4).  
The history, analysis info, and so forth seem relevant to many real-world engineers using crypto, and isn't collected in one place under a free-content license.  It's also useful as context for anyone trying to understand the current NIST hash competition, the 2008 MD5 crack, and future changes in the SSL protocol.  We could perhaps improve the article by removing redundancy, but most of what's here is useful to real people.  It's a little analogous to the math articles describing obscure (to non-mathematicians) functions, theorems, and equations: not for everyone but clearly valuable to a real audience.
And the most boring sentence probably provides as much value to humanity as the Lost episode descriptions that seemingly *aren't* fancruft. :)  
(Incidentally, I'd be for deleting articles about some ciphers that were published and then forgotten.  "Published" doesn't mean "notable.")
I'm certainly a crypto fanboy, though.  Any other perspectives?  Particular sections people think don't help? 67.119.195.43 (talk) 22:10, 2 February 2009 (UTC)
thread_title:  Your opinion: is this useless fancruft? 

message: see paper at: http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf  —Preceding unsigned comment added by 87.145.199.71 (talk) 19:15, 29 April 2009 (UTC)
replies: text: This paper has since been withdrawn because the authors state that their 252 estimation was wrong. -- intgr [talk] 17:47, 31 March 2010 (UTC)
thread_title:  sha-1 collision down to 2^52 now claims Macquarie University and Qualcomm, Australia 

message: I removed the following unsourced "critique": "It is well known that if a hash of bit length m is produced from messages of bit length n, then on average $2^(n-m)$ messages will share the same hash key, and consequently for a small fixed value of m, say, 1024, and messages with length of more than 1024/8=128 characters, collisions are going to be extremely likely." It is certainly true that the set of all 1024 bit messages, if SHA1 hashed, would produce large numbers of collisions. All cryptographic hashes promise is that finding two different messages with the same hash is very difficult. Also note that if every human on Earth sends one message a second, that amounts to about 2^58 messages a year, not enough to raise the probability of a single 128-bit hash collision above 50%.--agr (talk) 23:15, 27 October 2009 (UTC)
thread_title:  Critique removal 

message: In the 11:23, 2 October 2009 update, the pseudo code was reformatted in such a way that the loops are no longer clear when they occur.  The previous version used indentation to show when the loops occur, now it's left up to the reader to determine.  I would like to change it back, but want to see if others agree that it is a problem. Xylaan (talk) 19:12, 6 November 2009 (UTC)
thread_title:  Pseudocode formatting 

message: A new hash standard, SHA-3, is currently under development – the function will be selected via an open competition running between fall 2008 and 2012.
"fall", is that autumn? Of which hemisphere? Southern or Northern? Is it during the months of "fall 2008", and then again during the months of "fall 2012"? Jesselong (talk) 16:47, 12 January 2010 (UTC)
replies: text: Good catch.  Too many people forget about the whole round-planet thing!  Also distracting is the use of future tense for something that started in the past.  CosineKitty (talk) 20:48, 12 January 2010 (UTC)

text: I just made a revision based on your comments.  What do you think about it?  CosineKitty (talk) 21:07, 12 January 2010 (UTC)
replies: text: Awesome, thanks for that, looks great!  —Preceding unsigned comment added by Jesselong (talk • contribs) 11:10, 14 January 2010 (UTC)
thread_title:  New competition dates