This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||
|
There's a conflict between accuracy and NPOV in how we present An-Ping's "analysis", and I'd be interested in ideas on how to resolve it. An-Ping's "analysis" is indeed garbage, and anyone sufficiently expert who reads his paper will be able to verify that (in so far as they're able to get through his impenetrable language). But because we have to take an NPOV stance, we'll give those who come to Wikipedia the impression that there's some sort of big unresolved question mark over Salsa20, when all there is is one nutter talking nonsense. There must be a fair way we can present the verifiable facts so as not to leave people with this misapprehension. — ciphergoth 10:06, 8 October 2005 (UTC)
I don't think the description of salsa20 as a prf is quite correct. Its indistinguishability depends on some assumptions about the input distribution, e.g. that the key is random and the hash function input comes from the expansion function. Maybe the individual functions salsa20_{k,v}(n) could be described as prf's on n, i.e. k is a parameter selecting from a family of functions, not a function input. Bernstein has mentioned that you can't use salsa20 as a general purpose 512 bit hash function. Phr
I've removed An-Ping's attacks from here. There has to come a point where someone's commentary on a thing is not notable enough to go in the article on that thing. I will restore them if even one cryptographer who has been published in an IACR journal is prepared to publically say that they think there is some worthwhile substance to those papers. — ciphergoth 05:55, 7 September 2006 (UTC)
http://sasc.crypto.rub.de/files/sasc2007_039.pdf says:
There is a link on the Salsa20 page to a page for the ChaCha crypto suite. But that page seems to be missing, and a redirect back to the Salsa20 page is done. That is, a user that wants to read more about ChaCha ends up where he/she started.
194.237.142.17 ( talk) 11:51, 14 June 2010 (UTC)
See (among others) http://www.ecrypt.eu.org/documents/D.SYM.10-v1.pdf, page 10.
Useurandom ( talk) 12:22, 6 April 2014 (UTC)
Attribution # 2 is for a Latin dance article: "Jean-Philippe Aumasson, Simon Fischer, Shahram Khazaei, Willi Meier, and Christian Rechberger, New Features of Latin Dances". It is apparently supposed to refer to:
I propose to rename this article Salsa20 and ChaCha, since it covers both. Any objections?-- agr ( talk) 15:21, 24 November 2014 (UTC)
User:intgr suggests: "Per LEAD I think it's fine to mention ChaCha as a separate sentence in the lead..." I can live with that and have added one. Also added a ref about Google's use of ChaCha. Perhaps that is enough reason for a separate article on ChaCha. -- agr ( talk) 01:26, 4 December 2014 (UTC)
Chacha20 is now way more popular than Salsa20. It was adopted by Google. It's supported by Chrome, Firefox. It's part of TLS 1.3. It's in newer version of Open SSL. The article should primarily focus on Chacha20 with Salsa20 as sub section. It should also be renamed to Chacha20 OneGuy ( talk) 16:20, 17 January 2017 (UTC)
The IETF modified Bernstein's algorithm for use in TLS. The CFRG approved the changes. Documenting the interoperability problems is important for implementers and other parties interested in the technical details of the algorithm.
The issue was raise on both the [Linux] Kernel Crypto mailing list and the IETF's TLS Working Group mailing list. It was suggested the IETF change their algorithm name to "TLS-ChaCha20" or similar to aid in disambiguation. The IETF declined, arguing [sic], "We published the algorithm as RFC 7905. Within the context of the RFC the name is correct".
As someone who experienced the interoperability problems, it would have been great to have the information at my fingertips instead of searching mailing lists archives for the cause of the break.
I reverted Claw of Slime's revert to the original documenting of the interoperability problem. Claw of Slime gave no reasons for the revert. — Preceding unsigned comment added by Noloader ( talk • contribs)
This section needs some clarification.
Normally in a stream cipher you want to be able to go from step n to step n-1 deterministically, as that makes it much more unlikely that you will end up with a short loop, as any such loop would have to go through the initial state. It also makes it easy to detect a loop for that reason. So I do not understand that section. Tuntable ( talk) 07:30, 16 December 2018 (UTC)
The text currently states:
An implementation reference for ChaCha20 has been published in RFC 7539...
...and then...
In 2018, RFC 7539 was obsoleted by RFC 8439
Historically, that's true, however I would suggest that this be reversed. Most people want to know the most current standard, and will stop reading when they get to the first RFC reference. Perhaps:
The current implementation reference for ChaCha20 is published in RFC 8439...
...
ChaCha20 was originally documented as an Internet standard in 2015, as RFC 7539 (now superceded by RFC 8439).
Davidfinnie ( talk) 07:30, 18 December 2019 (UTC)
The current XSalsa description is not complete enough. Specifically it does not describe the setup in full and makes it appear like only 128 bits of the nonce is used.
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||
|
There's a conflict between accuracy and NPOV in how we present An-Ping's "analysis", and I'd be interested in ideas on how to resolve it. An-Ping's "analysis" is indeed garbage, and anyone sufficiently expert who reads his paper will be able to verify that (in so far as they're able to get through his impenetrable language). But because we have to take an NPOV stance, we'll give those who come to Wikipedia the impression that there's some sort of big unresolved question mark over Salsa20, when all there is is one nutter talking nonsense. There must be a fair way we can present the verifiable facts so as not to leave people with this misapprehension. — ciphergoth 10:06, 8 October 2005 (UTC)
I don't think the description of salsa20 as a prf is quite correct. Its indistinguishability depends on some assumptions about the input distribution, e.g. that the key is random and the hash function input comes from the expansion function. Maybe the individual functions salsa20_{k,v}(n) could be described as prf's on n, i.e. k is a parameter selecting from a family of functions, not a function input. Bernstein has mentioned that you can't use salsa20 as a general purpose 512 bit hash function. Phr
I've removed An-Ping's attacks from here. There has to come a point where someone's commentary on a thing is not notable enough to go in the article on that thing. I will restore them if even one cryptographer who has been published in an IACR journal is prepared to publically say that they think there is some worthwhile substance to those papers. — ciphergoth 05:55, 7 September 2006 (UTC)
http://sasc.crypto.rub.de/files/sasc2007_039.pdf says:
There is a link on the Salsa20 page to a page for the ChaCha crypto suite. But that page seems to be missing, and a redirect back to the Salsa20 page is done. That is, a user that wants to read more about ChaCha ends up where he/she started.
194.237.142.17 ( talk) 11:51, 14 June 2010 (UTC)
See (among others) http://www.ecrypt.eu.org/documents/D.SYM.10-v1.pdf, page 10.
Useurandom ( talk) 12:22, 6 April 2014 (UTC)
Attribution # 2 is for a Latin dance article: "Jean-Philippe Aumasson, Simon Fischer, Shahram Khazaei, Willi Meier, and Christian Rechberger, New Features of Latin Dances". It is apparently supposed to refer to:
I propose to rename this article Salsa20 and ChaCha, since it covers both. Any objections?-- agr ( talk) 15:21, 24 November 2014 (UTC)
User:intgr suggests: "Per LEAD I think it's fine to mention ChaCha as a separate sentence in the lead..." I can live with that and have added one. Also added a ref about Google's use of ChaCha. Perhaps that is enough reason for a separate article on ChaCha. -- agr ( talk) 01:26, 4 December 2014 (UTC)
Chacha20 is now way more popular than Salsa20. It was adopted by Google. It's supported by Chrome, Firefox. It's part of TLS 1.3. It's in newer version of Open SSL. The article should primarily focus on Chacha20 with Salsa20 as sub section. It should also be renamed to Chacha20 OneGuy ( talk) 16:20, 17 January 2017 (UTC)
The IETF modified Bernstein's algorithm for use in TLS. The CFRG approved the changes. Documenting the interoperability problems is important for implementers and other parties interested in the technical details of the algorithm.
The issue was raise on both the [Linux] Kernel Crypto mailing list and the IETF's TLS Working Group mailing list. It was suggested the IETF change their algorithm name to "TLS-ChaCha20" or similar to aid in disambiguation. The IETF declined, arguing [sic], "We published the algorithm as RFC 7905. Within the context of the RFC the name is correct".
As someone who experienced the interoperability problems, it would have been great to have the information at my fingertips instead of searching mailing lists archives for the cause of the break.
I reverted Claw of Slime's revert to the original documenting of the interoperability problem. Claw of Slime gave no reasons for the revert. — Preceding unsigned comment added by Noloader ( talk • contribs)
This section needs some clarification.
Normally in a stream cipher you want to be able to go from step n to step n-1 deterministically, as that makes it much more unlikely that you will end up with a short loop, as any such loop would have to go through the initial state. It also makes it easy to detect a loop for that reason. So I do not understand that section. Tuntable ( talk) 07:30, 16 December 2018 (UTC)
The text currently states:
An implementation reference for ChaCha20 has been published in RFC 7539...
...and then...
In 2018, RFC 7539 was obsoleted by RFC 8439
Historically, that's true, however I would suggest that this be reversed. Most people want to know the most current standard, and will stop reading when they get to the first RFC reference. Perhaps:
The current implementation reference for ChaCha20 is published in RFC 8439...
...
ChaCha20 was originally documented as an Internet standard in 2015, as RFC 7539 (now superceded by RFC 8439).
Davidfinnie ( talk) 07:30, 18 December 2019 (UTC)
The current XSalsa description is not complete enough. Specifically it does not describe the setup in full and makes it appear like only 128 bits of the nonce is used.