I would like to know why the sender and receiver must be synchronized in synchronous stream ciphers as said in synchronous stream cipher. Why is there no synchronization between the sender and receiver in asynchronous stream ciphers?

I'm thinking that a plain text is first encrypted and then decrypted. I can't get how encryption and decryption are done at the same time. Is this synchronization done in block ciphers too?


With a synchronous stream cipher (Sync SC), the stream is generated from the internal state, which is built from the key, and depending on the algorithm, a nonce. As the algorithm goes through its steps, the state is changed, and new stream bits are generated. If you want go get to the 11560th bit of stream, you have to start at bit 1 and go through all steps until you get the state at the right point for the bits you want, you cannot just get there in a single step.

Most Sync SCs have a large internal state built from the key, which is processed in some way defined by the algorithm, of which a small bit is exported as the stream. The processing and export is repeated to generate more stream bits.

The asynchronous stream cipher (Async SC) allows you to get there in a single step, or sometimes a little more than 1 depending on the algorithm. CTR mode on a block cipher is an example of an asynchronous, or seekable stream cipher. You use the key, the nonce, and the block number you want, and it generates the stream for that block. Salsa and ChaCha are built using a type of counter mode. CTR mode on a block cipher only requires a single encryption operation to generate any single block, regardless of its position in the stream, and only needs to change the block counter to get there.

In terms of getting the sender and receiver synchronized, with the Async SC you only need to know which block or bit you are on, and you are synchronized. The Sync SC requires the sender and receiver to both generate stream bits until they get to the same point, then they must make sure they do not get out of sync. Depending on the protocol and type of data, they may need to start at the beginning. If using a Sync SC in a real time communications protocol, that can be a showstopper.

Some Async SCs may need some of the prior stream bits as input, which requires successful decryption of some of the prior data. An example of an Async SC that needs prior stream bits is a hash function that hashes the last output. This is not used in practice because it is not secure, but it is useful as an example.

Block ciphers also need some sort of synchronization, but that is mode dependent. Some modes turn the block cipher into a stream cipher, as referenced above in CTR mode. Some require only the prior block to sync, such as CBC mode. Any block cipher mode will need to keep the block alignment in sync.

  • $\begingroup$ :That's a good answer.Why don't we have to start from bit 1 in asynchronous stream cipher even if this stream cipher depends on the key and the previous cipher characters to reach the 11560th bit? $\endgroup$ – justin Apr 29 '15 at 10:39
  • $\begingroup$ because they don't depend on all those bits, maybe just the last 1000, or even none of them at all. CTR type ciphers do not need any of the prior ciphertext $\endgroup$ – Richie Frame Apr 29 '15 at 10:47
  • $\begingroup$ :Okay.Do you mean to day that CTR type ciphers are asynchronous?While looking this (p.8)document it says "in synchronous stream ciphers keystream is independent from plain text and ciphertext".Does this mean that CTR type ciphers are synchronous since their keystream isn't dependent on plain text or ciphertext? $\endgroup$ – justin Apr 29 '15 at 10:58
  • $\begingroup$ no that is not what that means, that is like saying that cats like milk, and I like milk and therefore am a cat. CTR type ciphers depend on a counter to synchronize, synchronous ciphers depend on an internal state, some other asynchronous ciphers depend on prior ciphertext or plaintext $\endgroup$ – Richie Frame Apr 29 '15 at 11:01
  • $\begingroup$ :Okay.That's great.Why do we need to synchronize between sender and receiver?I am thinking that first the plain text to be send is encrypted and then send to a receiver and then the receiver decrypts the whole plain text?Am I right or wrong? $\endgroup$ – justin Apr 29 '15 at 11:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.