2

In order to reduce the amount of key exchanges, I propose to encrypt messages using the same key stream, by selecting subsequent positions in the keystream for the separate messages.

I.e., message $M_1$ gets encrypted with the first $|M_1|$ bits of the key stream, message $M_i$ with bits $|M_1| + |M_2| + \dots + |M_{i-1}|$ to $|M_1| + |M_2| + \dots + |M_{i}|$ bits of the same key stream.

Observation: This way, I see it as if I encrypt a long message $M_1+M_2 \dots + M_i$ using said stream cipher.

Question: is this observation correct, for

  • all stream ciphers;
  • any specific stream cipher in particular, let's say Salsa20, and ChaCha20;

given that the time interval between messages is "large", and new messages might depend on different transmissions (possibly by an attacker)?

Ruben De Smet
  • 2,370
  • 11
  • 26
  • To clarify: Since you mention an "attacker" – how will you be handling authentication? Also, what is your exact scenario so that you can not use a well vetted key derivation algo to base all future keys on that initially exchanged secret (aka first "key" exchange)? I mean, that would be the usual way to handle it… – e-sushi Jul 26 '17 at 12:08
  • Both you and Paul Uszak make good points, especially since the nonce of Salsa/Chacha actually is meant for this purpose. A key derivation will indeed also solve this problem. – Ruben De Smet Jul 28 '17 at 12:56

1 Answers1

1

To address your bullet point directly, yes this will work for all generic key streams that only produce a sequence dependent solely on a key. However these are some real world problems.

  • Your scheme requires perfect synchronicity between a single pair of sender and receiver. Otherwise the stream position will get lost as that is not part of the transmission.
  • You've specifically mentioned attackers. Receipt of an attackers message will throw out the stream position and you'll never recover it without careful tracking of the number of characters received. Perhaps not even then.
  • Similarly, anything other that a single pair of sender /receiver will make stream position recovery extremely difficult. In the long term, impossible /impractical.
  • Salsa20 /ChaCha20 overcome this problem by use of a nonce that resets the key stream to an identifiable position.
  • If you don't exchange keys, how can new members join the party?

Key exchange is a part of cryptography and is well addressed. Key stream positioning is the role of a nonce, and well discussed.

Paul Uszak
  • 15,390
  • 2
  • 28
  • 77
  • 1
    "If you don't exchange keys, how can new members join the party?" Of course I exchange keys. I just want to minimize the amount.

    "stream position[...]as that is not part of the transmission." -> does the answer on the question change, when it's included in the transmission? Because I meant it that way, I might need to make that explicit.

    W.r.t. the Salsa/Chacha nonce, I didn't know. Thank you.

     – Ruben De Smet Jul 26 '17 at 11:44
  • 1
    Actually, my question looks like an x-y problem, where I just need to transmit the nonce instead of the stream position... – Ruben De Smet Jul 26 '17 at 11:49
  • 1
    Key stream positioning is the role of a nonce – Unless that nonce is used as a counter within the individual algorithm, the IV is more of a salt. But that's merely a nit-pick because, in the end, the effect is somewhat the same when looking at most stream cipher designs. – e-sushi Jul 26 '17 at 12:05