Hot answers tagged

29

This appears to be a simple case of Loop Unrolling, which is a generic software optimization. Implementations of crypto algorithms are often times "unrolled", which means taking the statements that normally go in a loop and hardcoding them in the order they would have happened. This is a performance optimization: The loop counter requires cycles to increment ...


14

XSalsa20 uses the same cryptographic core as Salsa20 and comes with a security proof that it's secure if Salsa20 is secure. It doesn't use the core of ChaCha and thus has worse diffusion. The way XSalsa20 works is that it hashes its 256 bit key and the first 128 bits of the nonce using HSalsa down to a 256 bit key and then uses that key together with the ...


14

The input of the Salsa20 core is a 4x4 array of 32-bit words. If you move all the inputs diagonally (wrapping), the output will be the same as the original output, except that it's moved by the same offset. $P^\prime_{i,j}=P_{i+k,j+k}$ implies $C^\prime_{i,j}=C_{i+k,j+k}$ (indices reduced modulo 4) This symmetry follows directly from Salsa20 applying the ...


13

The internal state of RC4 consists of a shuffled 256-element array and two pointers into that array. Thus, there are a total of $$256! \times 256^2 \approx 2^{1700.00}$$ possible states. Since the state update function of RC4 is reversible, it acts as a permutation on this set of possible states, so that every starting state will eventually recur after ...


12

Salsa20 has strong rotational symmetry. The main point of these constant is that they're not invariant under rotations, introducing an asymmetry. The precise value isn't very important, as long as it's sufficiently asymmetric. Bernstein - Salsa20 security says: Notes on the diagonal constants Each Salsa20 column round affects each column in the same ...


11

By definition of Salsa20 used as a stream cipher, it uses a 64-bit block counter and 64-bytes blocks, limiting its capacity to $2^{73}$ bits. After that, the counter would rollover, and thus the output. In a sense, this is the period. RC4 has no such explicit limit on the size of its output. We do not know how to exactly compute the period size, which very ...


10

There are in the RFC : http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04#section-7 The following blocks contain test vectors for ChaCha20. The first line contains the 256-bit key, the second the 64-bit nonce and the last line contains a prefix of the resulting ChaCha20 key-stream. KEY: ...


10

The sum of two words with carries suppressed is just a convoluted way of saying XOR. You don't need to implement any kind of complicated summation operation. Just perform a bitwise-exclusive OR. If you're performing modular addition, just like with paper-and-pen mathematics, you need to use carries. When adding binary, you're doing the same, but each digit ...


9

Generally speaking, there are (at least) three reasons to put a KDF in between an DH shared secret and the bulk encryption. Improved re-usability. If you don't post-process the shared secret with a KDF there's no way to give the sender and the recipient different keys for each direction or to split up authentication and encryption keys. An additional bonus ...


9

Pulling information from the wikipedia entry on Salsa20: eSTREAM selection Salsa20 has been selected as a Phase 3 design for Profile 1 (software) by the eSTREAM project, receiving the highest weighted voting score of any Profile 1 algorithm at the end of Phase 2.[6] Salsa20 had previously been selected as Phase 2 Focus design for Profile 1 (software) ...


8

I doubt you will find a fast implementation of Salsa20 in Java (having spent much time attempting to achieve just this). Salsa20 mutates a 512 bit state made up of 16 x 32 bit integers, which means that implementations that don't take advantage of SIMD (on Java or otherwise) will probably not perform well - there are too many independent state parts to keep ...


8

I agree that conservatism is the likely reason for the choice in McBits. ChaCha was published while eSTREAM was still running. Salsa20/12 is now in the final eSTREAM portfolio. Even in the XSalsa paper on constructing a larger nonce, Bernstein makes no mention of ChaCha. So what are the reasons to prefer Salsa20 over ChaCha? Wanting to use a ...


7

No, you cannot "directly" encrypt a file using ECC without generating your own algorithm. Encrypting a file would be extremely inefficient; this is because the block size of ECC is very small, leading to a very high overhead both with regards to data usage (the ciphertext would be strictly larger than the plaintext) as well as CPU-usage. Yes, any curve can ...


7

Rather than giving the advantages of purpose build stream cipher I'll give the disadvantages of using a PRNG / DRBG (you are using a PRNG for the use case of a stream cipher after all): Implementation details (including reseeding) may differ between systems (this is less likely if the DRBG is well defined and tested, but as they have been designed to ...


6

As stated in the comments, dev/random already produces cryptographically secure random bytes which are perfectly adequate for use in encryption keys. Running these bytes through another CSPRNG is completely redundant. As far as I've understood, one of the options to create cryptographically secure keys would be to gather entropy from /dev/urandom/ and ...


