# hardware and software optimizations for Salsa20

I'm using the Crypto++ implementation of Salsa20 for a software project we are working on and I'd like to know if there are any SSE or software optimizations that will increase the speed of the CSPNG?

-
This question appears to be off-topic because it is about optimizing software. I think it will get better answers at programmers.SE. –  e-sushi Aug 24 '13 at 15:19
@e-sushi Why wouldn't the relevance to cryptography of optimizations techniques or hardware features be on-topic here? –  Gilles Aug 24 '13 at 16:56
@e-sushi I doubt that programmers.SE community will have the required expertise to adequately answer crypto optimization questions. This is of course a generalization - they will obviously have capable people within the community, but I think the chance of having an insecure answer there is significantly higher than here. And let's be honest here: a large part of symmetric crypto is optimization. –  orlp Aug 24 '13 at 18:21
Thank you nightcracker –  Charles Hoskinson Aug 24 '13 at 20:41

Looking at the Crypto++ 5.6.2 implementation for Salsa20 it seems they do have an SSE implementation, but it doesn't use intrinsics so it doesn't look very portable between compilers.

If you're not exactly set on using Salsa20 I would recommend using ChaCha20, which is a small modification of Salsa20 by the author (Daniel Bernstein) that is slightly faster and cleaner. And if you really value speed I would recommend using Salsa12, which reduces computation time by about 40%.

For ChaCha20 I would recommend the crypto_stream\chacha20\krovetz implementation found in SUPERCOP. Similarly for ChaCha12.

For Salsa20 I suggest you look inside the crypto_stream\salsa20 folder and look for an appropriate implementation for your target platform. You can see timings for various platforms at these pages.

-
This is second hand from two different sources, but at the Crypto 2013, Bernstein was recommending to people that they not use a reduced round version of Salsa20(i.e Salsa12,13, 19, etc) for a proposed addition to TLS. I believe there are (mainly) theoretical attacks against reduced round variants –  imichaelmiers Aug 24 '13 at 17:04
Our goal is to populate blocks of 128 MBs of RAM with noise and my thought process was to simply use a CSPRNG. Salsa20 is a fairly fast. The noise has to be as close to random as possible. –  Charles Hoskinson Aug 24 '13 at 20:40
@CharlesHoskinson What purpose does the noise have? Will it ever be used to encrypt sensitive data or did you just choose for a cryptographic PRNG for maximum randomness? Will the random data ever face an attacker trying to find the seed? Because if you only need it to be sufficiently random for things like simulation or random overwriting of memory I would not hesitate to suggest ChaCha8 or even a non-cryptographic RNG for speed. –  orlp Aug 24 '13 at 20:50
The seed is public knowledge and we are using for a proof of work. We selected a CSPRNG both security and randomness. I suppose we could use hardware accelerated AES. My goal is raw speed. –  Charles Hoskinson Aug 27 '13 at 3:12