Exercise 2: Block vs. Stream Ciphers, and a Practical Scenario — Possible Solution
====================================================================

Structural difference:

A block cipher (like AES) processes data in fixed-size chunks --
128 bits at a time for AES. If the plaintext isn't an exact multiple
of the block size, the last block has to be padded out with extra
bytes before it can be encrypted, and that padding has to be removed
again after decryption.

A stream cipher (like ChaCha20) doesn't work in fixed chunks at all.
It uses the key (and a nonce) to generate a long pseudorandom
keystream, then combines that keystream with the plaintext one bit or
byte at a time via XOR. Because it operates a byte at a time rather
than in fixed blocks, there is no "leftover partial block" to pad --
whatever length the plaintext happens to be, the keystream is simply
generated to match that exact length.

Practical scenario favoring a stream cipher's lack of padding:

Live audio or video streaming (or any real-time, continuously-flowing
data feed) is a natural fit for a stream cipher. The data arrives
continuously in small, often irregular chunks rather than neat
fixed-size blocks, and there's no natural "end of message" boundary at
which padding could even be added cleanly. A stream cipher can encrypt
each small chunk of audio/video data as it arrives, in whatever size
it happens to come in, with no padding overhead and no need to buffer
data until a full block is available -- which matters directly for
latency in a real-time application.

WHY THIS WORKS AS AN ANSWER
------------------------------
This reuses the chapter's own comparison table directly (fixed-size
chunks + padding vs. one bit/byte at a time + no padding) and applies
it to a scenario -- continuous, irregularly-sized real-time data --
that specifically exercises the "no padding, no fixed block boundary"
property the chapter calls out as stream ciphers' structural
advantage, rather than a scenario where either family would work
equally well.