6

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


6

Can we exhibit collisions, or second-preimages (with implies the former), for the ChaCha core? No, likely not. The Salsa20 and ChaCha cores both consist of a large number of "quarter-rounds" each of which is invertible and bijective. The only reason neither core is a bijection (and thus can have collisions) is the final addition of the input elements into ...


6

Maybe. But your scheme hasn't been vetted by the community for its impact. Better to use XSalsa20 or the related XChaCha20 as recommended by Bernstein himself: http://cr.yp.to/snuffle/xsalsa-20110204.pdf In my opinion it was a fairly major faux pas that DJB originally chose short 64-bit nonces for Salsa20 and ChaCha20, especially given all the nonce-misuse ...


6

As a comment points out, it’s most probably a mistake/error in the docs. If you look at “What is the PRG period of stream ciphers such as RC4 or Salsa20?”, you’ll find an answer which explicitly points out the limits of Salsa20 (quote) …Salsa20 used as a stream cipher, it uses a 64-bit block counter and 64-bytes blocks, limiting its capacity to $2^{73}$ ...


6

I use HMAC-DRBG in my python modules as a backup for when no "real" crypto package is installed. The python 2 standard library offers cryptographic hashes and HMAC, but no encryption primitives. The advantage of HMAC-DRBG over something like AES-CTR/ChaCha is that is significantly less complicated than implementing a "real" design in pure python, and faster ...


6

Per the Salsa20 page - Each modification involves xor'ing into one word a rotated version of the sum of two other words modulo 232. Adding two uint32s and ignoring the carry / overflow is equivalent to performing addition modulo 232.


5

You'll find the test vector in a draft "Test Vectors for the Stream Cipher ChaCha draft-strombergson-chacha-test-vectors-00" available at the following link: http://tools.ietf.org/html/draft-strombergson-chacha-test-vectors-00 The document links a github repo where you can find all the vectors https://github.com/secworks/chacha_testvectors/ Another ...


5

Salsa20 is a stream cipher based on a pseudorandom function, not a pseudorandom permutation. For a fixed key $k$ and nonce $n$, the mapping $PRF^{S20}_{k,n}: \{0,1\}^{64} \to \{0,1\}^{512}$, which maps a "Stream position" to "keystream block", is supposed to be a pseudorandom function. It is not supposed to be injective (i.e. a permutation, even less since ...


5

Every paragraph ends with : "this operation is invertible", I suppose the whole salsa20 algorithm is. The Salsa20 quarterround, and thus rowround, columnround and doubleround are invertible. However, the whole Salsa20 core is not because the initial state is added to the state after iterating the rounds (cf. page 6 in the spec). If I use salsa20 in ...


5

Note that, in Salsa20, the loads and additions of the key words ($x_1$, $x_2$, $x_3$, $x_4$, $x_{11}$, $x_{12}$, $x_{13}$, $x_{14}$) are critical for security, since the double-round function is trivially invertible. One might think that the remaining loads and additions could be skipped without sacrificing security, achieving almost half of the ...


5

Can one extend the ChaCha and Salsa20 nonces by XORing the extra nonce bits with the key? One can, but one probably should not. Security against related-key attacks is not claimed for either (Salsa20 security pdf): The standard solutions to all the standard cryptographic problems—encryption, authentication, etc.—are protocols that do not allow related-...


5

The requirements of a key schedule would be easily met by Salsa20, or any PRF for that matter. A key schedule is similar in purpose to a cryptographic hash functions (which Salsa20 is built off of), but the requirements are not as strict. For example, a preimage attack is fatal to a hash function, but being able to calculate the original key given only the ...


5

Reducing the rounds to 8 would give you Salsa20/8, which is not just a fast PRNG operating at 1.88 cycles per byte on Core2Duo, but is still quite cryptographically secure with the best attack requiring approximately 2244 operations. Removing the final addition step would not be good though, as without that, it would be trivial to reverse the function and ...


5

Writing a secure messenger application is difficult, and vulnerabilities have been found, and keep being found in all of them. This requires far more than just a stream cipher such as Salsa20. An entire protocol has to be designed for user registration, key exchange, group invites and more. The MLS working group is currently designing a reference protocol ...


4

You are correct about extending number of rounds. It is safe to increase number of rounds. In most cases it will increase safety margin. Removing constants doesn't seem to be a good idea to me, as Salsa20 and ChaCha don't have any round constants. Purpose of constants is also to reduce number of bits that can be controlled by attacker, however key is not ...


Only top voted, non community-wiki answers of a minimum length are eligible