![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The presentation of the block permutation differs from the reference in presentation. The mapping between bits in the state and the matrix is specified on page 8 as follows:
"The mapping between the bits of s and those of a is s[w(5y + x) + z] = a[x][y][z]."
The wikipedia page basically switches the second and first coordinate:
"Let a[i][j][k] be bit (i×5 + j)×w + k of the input,[..]"
The following description of the algorithm is correct, but confusing for those comparing reference, implementation guidelines and other sources. I think it would be helpful to stay closer to the reference in this regard, especially as I don't see an advantage in presenting it with the coordinates switch.
If there is no sign of disagreement, I will come back and change the section accordingly. — Preceding unsigned comment added by Deejaydarvin ( talk • contribs) 10:12, 25 June 2013 (UTC)
The result of the proposal was moved. -- BDD ( talk) 19:19, 11 October 2012 (UTC) ( non-admin closure)
Keccak → SHA-3 – Now that Keccak is the official SHA-3 algorithm, this article should be moved to SHA-3 (and perhaps recreate Keccak as a redirect to SHA-3 if it's felt warranted.) moof ( talk) 16:56, 4 October 2012 (UTC)
Update: SHA-3 was added to the Secure Hash Standard by NIST today. ( http://www.nist.gov/customcf/get_pdf.cfm?pub_id=919060) — Preceding unsigned comment added by Rbrightwell ( talk • contribs) 17:50, 5 August 2015 (UTC)
SHA-3 standard does not not exist yet: Secure Hash Standard (SHS) is not yet updated. Only thing which is 100 % sure is that SHA-3 will be based on Keccak. This fact was pointed by the Keccak authors at FOSDEM 2013 ( https://fosdem.org/2013/schedule/event/security_keccak/).
news on finalization https://docs.google.com/file/d/0BzRYQSHuuMYOQXdHWkRiZXlURVE 80.98.89.22 ( talk) 22:04, 27 August 2013 (UTC)
Can we delete rhash sample data? SHA-3 not standardized and the trickle of changes during the standardization process is changing the test values; moreover the current text suggest they're from a non-standard rhash utility. — Preceding unsigned comment added by 216.113.160.81 ( talk) 00:52, 6 December 2014 (UTC)
I think it could be reasonable to remove the RHASH algorithm. I changed it, because when researching the algorithm, I found this example only matched the FIPS standard and the competition output on an empty string. The original block simply gave the examples as if there was no difference. I could give sample data to prove the point of the small change for the FIPS standard, but I'm not aware of it being published, so I hesitate to do so. I think that is why the RHASH algorithm has become so popular, because they have a far greater list of example inputs and outputs than the FIPS examples that consist of a few bits. I've already seen the RHASH algorithm popping up in other applications, probably because it is easier to test. It may be useful to instead have a section that shows the difference between the standards, the problem still exists however that the only published input example that is the same between all three is the empty string, and that just happens to be the worst example to use. It will be interesting if early adopters of SHA-3 mostly get it wrong, simply because RHASH got it wrong. The fact that it is wrong seems to be important. 74.200.48.5 ( talk) 14:35, 1 May 2015 (UTC)
in the light of recent documents, i suggest keccak and sha-3 to be separated. rationale: in this document http://keccak.noekeon.org/NoteSoftwareInterface.pdf authors suggest a wide array of uses for keccak outside the scope of a hash function. also there are different usage modes, namely the overwrite mode absorbing (as opposed to the xor method), reduced rounds for first Keccak-f in special cases like keyed mode, and sakura tree hashing with special padding. as of now, it is impossible to incorporate these into wikipedia, because they are not related to SHA-3, and there is no keccak article. 178.21.48.247 ( talk) 14:32, 26 July 2013 (UTC)
more: CAESAR contestants ketje http://competitions.cr.yp.to/round1/ketjev1.pdf and keyak http://competitions.cr.yp.to/round1/keyakv1.pdf are based on smaller state and reduced round keccak. (i am 178.21.48.247 above) Krisztián Pintér ( talk) 12:34, 19 March 2014 (UTC)
now what? now we have the SHAKE's as well. where to put it? Krisztián Pintér ( talk) 18:59, 7 May 2014 (UTC)
The name SHA-3 seems to be rather restrictive to SHA3-{224,256,384,512}, while there is much more than that: the SHAKE's indeed, but also the new functions standardized by NIST in SP 800-185 (cSHAKE, KMAC, etc.), Ketje, Keyak, the STROBE protocol... So I think the current redirect does not help in showing the bigger picture, which would be a nice added value of this Wikipedia page. 62.147.254.143 ( talk) 03:04, 4 August 2017 (UTC)
on the apropos of User:Samboy adding kanga, i would like to mention kravatte here to be added to the keccak zoo. all this would have been solved by having a keccak article and sha3 redirecting to a section of it. Krisztián Pintér ( talk) 14:11, 20 August 2018 (UTC)
added a little bit of info about the fuss that is going on. sadly, due to US government inaptness, i can't cite the djb mail from the NIST mailing list, it is not available. — Preceding unsigned comment added by 80.98.89.22 ( talk) 16:53, 13 October 2013 (UTC)
I've never heard of "Paul Crowley", and he doesn't have a Wikipedia article (in contrast to e.g. Bruce Schneier who is cited in the same section). A Google search for "Paul Crowley" doesn't turn up any cryptologist (there's an Irish football player, and a lawyer that comes on the first page). The citation itself seems to be a blog site. I'm being bold and removing the statement, particularly considering the controversy around the weakening of Keccak by NIST. We need to be careful who is being cited and their weight in the cryptologic community. Please cite who he is before adding him back. 83.248.146.73 ( talk) 14:16, 16 February 2014 (UTC)
I think there is a little problem on the item three of the section "References" because it is showing the follow string in red
"|first1= missing |last1= in Authors list (help)"
I'm sorry, but I don't know how to fix it, so, I'm reporting here.
Regards,
Lp.vitor ( talk) 22:39, 21 October 2014 (UTC)
For the previous hash algorithms, there have been free implementations available under the BSD license. Is there such an implementation available for SHA-3 already? Schily ( talk) 15:56, 18 August 2015 (UTC)
i suggest the deletion of the tweaks session, or merging it into the history section. now that the standard is out, tweaks does not seem all that relevant. Krisztián Pintér ( talk) 08:51, 8 September 2015 (UTC)
I think deletion is not good, but I support moving it to the history. -- mafutrct ( talk) 10:59, 8 October 2015 (UTC)
AFAIK the padding is 1...0...1 for Keccak, 011...0...1 for SHA3 and 11111...0...1 for SHAKE. — Preceding unsigned comment added by 95.111.59.55 ( talk) 12:13, 11 October 2015 (UTC)
I have a question: The article now says that a maximum or r-1 0's are added, but given that there is a 1 in front and a 1 at the end, and that the total number of bits should be r, it seems to me that the maximal number of 0's is r-2 instead of r-1. This should occur when padding the empty message.
I made an implementation of SHA3, and ran SHA3-224(""), and I get: d46b7676dc1570d228520b1b9dd5caa1319ec425e2775ec399f96fb7.
I've noticed that there's no in-line citation in the examples section, so I doubt it's correct.
Do we have a reference implementation we can defer to? — Preceding unsigned comment added by Dannyniu ( talk • contribs) 12:20, 14 May 2016 (UTC)
I think some technical details may be worth mentioning. I can draft sentences on this, but finding reference may be over the wall for me.
Because of birthday attack, the collision resistance of any hash function is always half of that of its pre-image resistance. As NIST was considering the necessity of twice the pre-image resistance than that minimal target security level, many in the field (cite Daniel J. Bernstein, Bruce Schneier, quotes here) have raised concern over the move. While favorable in performance, the tweak would cause SHA3 to have significantly less pre-image resistance than their SHA2 counterparts. — Preceding unsigned comment added by Dannyniu ( talk • contribs) 09:22, 31 May 2017 (UTC)
Also, there's the trivia that quantum computers can pre-image a sponge function in capacity/3 compared to outlen/2 on true random oracles. Dannyniu ( talk) 09:30, 31 May 2017 (UTC)
I added the following to the lede:
This was removed by User:Krisztián Pintér with the comment "removing irrelevant paragraph from lead. speed section suffices." I don't think so. The topic begs the question why hardly anybody is using SHA-3. The lede should give an explanation and give the facts. I don't think that this crucially relevant information should be buried deep down in the article. -- rtc ( talk) 12:05, 17 July 2017 (UTC)
[outdent]
I’ve been following this dicussion today. The Wikipedia policy is pretty clear: We should only put things in the lede which reliable sources say about the topic in question. If reliable sources give extensive coverage to SHA-3’s software performance, then we put that there. But, that means a reliable source: A book about the topic, or a peer reviewed paper which gives an overview of modern cryptographic hash functions. Keep in mind that Adam Langley’s blog is not a reliable source as per our guidelines on what is and is not a reliable source. To say that SHA-3 is slow just because some people on some random Reddit discussion board feel it’s slow is not a reliable source; remember, the Pizzagate conspiracy theory started as a thread in Reddit. Since reliable sources do not give extensive discussion about SHA-3 being slower in software (in fact, they say SHA-3 is incredibly fast when implemented in hardware), to put any discussion based on a Reddit or Ycombinator thread violates WP:UNDUE. Samboy ( talk) 02:12, 18 July 2017 (UTC)
References
Since changes to this section have resulted in heated discussion from one editor, here are the latest changes I have made to the speed section (in bold)
a) Theoretically secure, for two reasons:
The first reason is because, once we get at 256 bits of security (or, likewise 128 bits of security against an imaginary quantum computer), the numbers just don’t make sense in the real world. Since that one editor didn’t like my own back of the envelope calculation of making every atom in the solar system a brute force cryptographic calculating computer four times as fast as my core i7-7600U, which would require over 350,000 years to brute force 256 bits, let me quote Applied Cryptography to give an idea of how hard it would be to brute force only 128 bits:
For 256 bits to be brute forced with a quantum computer, imagine this same algae bloom — but this time with each algae cell somehow being a quantum computer.
The other reason is that a cryptographic sponge would have to be indistinguishable from a random permutation to actually get more than 256 bits of security. Any cryptographic weakness in Keccak’s round function, no matter how small, would make it so having a huge capacity like 1024 bits won’t actually give us 512 bits of security (remember, with a sponge, the theoretical security level is the capacity in bits divided by two).
b) fewer bits
“bits” is a countable noun, not a mass noun, so it is grammatically correct to say “fewer bits”, not “less bits.”
Samboy ( talk) 07:21, 24 July 2017 (UTC)
It seems that the table on the security against quantum attacks is not correct for the SHAKEs. IMHO, the resistance should be:
62.147.254.143 ( talk) 21:18, 30 July 2017 (UTC)
Just implemented it now. 62.147.254.143 ( talk) 02:58, 4 August 2017 (UTC)
Keccak is a family of cryptographic algorithms (built around the cryptographic sponge or another construction and the Keccak permutation with a chosen number of rounds), some of which have been standardized as "SHA-3".
This article is currently unnecessarily confusing because of having SHA-3 as the main topic, instead of just a subsection or two being devoted to SHA-3.
I propose changing this page so as to
If you do not agree with some details, take this as just a general direction. Although an amount of work would be necessary for additions to the article (like Farfalle), that stuff must (because it would currently be off-topic) be postponed. What is needed to do as soon as possible is rename and reorganize the existing article so as to emphasize the Keccak permutation, and de-emphasize the SHA-3 and cSHAKE functions (which are simply instances of the sponge constructed with the Keccak permutation); because the current structure is unnatural and confusing. 77.216.237.71 ( talk) 16:39, 7 January 2019 (UTC)
Looking at the tables in https://keccak.team/sw_performance.html, it seems that the software speed figures in this page are somewhat behind the latest implementations on Skylake. And the statement "12.6 cpb on a typical x86-64-based machine" looks outdated. Do you confirm? DemusHok ( talk) 15:00, 19 October 2019 (UTC)
@ Krisztián Pintér: Thanks for adding Kravatte to the page!
Actually, I found the sentences "The original instance was found weak. An update was released in 2018 to address these issues." somewhat misleading. We indeed initially posted a weak instance on ePrint. However, we fixed it and Kravatte as published in ToSC 2017 is fine: The attacks by Guo et al. and Chaigneau et al. are on the earlier versions, see Appendix A for the version history. As for the 2018 update, that does not concern Kravatte itself but the modes on top of it (SANE and SANSE vs SAE and SIV). -- Gilles Van Assche ( talk) 14:27, 2 November 2019 (UTC)
I've marked this (particularly the last sentence) as failed verification:
I think it needs rewriting, but I don't understand what it's trying to say about MD and SHA functions. SHA explicitly allows for truncation of the hash, and the concept that "every bit of output be as strong as the last" doesn't make any cryptographic sense to me. The closest the source contains is A.2:
But this is a drawback of XOFs, not a criticism of MD and SHA functions. As a result, I've reverted User:SilverbackNet's revert of my edit. If anyone can explain a different interpretation of either the article or the source, please let me know before I spend time rewriting. Ms7821 ( talk) 21:52, 22 December 2021 (UTC)
In the description of the differences between Keccak and SHA3 there is this text: "12 + ℓ to 12 + 2ℓ" where nowwhere in the article is mentioned what ℓ refers to... Can somebody knowing what this means please add this?-- 2A02:8070:6394:7A00:A553:6D74:9F04:1A8D ( talk) 13:52, 3 April 2022 (UTC)
The lede says "The purpose of SHA-3 is that it can be directly substituted for SHA-2 in current applications if necessary, ..." while the History section says "SHA-3 is not meant to replace SHA-2, as no significant attack on SHA-2 has been demonstrated". Those statements might both be true in some technical sense, but they sound somewhat contradictory. I want to "harmonize" these two phrases, but I am not sure what is best. Any thoughts? David10244 ( talk) 13:41, 24 December 2022 (UTC)
The term permutation is indeed confusing, but the fact of confusion does not belong here and should be dealt with somewhere else (I have started a discussion at Talk:Substitution-permutation network#Meaning of "permutation"). The regular (bit) permutation is frequently called "transposition" to avoid this confusion. Dimawik ( talk) 23:32, 9 October 2023 (UTC)
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The presentation of the block permutation differs from the reference in presentation. The mapping between bits in the state and the matrix is specified on page 8 as follows:
"The mapping between the bits of s and those of a is s[w(5y + x) + z] = a[x][y][z]."
The wikipedia page basically switches the second and first coordinate:
"Let a[i][j][k] be bit (i×5 + j)×w + k of the input,[..]"
The following description of the algorithm is correct, but confusing for those comparing reference, implementation guidelines and other sources. I think it would be helpful to stay closer to the reference in this regard, especially as I don't see an advantage in presenting it with the coordinates switch.
If there is no sign of disagreement, I will come back and change the section accordingly. — Preceding unsigned comment added by Deejaydarvin ( talk • contribs) 10:12, 25 June 2013 (UTC)
The result of the proposal was moved. -- BDD ( talk) 19:19, 11 October 2012 (UTC) ( non-admin closure)
Keccak → SHA-3 – Now that Keccak is the official SHA-3 algorithm, this article should be moved to SHA-3 (and perhaps recreate Keccak as a redirect to SHA-3 if it's felt warranted.) moof ( talk) 16:56, 4 October 2012 (UTC)
Update: SHA-3 was added to the Secure Hash Standard by NIST today. ( http://www.nist.gov/customcf/get_pdf.cfm?pub_id=919060) — Preceding unsigned comment added by Rbrightwell ( talk • contribs) 17:50, 5 August 2015 (UTC)
SHA-3 standard does not not exist yet: Secure Hash Standard (SHS) is not yet updated. Only thing which is 100 % sure is that SHA-3 will be based on Keccak. This fact was pointed by the Keccak authors at FOSDEM 2013 ( https://fosdem.org/2013/schedule/event/security_keccak/).
news on finalization https://docs.google.com/file/d/0BzRYQSHuuMYOQXdHWkRiZXlURVE 80.98.89.22 ( talk) 22:04, 27 August 2013 (UTC)
Can we delete rhash sample data? SHA-3 not standardized and the trickle of changes during the standardization process is changing the test values; moreover the current text suggest they're from a non-standard rhash utility. — Preceding unsigned comment added by 216.113.160.81 ( talk) 00:52, 6 December 2014 (UTC)
I think it could be reasonable to remove the RHASH algorithm. I changed it, because when researching the algorithm, I found this example only matched the FIPS standard and the competition output on an empty string. The original block simply gave the examples as if there was no difference. I could give sample data to prove the point of the small change for the FIPS standard, but I'm not aware of it being published, so I hesitate to do so. I think that is why the RHASH algorithm has become so popular, because they have a far greater list of example inputs and outputs than the FIPS examples that consist of a few bits. I've already seen the RHASH algorithm popping up in other applications, probably because it is easier to test. It may be useful to instead have a section that shows the difference between the standards, the problem still exists however that the only published input example that is the same between all three is the empty string, and that just happens to be the worst example to use. It will be interesting if early adopters of SHA-3 mostly get it wrong, simply because RHASH got it wrong. The fact that it is wrong seems to be important. 74.200.48.5 ( talk) 14:35, 1 May 2015 (UTC)
in the light of recent documents, i suggest keccak and sha-3 to be separated. rationale: in this document http://keccak.noekeon.org/NoteSoftwareInterface.pdf authors suggest a wide array of uses for keccak outside the scope of a hash function. also there are different usage modes, namely the overwrite mode absorbing (as opposed to the xor method), reduced rounds for first Keccak-f in special cases like keyed mode, and sakura tree hashing with special padding. as of now, it is impossible to incorporate these into wikipedia, because they are not related to SHA-3, and there is no keccak article. 178.21.48.247 ( talk) 14:32, 26 July 2013 (UTC)
more: CAESAR contestants ketje http://competitions.cr.yp.to/round1/ketjev1.pdf and keyak http://competitions.cr.yp.to/round1/keyakv1.pdf are based on smaller state and reduced round keccak. (i am 178.21.48.247 above) Krisztián Pintér ( talk) 12:34, 19 March 2014 (UTC)
now what? now we have the SHAKE's as well. where to put it? Krisztián Pintér ( talk) 18:59, 7 May 2014 (UTC)
The name SHA-3 seems to be rather restrictive to SHA3-{224,256,384,512}, while there is much more than that: the SHAKE's indeed, but also the new functions standardized by NIST in SP 800-185 (cSHAKE, KMAC, etc.), Ketje, Keyak, the STROBE protocol... So I think the current redirect does not help in showing the bigger picture, which would be a nice added value of this Wikipedia page. 62.147.254.143 ( talk) 03:04, 4 August 2017 (UTC)
on the apropos of User:Samboy adding kanga, i would like to mention kravatte here to be added to the keccak zoo. all this would have been solved by having a keccak article and sha3 redirecting to a section of it. Krisztián Pintér ( talk) 14:11, 20 August 2018 (UTC)
added a little bit of info about the fuss that is going on. sadly, due to US government inaptness, i can't cite the djb mail from the NIST mailing list, it is not available. — Preceding unsigned comment added by 80.98.89.22 ( talk) 16:53, 13 October 2013 (UTC)
I've never heard of "Paul Crowley", and he doesn't have a Wikipedia article (in contrast to e.g. Bruce Schneier who is cited in the same section). A Google search for "Paul Crowley" doesn't turn up any cryptologist (there's an Irish football player, and a lawyer that comes on the first page). The citation itself seems to be a blog site. I'm being bold and removing the statement, particularly considering the controversy around the weakening of Keccak by NIST. We need to be careful who is being cited and their weight in the cryptologic community. Please cite who he is before adding him back. 83.248.146.73 ( talk) 14:16, 16 February 2014 (UTC)
I think there is a little problem on the item three of the section "References" because it is showing the follow string in red
"|first1= missing |last1= in Authors list (help)"
I'm sorry, but I don't know how to fix it, so, I'm reporting here.
Regards,
Lp.vitor ( talk) 22:39, 21 October 2014 (UTC)
For the previous hash algorithms, there have been free implementations available under the BSD license. Is there such an implementation available for SHA-3 already? Schily ( talk) 15:56, 18 August 2015 (UTC)
i suggest the deletion of the tweaks session, or merging it into the history section. now that the standard is out, tweaks does not seem all that relevant. Krisztián Pintér ( talk) 08:51, 8 September 2015 (UTC)
I think deletion is not good, but I support moving it to the history. -- mafutrct ( talk) 10:59, 8 October 2015 (UTC)
AFAIK the padding is 1...0...1 for Keccak, 011...0...1 for SHA3 and 11111...0...1 for SHAKE. — Preceding unsigned comment added by 95.111.59.55 ( talk) 12:13, 11 October 2015 (UTC)
I have a question: The article now says that a maximum or r-1 0's are added, but given that there is a 1 in front and a 1 at the end, and that the total number of bits should be r, it seems to me that the maximal number of 0's is r-2 instead of r-1. This should occur when padding the empty message.
I made an implementation of SHA3, and ran SHA3-224(""), and I get: d46b7676dc1570d228520b1b9dd5caa1319ec425e2775ec399f96fb7.
I've noticed that there's no in-line citation in the examples section, so I doubt it's correct.
Do we have a reference implementation we can defer to? — Preceding unsigned comment added by Dannyniu ( talk • contribs) 12:20, 14 May 2016 (UTC)
I think some technical details may be worth mentioning. I can draft sentences on this, but finding reference may be over the wall for me.
Because of birthday attack, the collision resistance of any hash function is always half of that of its pre-image resistance. As NIST was considering the necessity of twice the pre-image resistance than that minimal target security level, many in the field (cite Daniel J. Bernstein, Bruce Schneier, quotes here) have raised concern over the move. While favorable in performance, the tweak would cause SHA3 to have significantly less pre-image resistance than their SHA2 counterparts. — Preceding unsigned comment added by Dannyniu ( talk • contribs) 09:22, 31 May 2017 (UTC)
Also, there's the trivia that quantum computers can pre-image a sponge function in capacity/3 compared to outlen/2 on true random oracles. Dannyniu ( talk) 09:30, 31 May 2017 (UTC)
I added the following to the lede:
This was removed by User:Krisztián Pintér with the comment "removing irrelevant paragraph from lead. speed section suffices." I don't think so. The topic begs the question why hardly anybody is using SHA-3. The lede should give an explanation and give the facts. I don't think that this crucially relevant information should be buried deep down in the article. -- rtc ( talk) 12:05, 17 July 2017 (UTC)
[outdent]
I’ve been following this dicussion today. The Wikipedia policy is pretty clear: We should only put things in the lede which reliable sources say about the topic in question. If reliable sources give extensive coverage to SHA-3’s software performance, then we put that there. But, that means a reliable source: A book about the topic, or a peer reviewed paper which gives an overview of modern cryptographic hash functions. Keep in mind that Adam Langley’s blog is not a reliable source as per our guidelines on what is and is not a reliable source. To say that SHA-3 is slow just because some people on some random Reddit discussion board feel it’s slow is not a reliable source; remember, the Pizzagate conspiracy theory started as a thread in Reddit. Since reliable sources do not give extensive discussion about SHA-3 being slower in software (in fact, they say SHA-3 is incredibly fast when implemented in hardware), to put any discussion based on a Reddit or Ycombinator thread violates WP:UNDUE. Samboy ( talk) 02:12, 18 July 2017 (UTC)
References
Since changes to this section have resulted in heated discussion from one editor, here are the latest changes I have made to the speed section (in bold)
a) Theoretically secure, for two reasons:
The first reason is because, once we get at 256 bits of security (or, likewise 128 bits of security against an imaginary quantum computer), the numbers just don’t make sense in the real world. Since that one editor didn’t like my own back of the envelope calculation of making every atom in the solar system a brute force cryptographic calculating computer four times as fast as my core i7-7600U, which would require over 350,000 years to brute force 256 bits, let me quote Applied Cryptography to give an idea of how hard it would be to brute force only 128 bits:
For 256 bits to be brute forced with a quantum computer, imagine this same algae bloom — but this time with each algae cell somehow being a quantum computer.
The other reason is that a cryptographic sponge would have to be indistinguishable from a random permutation to actually get more than 256 bits of security. Any cryptographic weakness in Keccak’s round function, no matter how small, would make it so having a huge capacity like 1024 bits won’t actually give us 512 bits of security (remember, with a sponge, the theoretical security level is the capacity in bits divided by two).
b) fewer bits
“bits” is a countable noun, not a mass noun, so it is grammatically correct to say “fewer bits”, not “less bits.”
Samboy ( talk) 07:21, 24 July 2017 (UTC)
It seems that the table on the security against quantum attacks is not correct for the SHAKEs. IMHO, the resistance should be:
62.147.254.143 ( talk) 21:18, 30 July 2017 (UTC)
Just implemented it now. 62.147.254.143 ( talk) 02:58, 4 August 2017 (UTC)
Keccak is a family of cryptographic algorithms (built around the cryptographic sponge or another construction and the Keccak permutation with a chosen number of rounds), some of which have been standardized as "SHA-3".
This article is currently unnecessarily confusing because of having SHA-3 as the main topic, instead of just a subsection or two being devoted to SHA-3.
I propose changing this page so as to
If you do not agree with some details, take this as just a general direction. Although an amount of work would be necessary for additions to the article (like Farfalle), that stuff must (because it would currently be off-topic) be postponed. What is needed to do as soon as possible is rename and reorganize the existing article so as to emphasize the Keccak permutation, and de-emphasize the SHA-3 and cSHAKE functions (which are simply instances of the sponge constructed with the Keccak permutation); because the current structure is unnatural and confusing. 77.216.237.71 ( talk) 16:39, 7 January 2019 (UTC)
Looking at the tables in https://keccak.team/sw_performance.html, it seems that the software speed figures in this page are somewhat behind the latest implementations on Skylake. And the statement "12.6 cpb on a typical x86-64-based machine" looks outdated. Do you confirm? DemusHok ( talk) 15:00, 19 October 2019 (UTC)
@ Krisztián Pintér: Thanks for adding Kravatte to the page!
Actually, I found the sentences "The original instance was found weak. An update was released in 2018 to address these issues." somewhat misleading. We indeed initially posted a weak instance on ePrint. However, we fixed it and Kravatte as published in ToSC 2017 is fine: The attacks by Guo et al. and Chaigneau et al. are on the earlier versions, see Appendix A for the version history. As for the 2018 update, that does not concern Kravatte itself but the modes on top of it (SANE and SANSE vs SAE and SIV). -- Gilles Van Assche ( talk) 14:27, 2 November 2019 (UTC)
I've marked this (particularly the last sentence) as failed verification:
I think it needs rewriting, but I don't understand what it's trying to say about MD and SHA functions. SHA explicitly allows for truncation of the hash, and the concept that "every bit of output be as strong as the last" doesn't make any cryptographic sense to me. The closest the source contains is A.2:
But this is a drawback of XOFs, not a criticism of MD and SHA functions. As a result, I've reverted User:SilverbackNet's revert of my edit. If anyone can explain a different interpretation of either the article or the source, please let me know before I spend time rewriting. Ms7821 ( talk) 21:52, 22 December 2021 (UTC)
In the description of the differences between Keccak and SHA3 there is this text: "12 + ℓ to 12 + 2ℓ" where nowwhere in the article is mentioned what ℓ refers to... Can somebody knowing what this means please add this?-- 2A02:8070:6394:7A00:A553:6D74:9F04:1A8D ( talk) 13:52, 3 April 2022 (UTC)
The lede says "The purpose of SHA-3 is that it can be directly substituted for SHA-2 in current applications if necessary, ..." while the History section says "SHA-3 is not meant to replace SHA-2, as no significant attack on SHA-2 has been demonstrated". Those statements might both be true in some technical sense, but they sound somewhat contradictory. I want to "harmonize" these two phrases, but I am not sure what is best. Any thoughts? David10244 ( talk) 13:41, 24 December 2022 (UTC)
The term permutation is indeed confusing, but the fact of confusion does not belong here and should be dealt with somewhere else (I have started a discussion at Talk:Substitution-permutation network#Meaning of "permutation"). The regular (bit) permutation is frequently called "transposition" to avoid this confusion. Dimawik ( talk) 23:32, 9 October 2023 (UTC)