Talk:Salsa20

message: 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)
replies: text: I think the way around this sort of thing is to emphasise that noone has accepted his claims, and that experts have expressed criticism or skepticism about the claims. I tweaked a couple of words, and I think it gives the right sort of impression now, but still keeps an NPOV. — Matt Crypto 11:13, 8 October 2005 (UTC)
thread_title: An-Ping

message: 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
:A PRF is not a function; it's a keyed family of functions.  For Salsa20 that family is not exactly what you specify; it's Salsa20_k(v, i).  Otherwise it would not be claiming any security against an attacker who knows the nonce, which wouldn't be much use.  As it is, it claims security against chosen-nonce attacks, a very important class of attacks that break lots of eSTREAM candidates.  To me the sentence
::a pseudorandom function based on 32-bit addition, bitwise addition (XOR) and rotation operations, which maps a 256-bit key, a 64-bit nonce, and a 64-bit stream position to a 512-bit output
:implies that the PRF is Salsa20_k(v, i) but perhaps it could be made clearer? — ciphergoth 09:00, 19 February 2006 (UTC)
replies: text: Yes it could be clearer.  I thought a PRF was a single function (like an HMAC instance with a fixed but unknown key) that can't be distinguished from a random function, so HMAC is a family of PRF's, AES is a family of PRP's, etc.  Maybe I've got the definition mixed up.  I've been wanting to write articles describing PRF and PRP, so I better check that. Phr 06:26, 20 February 2006 (UTC)
thread_title:  prf description 

message: 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)
thread_title:  An-Ping redux 

message: http://sasc.crypto.rub.de/files/sasc2007_039.pdf says:
: In this example, the computational complexity becomes approximately 2255
: (= 2245× 210 ×  2 × 4/8) times of Salsa20/8 encryption and it is lower than 2256
: of exhaustive key search.
:5 Conclusion
:This paper presented a cryptanalysis of the Salsa20 stream cipher proposed
:in 2005. We discovered a significant differential probability bias in the Salsa20
:round 4 internal state, yielded by assigning single bit differences to the initial
:vector which may be freely chosen by an attacker.
:Further more, we have used this bias to attack Salsa20/r (5 ≤ r ≤ 8). Using
:our method, Salsa20/7 with a 128-bit secret key and Salsa20/8 with a 256-bit
:secret key were broken using less computational complexity than required for
:an exhaustive key search. The amount of data needed for both cryptanalyses
:is theoretically 211.37 keystream pairs. Our method of attack uses a new technique
:of approximating polynomials of addition, and succeeds in the reducing
:the computational complexity compared to previous methods.
:Finally, Bernstein proposed Salsa20/8 and Salsa20/12 as models paying consideration
:to implementation, but faced with our attack the security of Salsa20/8
:is insufficient, and even considering implementation, a model of at least 12 rounds
:should be used. However, the attack in this paper does not directly threaten the
:security of the full-round Salsa20/20 specification, although caution is still required
:regarding the issue of whether there is a sufficient margin of safety.  —Preceding unsigned comment added by 71.41.210.146 (talk) 15:00, 13 December 2007 (UTC)
thread_title:  Differential Cryptanalysis of Sala20/8 

message: 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)
thread_title:  ChaCha and redirect 

message: See (among others) http://www.ecrypt.eu.org/documents/D.SYM.10-v1.pdf, page 10.
Useurandom (talk) 12:22, 6 April 2014 (UTC)
thread_title:  Number of rounds - author suggests salsa20/20, eSTREAM suggests salsa20/12 

message: 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:
:As of 2012, there are no published attacks on Salsa20/12 or the full Salsa20/20; the best attack known[2] breaks 8 of the 12 or 20 rounds.  — Preceding unsigned comment added by Krudler5 (talk • contribs) 13:00, 3 October 2014 (UTC)
thread_title:  Incorrect attribution 

message: 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)
thread_title: Rename it to Chacha20

message: 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) 
: While everything you wrote may be correct, in Wikipedia we expect statements to be verifiable. That is, if you add material that might be challenged by someone, you need to provide sources. I'm afraid Claw of Slime was correct to revert this edit; the edit summary says "meed references".
:While mailing list posts etc are sometimes used and accepted as sources, it's even better if you could find published sources, see WP:RS if you want the details. -- intgr [talk] 07:19, 7 August 2017 (UTC)
replies: text: Anyway that's a moot point now,  already updated it. -- intgr [talk] 19:49, 7 August 2017 (UTC)
thread_title:  ChaCha20 and non-interoperability 

message: 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)
thread_title:  Invertivle 

message: 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)
thread_title:  Suggesting to reverse RFC references to most current first, perhaps with history included later 

message: 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.
* It does not mention HSalsa20 by name, though it alludes to it by describing "without the final addition", "128-bit nonce". This is page 5 of xsalsa-20110204.pdf.
* There is no description of the first mixing of the 256 bits from HSalsa20. This is page 5-6 of xsalsa-20110204.pdf, starting with "XSalsa20/r produces a 512-bit output block starting from a 512-bit input block".
* There is no description of the final setup of the XSalsa20 initial state, which finally explains how the last 64 bits of the nonce is used. This is page 6 of xsalsa-20110204.pdf, starting with "It then builds a new 512-bit input block".
Artoria2e5 🌉 07:06, 8 May 2024 (UTC)
thread_title:  XSalsa description