Hot answers tagged

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


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

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


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


4

The Salsa20 core is defined on a $4\times4$ matrix $x$ of 32-bit words by $\operatorname{Salsa20}(x) = \pi(x) + x$, where $\pi$ is a permutation. Consider a matrix: \begin{equation} x = \begin{pmatrix} A_0 & B_0 & C_0 & D_0 \\ A_1 & B_1 & C_1 & D_1 \\ A_2 & B_2 & C_2 & D_2 \\ A_3 & B_3 & C_3 &...


3

Well, no you can't (without rescanning the entire ciphertext), and you probably shouldn't anyways. The xSalsa20 is the easy half - it is effectively in counter mode, and so it'd be easy to generate a few more bits out of the xSalsa20 to use to encrypt the additional data you're appending (and those additional bits wouldn't change to previous ciphertext bits)...


3

As Luis Casillas said in his comment, the spec of Salsa is short and well explained. Namely, if you are interested in the expansion function, you can find a description with two examples (one with a 32-byte key, and one with a 16-byte key). Short answer: when dealing with a 16-byte key, you only have to change a constant and append the key to itself. More ...


3

There is no known quantum attack better than the generic Grover attack on Salsa20 and ChaCha, which is inconsequential because it would take $2^{128}$ sequential steps. Even if parallelized $p$ ways to run in marginally less time, a factor of $\sqrt p$ improvement, it would cost more, also by a factor of $\sqrt p$, than the cost to run a quantum computer ...


2

Is there a reason specific input bits were chosen for specific purposes? For example, if the some of the counter bit positions and key bit positions were swapped, would this result in a weaker cipher? No, there would be no real effect on security. The specific positions were chosen primarily to improve SIMD implementation performance. The Salsa20 and ChaCha ...


2

If $ X $ is the ciphertext, $N$ is the nonce value, and $H$ is the authentication tag such that the final ciphertext is $ N \| X \| H $, then given the key $K$, is it possible to extend $ X $ with more data, without decrypting it, updating $N$ and $H$ as needed? For most schemes, this is very much possible, yes. There are two parts to this: The CPA-secure ...


2

This can be a secure construction, if by MAC you mean universal hash family, like Poly1305. Call this hash family $H_r$ and the short pseudorandom function family $F_k$. Rough justification for why this is secure: The function $m \mapsto F_k(H_r(m))$ is a long-input, short-output PRF. A good PRF makes a good MAC. A good PRF has birthday-bounded collision ...


2

Salsa20 has essentially no limits on its own for data volume: it can be used for up to $2^{64}$ messages of up to $2^{70}$ bytes apiece. You could use it in a nonstandard way for, say, more messages if they're each smaller, by carving up the input to the PRF differently, as long as the total volume of data is below $2^{134}$ bytes. You certainly can't ...


1

The Salsa20 specification paper contains examples for testing for each function. quarterround 7 example, rowround 2 example, etc.. Indeed this paper is written as a tool for programmers, or the analyzers so that they can use these test vectors. Salsa20 exists in the Crypto++ which is a C++ library originally written by Wei Dai. You can use this code to test,...


1

Yes this is "OK". Please correct me if I'm wrong there. You are correct. It's effectively ratcheting the original key. However there may be a more elegant solution such as using static keys for auth and ephemeral keys for key agreement (i.e. use Ephemeral-Ephemeral Diffie-Hellman for each new message).


1

Using crypto_secretstream that should be fine. It generates a random nonce for each message. Reusing a key in that context is fine. Original answer, before edit follows: Yes, that's bad. You have to use a unique IV/nonce for each document. A stream cipher, such as ChaCha, which is combined with the plaintext using XOR reveals the keystream to anyone who ...


1

Am I considerably reducing the complexity of finding the original key this way? No. If key was only used as input of chacha20_block(key, counter=0, nonce) when preparing the lookup_tables, then finding the original key is demonstrably at least as hard as breaking chacha20 (the algorithm) in its intended usage. Am I increasing attack chances? Depends ...


1

Perhaps the best evidence for the related-key security of Salsa20 is in the Rumba compression function proposed by the author: $$ \mathrm{Rumba}(m_1, m_2, m_3, m_4) = f_1(m_1) \oplus f_2(m_2) \oplus f_3(m_3) \oplus f_4(m_4)\,, $$ where $f_i$ is Salsa20 with a different initial constant for each variant, and each $m_i$ is 384-bit wide. Clearly, for the author ...


1

I suggest you take a look at the spec of Salsa20. It is quite short and easy to understand. You even have some examples for each component of the implementation. For more details, you can take a look at this post which explains how to handle different key size (how to treat your initial block, and feed it to the Salsa hash function).


1

Just use the test vector specified by DJB himself, specified here, chapter 4 (just XSalsa20) and chapter 10 for the box. This will already test all your primitives. To perform boundary tests, I would strongly suggest you first document the boundaries. These are the places where there is a difference in e.g. buffer handling for the MAC function. If you test ...


1

Are you actually sending these messages over the network? If you don't, this limit doesn't apply, even though splitting large messages into chunks is still worth it: the whole message doesn't have to fit in memory, and an invalid message can be rejected earlier. If you do, 4 KiB is a very conservative size, that you can safely bump up on most modern ...


1

This is advice to you, the application protocol designer, on how to use the cryptography. The word ‘separately’ applies to the packets, not to encrypt and authenticate: use crypto_secretbox_xsalsa20poly1305 for one ≤4096-byte packet at a time. You should split longer messages into ≤4096-byte packets with sequence numbers. This way: The most memory an ...


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