Block Cipher CTR mode when offset is not known by receiver

Question

When an encrypted message is received, it can be easily decrypted if the offset (=counter) of the received message is known (and also the required private key of course). This allows for random access on decryption. What if the receiver somehow forgot to keep track of the counter. Can the receiver still recreate the original plaintext? Or is it required that every received encrypted text is asigned a resp. counter value upon arrival? Or is this counter passed in some way such that the receiver does not have to keep track of it, e.g. as an additional parameter.

A scenario I was thinking of is that when the receiver missed the first N blocks. He/she would then not know the current counter resulting in not being able to decrypt.

Answer 1

Most protocols are like TLS, where you can't start in the middle. In most protocols, the counter is implicit, the receiver needs to count blocks from the beginning, if the receiver doesn't know the current value they can't decrypt.

The reason this is not a problem with live streaming video on the internet is that in modern video livestream, the video is cut into little 5 second chunks encoded in multiple resolutions for clients with different effective bandwidth, and the client uses TLS download of each 5 second chunk of the video, switching to smaller or bigger version depending on how long it took to download the previous 5 seconds of video. See HTTP Live Streaming.

Most protocols do not support "tune-in in the middle of broadcast, already have shared symmetric key, start decrypting in middle of stream".

If you are developing something like encrypted broadcast with shared key, you need your protocol to insert "resync" metadata every few seconds (maybe every second) for the benefit of clients tuning-in just now [1]. Maybe the resync provides only markers, and the "handshake" protocol the joining client uses to receive the shared symmetric key will also give the client the counter value for the next marker.

1 - Video codecs also need to do that if the video is not cut into separate 5 second video files (see "Periodic Intra Refresh" in x264).