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,530
  • 15
  • 27

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,905
  • 2
  • 32
  • 83