It is often said to never use a nonce for more than one message when using a stream cipher. It seems this is to prevent something like this: Taking advantage of one-time pad key reuse? Yet what if I keep the same nonce, but increment the block counter depending on the amout of blocks exchanged so far? This should be the same thing as turning the whole exchange into one long message, thus not needing more than one IV. By exchange I mean two people sending each other stuff.
$\begingroup$
$\endgroup$
5
-
$\begingroup$ a) doing this is likely going to be as hard as doing the same with IVs b) Can you be more precise into what this "block counter" is for you? $\endgroup$– SEJPMJan 28, 2017 at 18:17
-
$\begingroup$ Salsa20 internally uses a counter along with the nonce and the key to generate the cipher stream (to xor with your messages). The implementation I'm using allows to specify the counter. Specifying the counter allows you to decrypt/encrypt a block without having to decrypt all previous blocks. Usually, the counter is incremented for every generated block (every 512 bits). $\endgroup$– Gordanothon JohnJan 28, 2017 at 18:26
-
$\begingroup$ If you do what you propose you're basically back at CTR. There's a reason why you should not fiddle with this sort of internals. I can't right now but will write an answer soon (~30-60min) $\endgroup$– SEJPMJan 28, 2017 at 18:28
-
$\begingroup$ You won't gain anything with such approach. You risk reusing stream position and you are limited to 64bit space. So there is no point in doing so, except if you want to lose compability with some libraries. Use IV. $\endgroup$– axapaxaJan 28, 2017 at 18:32
-
$\begingroup$ Note: "It uses a dedicated 64-bit block counter to avoid incrementing the nonce after each block." - taken from the documentation of libsodium ( download.libsodium.org/doc/advanced/salsa20.html ). I'm not directly fiddling with the internals - just passing arguments (the ic argument) to the API. And I don't think a single transfer session is gonna exhost the entire 64bit space. If necessary, I can use carry-add on the counter and add the carry to the nonce. $\endgroup$– Gordanothon JohnJan 28, 2017 at 18:44
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
6
[What] if I keep the same nonce, but increment the block counter depending on the amout of blocks exchanged so far?
This is a "bad" idea.
What Salsa20 is doing can be considered to be "CTR-Mode like" $E_k(IV\parallel CTR)$ where you have to supply $k$ and $IV$.
If you were allowed to supply $IV'=IV\parallel CTR$ this would also mean you'd to absolutely make sure that no two blocks ever happen to share the same $IV'$ under the same key. Even worse to make sure this doesn't happen, you'd have to pick $IV'$ at random (or actually keep track of all the blocks encrypted under the key) as opposed to being able to just increment $IV$ (= uniqueness).
Note that this change was made to the usual API of authenticated encryption schemes to avoid the above mentioned problems and this approach is now standard with modern authenticated encryption schemes (like ChaCha20-Poly1305 and AES-GCM)
-
$\begingroup$ Is there any other way to do random access on blocks? $\endgroup$ Jan 28, 2017 at 19:58
-
$\begingroup$ @GordanothonJohn the random access to blocks (which has its uses) has the main application of re-gaining synchrononisation. You really shouldn't use it to concatenate two messages which you could normally use 2 nonces for. $\endgroup$– SEJPMJan 28, 2017 at 20:00
-
$\begingroup$ So if I need to transfer (random) segments of a large file, I'll need to make an IV for every 512 bits? Is there a less traffic-consuming way?(I want it to transfer faster) $\endgroup$ Jan 28, 2017 at 20:06
-
$\begingroup$ @GordanothonJohn what about making an implicit IV? Like start with an explicit random one and then implicitely increase it for each block by one (in order). $\endgroup$– SEJPMJan 28, 2017 at 20:08
-
$\begingroup$ Maybe I should set both the counter and the nonce to random, but increment only the counter? You said it concatinates the counter to the nonce, so It'll make no difference unless I'm transfering more blocks than fit into the 64bit space $\endgroup$ Jan 28, 2017 at 20:10