Talk:Salsa20

An-Ping

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 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)

prf description

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)

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)

An-Ping redux

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)

Differential Cryptanalysis of Sala20/8

http://sasc.crypto.rub.de/files/sasc2007_039.pdf says:

In this example, the computational complexity becomes approximately 2²⁵⁵

(= 2²⁴⁵× 2¹⁰ × 2 × 4/8) times of Salsa20/8 encryption and it is lower than 2²⁵⁶

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 2^11.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)

ChaCha and redirect

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)

Number of rounds - author suggests salsa20/20, eSTREAM suggests salsa20/12

See (among others) http://www.ecrypt.eu.org/documents/D.SYM.10-v1.pdf, page 10.

Useurandom (talk) 12:22, 6 April 2014 (UTC)

Incorrect attribution

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)

Move to Salsa20 and ChaCha

I propose to rename this article Salsa20 and ChaCha, since it covers both. Any objections?--agr (talk) 15:21, 24 November 2014 (UTC)

@ArnoldReinhold: I oppose, typically Wikipedia articles only cover one primary topic. If the topic has sub-topics, like Salsa20 having a less-known cousin ChaCha, then it's fine to cover that in a sub-section of the article, as before. But don't make it seem like this article has two primary topics. I disagree with your edits to the lead for the same reason. I believe this is supported by WP:PRIMARYTOPIC and WP:PRECISION.

If you think ChaCha is sufficiently important on its own, I think it should be split out into its own article instead. This follows the natural pattern with other articles, like SHA-2 article being split out of of the original SHA-1, as the importance of SHA-2 grew over time. Whether ChaCha is important enough, I don't know. -- intgr [talk] 18:20, 24 November 2014 (UTC)

The article already covered ChaCha, and ChaCha (cipher) redirects to this article. All I did is make the intro fully reflect the article's content, per WP:LEAD. As for your SHA-2 example, SHA-2 is in fact a family of six algorithms, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. There are far greater differences between the members of the SHA 2 family than there is between Salsa20 and ChaCha, which are almost identical in structure and interface, with just a different round function. They share the same author, have similar performance and were crypto-analyzed together. Having separate articles would be almost entirely duplicative. There is nothing in WP:PRIMARYTOPIC or WP:PRECISION that requires separate articles in a situation like this.--agr (talk) 04:02, 25 November 2014 (UTC)

@ArnoldReinhold: I'm sorry, I somehow missed your reply in my watchlist.

• I didn't say PRIMARYTOPIC and PRECISION require a separate article, but they do say that there should be one primary topic per article; currently there are two. I think it was fine before, with ChaCha being a secondary subject. Can you point out any guidelines that support your approach?
• Can you point out any precedents for articles covering two topics and using conjunction in the title? I don't remember seeing any, but I've seen plenty of examples solving it via primary/secondary topic or splitting.
• Before your edits, the only place talking about ChaCha was the last content section of the article. The intro, infobox, cryptanalysis, etc., was all about Salsa20. I think it would make more sense to change redirects to link to the section directly, which is a common style. Per LEAD I think it's fine to mention ChaCha as a separate sentence in the lead, but not to make it seem like the whole article talks about both.
• I think your SHA-2 analogy doesn't work because it has one well-defined primary topic: the SHA-2 standard and everything defined therein. The article's title isn't called SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256.
• For controversial moves you should follow the WP:RM process, I am going to move it back per WP:RM#Undiscussed moves for now.

-- intgr [talk] 22:12, 1 December 2014 (UTC)

@Claw of Slime: You reverted the edits to the lead section. If you have an opinion on this question then please share it. -- intgr [talk] 10:08, 2 December 2014 (UTC)

My opinion is "Section of ChaCha variants already exist. No need to mention in lead." That's it. I don't agree to renaming the article title to "Salsa20 and ChaCha". SHA-3 need to be renamed to "SHA-3, SHAKE, and Keccak"? SHA-1 to "SHA-1 and SHA-0"? BLAKE (hash function) to "BLAKE and BLAKE2"? Advanced Encryption Standard to "Advanced Encryption Standard and Rijndael"? It's verbose, meaningless, and nonsense. No positive effect for readers. --Claw of Slime (talk) 16:47, 2 December 2014 (UTC)

I am supportive of splitting them out to independent articles. For example, DES and Triple DES have their own pages despite being even more similar than Salsa and Chacha. KMeyer (talk) 14:43, 28 August 2018 (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)

I agree current lead section and ChaCha section. Thank you Agr. --Claw of Slime (talk) 08:57, 4 December 2014 (UTC)

Rename it to Chacha20

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)

ChaCha20 and non-interoperability

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)

@Noloader: 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 [sic] 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)

Anyway that's a moot point now, TheInevitable already updated it. -- intgr [talk] 19:49, 7 August 2017 (UTC)

Invertivle

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)

Suggesting to reverse RFC references to most current first, perhaps with history included later

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)

XSalsa description

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)