I still remember the first time I had to pick an encryption approach for a telemetry pipeline. The data looked small and “real-time,” so a stream cipher felt natural—but the compliance team expected authenticated block‑cipher modes. That mismatch forced me to revisit fundamentals, and it changed the way I evaluate cryptography in systems design. If you’re building anything from a file backup tool to an IoT gateway, you’ll eventually face the same decision. In this post, I’ll walk you through the practical difference between block ciphers and stream ciphers, how the trade‑offs show up in real systems, and how I choose between them today. I’ll keep the math light, use clear analogies, and show concrete examples you can run. By the end, you should be able to make a confident choice, spot common mistakes, and explain your reasoning to teammates, auditors, or security reviewers.
The Core Idea in One Sentence
A block cipher encrypts fixed‑size chunks of data, while a stream cipher encrypts data one bit or byte at a time by combining it with a generated keystream.
That sounds simple, but the details matter: block size, modes of operation, error behavior, performance, and how modern authenticated encryption fits in.
How I Picture Each Cipher (Simple Analogy)
When I teach this, I use two analogies that keep the mental model crisp:
- Block cipher: Think of packing letters into identical boxes before shipping. Each box must be filled to a fixed size, and the shipping label (the key and mode) tells the courier how to scramble the contents.
- Stream cipher: Think of encrypting a live voice call by mixing it with a synchronized noise signal. Every moment you speak is combined with a matching slice of noise; the listener subtracts the same noise to recover your words.
These analogies map to two key behaviors:
- Block ciphers like AES work on fixed‑size blocks (often 128 bits). If your data doesn’t align, you must pad or use a streaming mode.
- Stream ciphers like ChaCha20 emit a pseudorandom keystream that you XOR with the plaintext as it flows.
Block Ciphers: Fixed‑Size Strength With Flexible Modes
Block ciphers are the heavyweight workhorses of symmetric cryptography. In my day‑to‑day, I see AES in disks, TLS, VPNs, and database encryption. The algorithm itself only knows how to encrypt a fixed-size block, but the real magic is in the mode of operation.
What a Block Cipher Actually Does
A block cipher maps a block of plaintext to a block of ciphertext using a key. That mapping is reversible with the same key, and it’s designed to look random to anyone without the key.
Key characteristics I keep in mind:
- Fixed block size, typically 128 bits for AES.
- Strong diffusion and confusion: a small change in input spreads throughout the output.
- Security depends primarily on key length and mode of operation.
Modes Matter More Than People Expect
A raw block cipher is not enough by itself. The mode determines how blocks relate to each other, and that directly affects security.
Common modes I see in modern systems:
- CBC (Cipher Block Chaining): each block depends on the previous block. Requires an IV and correct padding. Vulnerable to padding‑oracle bugs if misused.
- CTR (Counter mode): turns a block cipher into a stream-like mode. Great for parallelism and random access.
- GCM (Galois/Counter Mode): CTR plus built‑in authentication. This is the default in many modern stacks.
If you only remember one thing: I strongly prefer authenticated modes like GCM over older modes like ECB or CBC. ECB is almost always a mistake because identical blocks produce identical ciphertext blocks, which can leak patterns.
When Block Ciphers Shine
I reach for block ciphers when I need:
- Strong, standardized encryption for stored data: database fields, backups, disk encryption.
- Tight integration with authenticated encryption modes (AES‑GCM is ubiquitous).
- Hardware acceleration: AES is fast on most modern CPUs because of AES‑NI or equivalent.
Stream Ciphers: Byte‑Wise Speed and Simplicity
Stream ciphers are my first pick for encrypting data that arrives or leaves continuously. They are conceptually simple: generate a keystream and XOR it with the plaintext. That’s it.
How a Stream Cipher Works
A stream cipher uses a key and usually a nonce to produce a pseudorandom keystream. Encryption is just:
ciphertext = plaintext XOR keystream
Decryption is the same operation, because XOR is its own inverse.
Key characteristics I watch for:
- Encrypts one bit or byte at a time.
- Very fast in software, often faster than block ciphers without hardware acceleration.
- Needs careful nonce handling to avoid keystream reuse.
Modern Stream Ciphers
In 2026, I rarely see RC4 in any healthy codebase. Instead, I recommend ChaCha20 or Salsa20, with ChaCha20‑Poly1305 as the authenticated version. It’s widely supported, efficient on mobile and embedded devices, and resists several classes of implementation pitfalls.
When Stream Ciphers Win
I reach for stream ciphers when I need:
- Low‑latency encryption for live data streams.
- Simplicity in environments without AES hardware acceleration.
- Robust performance on constrained hardware.
Side‑by‑Side Comparison
Here’s a practical comparison I use when I’m sketching system designs with my team:
Block Cipher
—
Fixed-size blocks (often 128 bits)
AES, DES, Blowfish
Yes, to encrypt streams or long messages
Often affects a full block (or more)
Usually required for block-aligned modes
Good in modes like CTR/GCM
File/disk encryption, TLS, databases
Must be added (e.g., GCM)
If you’re picking today, the right question is rarely “block or stream?” It’s “which authenticated scheme best fits my constraints?”
The Real‑World Trade‑Offs I See in Production
This is where the rubber meets the road. Theoretical differences are helpful, but operational behavior is what actually breaks systems.
1) Error Propagation
- Block cipher modes like CBC can cause a single corrupted block to garble the next block on decryption.
- Stream ciphers typically isolate errors to the same bytes, which can be helpful for media streams or telemetry where partial data is better than nothing.
If I’m encrypting live video or sensor data, I prefer a stream cipher or a block cipher in a stream‑like mode (CTR) plus authentication.
2) Padding and Message Length
Block ciphers in padding modes require you to handle padding safely. I’ve seen multiple production outages caused by padding errors or incorrect padding removal.
Stream ciphers don’t need padding at all, which simplifies implementation and avoids a whole class of bugs.
3) Performance and Hardware
On modern servers with AES acceleration, AES‑GCM can be exceptionally fast. On mobile and embedded hardware without AES acceleration, ChaCha20‑Poly1305 often wins.
When I build cross‑platform systems, I benchmark both. The performance difference can easily land in the “typically 10–20% faster” range for one or the other depending on the device class.
4) Parallel Processing
CTR and GCM allow parallel processing of blocks, which is a big win for throughput. Stream ciphers also support parallelization because the keystream can be generated in independent chunks.
If you need high‑throughput encryption in a pipeline, both approaches can scale well. The real difference is often in how easy it is to implement correctly in your stack.
Practical Guidance: When I Choose What
If you want specific guidance, here’s how I decide in 2026:
I choose a block cipher when:
- I’m encrypting files or structured data at rest.
- The platform has AES acceleration.
- I want a widely standardized option for compliance audits.
- I can use an authenticated mode like AES‑GCM or AES‑SIV.
I choose a stream cipher when:
- I’m encrypting real-time streams (audio, video, telemetry, logs).
- I’m targeting mobile or embedded hardware without AES acceleration.
- I want a simpler, padding‑free implementation.
- I can use a modern AEAD like ChaCha20‑Poly1305.
I avoid either when:
- I can’t enforce correct nonce/IV handling.
- I can’t store or transmit authentication tags.
- I’m tempted to roll my own mode or key derivation.
Common Mistakes I See (and How You Should Avoid Them)
Even strong ciphers can fail if you mishandle them. Here are the issues I run into most often:
Reusing Nonces or IVs
This is the single biggest foot‑gun in stream ciphers and stream‑like modes such as CTR. If you ever reuse a nonce with the same key, attackers can recover plaintext via XOR.
What I do instead: I treat nonce generation as a first‑class API. I use cryptographically secure random nonces or deterministic counters stored with the ciphertext, and I always enforce uniqueness.
Skipping Authentication
Encryption without integrity is not enough. Attackers can flip bits in ciphertext and cause predictable changes in plaintext.
My rule: Use an AEAD mode (AES‑GCM or ChaCha20‑Poly1305). If the library doesn’t offer AEAD, I pick a different library.
Using ECB (Ever)
ECB leaks structure. I’ve seen image files encrypted with ECB where the original image was still recognizable. That’s not theoretical; it happens.
My rule: Never use ECB in production, not even for “short messages.”
DIY Key Derivation
I’ve seen apps use plain passwords as keys. That’s a mistake. Keys need to be derived with a KDF.
My rule: Use a modern KDF such as Argon2id or scrypt, with proper parameters.
Example: AES‑GCM for File Encryption (Python)
Here’s a runnable example using a block cipher in an authenticated mode. This is a baseline for file encryption on servers with AES acceleration.
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os
def encrypt_file(plaintext: bytes, key: bytes) -> dict:
# AESGCM expects a 12-byte nonce for best performance
nonce = os.urandom(12)
aesgcm = AESGCM(key)
ciphertext = aesgcm.encrypt(nonce, plaintext, associated_data=None)
return {"nonce": nonce, "ciphertext": ciphertext}
def decrypt_file(nonce: bytes, ciphertext: bytes, key: bytes) -> bytes:
aesgcm = AESGCM(key)
return aesgcm.decrypt(nonce, ciphertext, associated_data=None)
if name == "main":
key = AESGCM.generatekey(bitlength=256)
data = b"Quarterly report: revenue up 12%."
blob = encrypt_file(data, key)
recovered = decrypt_file(blob["nonce"], blob["ciphertext"], key)
print(recovered.decode("utf-8"))
Why I like this pattern:
- Authenticated encryption is built in.
- Nonce handling is explicit.
- It’s safe for variable-length inputs without manual padding.
Example: ChaCha20‑Poly1305 for Streaming Data (JavaScript)
For real-time data or mobile devices, I often pick ChaCha20‑Poly1305. Here’s a Node.js example you can run:
import { randomBytes, createCipheriv, createDecipheriv } from "crypto";
function encryptMessage(plaintext, key) {
const nonce = randomBytes(12);
const cipher = createCipheriv("chacha20-poly1305", key, nonce, { authTagLength: 16 });
const ciphertext = Buffer.concat([cipher.update(plaintext), cipher.final()]);
const tag = cipher.getAuthTag();
return { nonce, ciphertext, tag };
}
function decryptMessage(nonce, ciphertext, tag, key) {
const decipher = createDecipheriv("chacha20-poly1305", key, nonce, { authTagLength: 16 });
decipher.setAuthTag(tag);
return Buffer.concat([decipher.update(ciphertext), decipher.final()]);
}
const key = randomBytes(32);
const message = Buffer.from("Sensor reading: 72.4°F");
const blob = encryptMessage(message, key);
const recovered = decryptMessage(blob.nonce, blob.ciphertext, blob.tag, key);
console.log(recovered.toString("utf-8"));
If you’re building a streaming API, this style of encryption fits naturally: the data is already byte‑wise, and the cipher stays fast on commodity CPUs and mobile chips.
A Word on “Block vs Stream” in Modern APIs
In 2026, most cryptography libraries hide the block/stream distinction under AEAD interfaces. For example, AES‑GCM is a block cipher in counter mode with authentication, and ChaCha20‑Poly1305 is a stream cipher with authentication. They both present as:
- key + nonce + plaintext → ciphertext + tag
So, practically, I ask three questions:
1) Can I ensure unique nonces for every encryption operation?
2) Is there hardware acceleration (AES) or platform bias (mobile) that affects performance?
3) Does the library provide a safe, high‑level AEAD interface?
If the answers are good, the “block vs stream” debate becomes a secondary detail.
Edge Cases and How I Handle Them
Very Small Messages
For tiny payloads (like 1–64 bytes), I still use AEAD modes. The overhead of the tag and nonce is worth the security guarantee. If size is critical, I use a compact binary format and avoid encryption schemes that require padding blocks.
Random Access to Encrypted Data
When I need random access (e.g., reading a segment from an encrypted file), I prefer modes like AES‑CTR or AES‑GCM with careful chunking. Stream ciphers also support random access by seeking the keystream to the right offset.
Partial Packet Loss
In networked streaming scenarios, a stream cipher or a stream-like block mode is better. If a packet drops, only that segment is corrupted, rather than a long chain of dependent blocks.
Performance Notes You Can Actually Use
Performance is rarely about one cipher being “fast” and the other being “slow.” It’s about the environment:
- On x86 servers with AES‑NI, AES‑GCM is extremely fast and often wins for bulk data.
- On ARM mobile chips without strong AES acceleration, ChaCha20‑Poly1305 is often 10–20% faster in end‑to‑end benchmarks.
- For high‑latency network connections, the cipher cost might be negligible compared to network overhead.
My approach: benchmark with realistic payload sizes. I avoid exact absolute numbers because they vary wildly with hardware, but I look for relative trends.
Deeper Dive: What “Mode of Operation” Really Means
If you’ve seen terms like CBC, CTR, GCM, or XTS and felt overwhelmed, you’re not alone. A “mode” is just a recipe for how to apply a block cipher to messages longer than one block. The core block cipher is a single‑block permutation. The mode tells you:
- How to link blocks together (or not).
- How to generate IVs/nonces.
- Whether and how to provide authentication.
Here’s how I explain three common modes to non‑crypto teammates:
- CBC: Each block depends on the previous one, which makes encryption sequential. It also makes padding tricky and creates risks if error messages leak details.
- CTR: Turns the block cipher into a keystream generator. That makes it “stream‑like” and naturally parallel. It’s also fragile if nonces are reused.
- GCM: CTR for encryption plus a built‑in authentication tag. It is fast, parallel, and the de‑facto standard for data in motion.
If you’re using a stream cipher, the “mode” is basically embedded in the cipher design itself (ChaCha20 is inherently stream‑oriented). But the same rule applies: you still need authentication, which is typically paired as an AEAD (ChaCha20‑Poly1305).
Deeper Dive: Nonces, IVs, and Counters (Why They Matter)
A lot of vulnerabilities start with misunderstanding nonces and IVs. I keep this mental model:
- IVs (initialization vectors) are usually random and can be public.
- Nonces (numbers used once) must be unique for a given key.
- Counters are deterministic nonces that must never repeat under the same key.
Stream ciphers and stream‑like block modes are extremely sensitive to reuse. If you encrypt two different messages with the same key and nonce, the keystream repeats. An attacker can XOR the two ciphertexts and eliminate the keystream, revealing the XOR of the original messages. That’s often enough to recover both plaintexts.
My rules of thumb:
- If I can’t guarantee uniqueness, I rotate keys frequently or choose a misuse‑resistant mode like AES‑SIV.
- I store nonces alongside ciphertext and validate them on decryption.
- I prefer libraries that generate nonces for me or expose a safe counter API.
When NOT to Use Each Approach (Practical Scenarios)
Sometimes the right decision is to avoid a cipher class altogether. Here are concrete scenarios where I step back:
When I Avoid Block Ciphers
- I’m on constrained hardware with no AES acceleration and strict latency budgets.
- I can’t guarantee correct padding or block alignment in my pipeline.
- I need encryption to be “streaming” at the byte level and want zero buffering.
In these cases, a stream cipher or a stream-like block mode (CTR) is more natural.
When I Avoid Stream Ciphers
- I can’t reliably track or store nonces per message.
- I need strong interoperability with compliance frameworks that explicitly require AES.
- I have a multi‑tenant system with complex key management and worry about nonce reuse.
In these cases, AES‑GCM or AES‑SIV gives me the guardrails I need.
Practical Scenario 1: Secure Telemetry From IoT Devices
Imagine thousands of devices sending temperature readings every second. Each message is tiny and time‑sensitive.
What I do:
- Use ChaCha20‑Poly1305 because it’s fast on embedded chips.
- Use a per‑message counter nonce stored in device flash so it never repeats.
- Include device ID and timestamp as associated data so tampering is detected.
This gives me low‑latency encryption, minimal buffering, and strong integrity checks.
Practical Scenario 2: Encrypted Database Backups
Backups are huge, and compliance teams expect strong, standardized crypto.
What I do:
- Use AES‑GCM or AES‑SIV on chunked backup files.
- Store the nonce and tag with each chunk.
- Use a hardware‑backed key if available.
This keeps audits simple and gives strong at‑rest security with good throughput.
Practical Scenario 3: Encrypted Logs in a Distributed System
Logs are append‑only, and you may want partial reads without decrypting the entire file.
What I do:
- Chunk logs into fixed sizes (e.g., 64 KB).
- Use AES‑GCM with a unique nonce per chunk.
- Store a separate index for random access.
This gives me the best of both worlds: block‑cipher strength and stream‑like access patterns.
Modern Alternatives and Misuse‑Resistant Options
Sometimes the “block vs stream” framing is too narrow. Here are alternatives I consider when I need extra safety:
AES‑SIV (Synthetic IV)
If I can’t guarantee unique nonces, I consider AES‑SIV. It is more expensive than GCM but is safe against nonce reuse in many scenarios. This is useful in systems where nonces might be replayed due to bugs or crashes.
XChaCha20‑Poly1305
If I need extremely large nonce space or want to avoid nonce collisions in a distributed system, I use XChaCha20‑Poly1305. It gives me a 24‑byte nonce, which is easier to generate safely without coordination.
One‑Time Pads (Only in Theory)
People sometimes ask if a “true” stream cipher is just a one‑time pad. It’s not practical because you’d need a key as long as the message. This is why we use pseudorandom keystreams instead.
A Clear “How-To” Checklist for Nonce Safety
If you only take one operational guideline from this article, make it nonce safety. Here’s the exact checklist I use:
- Choose a nonce length recommended by the library (often 12 bytes for GCM or ChaCha20‑Poly1305).
- For random nonces, use a cryptographic RNG and never reuse a nonce with the same key.
- For counter nonces, store the counter durably and increment it atomically.
- If you can’t guarantee uniqueness, use a misuse‑resistant mode like AES‑SIV or XChaCha20‑Poly1305.
- Store nonces with ciphertext and authenticate them if possible.
Extended Example: Chunked File Encryption With AES‑GCM
Here’s a more realistic example for large files. Instead of encrypting the entire file in memory, I encrypt in chunks. This makes decryption and random access easier and helps with streaming large files.
import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
CHUNK_SIZE = 64 * 1024 # 64 KB
def encryptfilestream(inpath, outpath, key):
aesgcm = AESGCM(key)
with open(inpath, "rb") as fin, open(outpath, "wb") as fout:
while True:
chunk = fin.read(CHUNK_SIZE)
if not chunk:
break
nonce = os.urandom(12)
ct = aesgcm.encrypt(nonce, chunk, None)
# Write: nonce length (1 byte) + nonce + ct length (4 bytes) + ct
fout.write(len(nonce).to_bytes(1, "big"))
fout.write(nonce)
fout.write(len(ct).to_bytes(4, "big"))
fout.write(ct)
def decryptfilestream(inpath, outpath, key):
aesgcm = AESGCM(key)
with open(inpath, "rb") as fin, open(outpath, "wb") as fout:
while True:
nlen = fin.read(1)
if not nlen:
break
nlen = int.from_bytes(nlen, "big")
nonce = fin.read(nlen)
ctlen = int.frombytes(fin.read(4), "big")
ct = fin.read(ct_len)
pt = aesgcm.decrypt(nonce, ct, None)
fout.write(pt)
if name == "main":
key = AESGCM.generatekey(bitlength=256)
encryptfilestream("input.bin", "output.enc", key)
decryptfilestream("output.enc", "output.dec", key)
This pattern solves practical problems:
- It avoids buffering huge files in memory.
- Each chunk has its own nonce and tag, which enables partial reads and easier recovery.
- The structure is explicit, which helps debugging and auditability.
Extended Example: Streaming Encryption With Chunked ChaCha20‑Poly1305
For streaming scenarios where you want to encrypt chunks of data in a pipeline, here’s a more complete Node.js style pattern. I use counters for nonces, which is safer than random nonces when you can persist state.
import { createCipheriv, createDecipheriv, randomBytes } from "crypto";
const NONCE_SIZE = 12;
const TAG_SIZE = 16;
function nonceFromCounter(counter) {
const nonce = Buffer.alloc(NONCE_SIZE, 0);
nonce.writeUInt32BE(counter >>> 0, NONCE_SIZE - 4);
return nonce;
}
function encryptChunk(plaintext, key, counter) {
const nonce = nonceFromCounter(counter);
const cipher = createCipheriv("chacha20-poly1305", key, nonce, { authTagLength: TAG_SIZE });
const ciphertext = Buffer.concat([cipher.update(plaintext), cipher.final()]);
const tag = cipher.getAuthTag();
return { counter, ciphertext, tag };
}
function decryptChunk(ciphertext, tag, key, counter) {
const nonce = nonceFromCounter(counter);
const decipher = createDecipheriv("chacha20-poly1305", key, nonce, { authTagLength: TAG_SIZE });
decipher.setAuthTag(tag);
return Buffer.concat([decipher.update(ciphertext), decipher.final()]);
}
// Example usage
const key = randomBytes(32);
const chunk1 = Buffer.from("chunk-1 data...");
const enc1 = encryptChunk(chunk1, key, 1);
const dec1 = decryptChunk(enc1.ciphertext, enc1.tag, key, enc1.counter);
console.log(dec1.toString("utf-8"));
Why I like this:
- Counter‑based nonces are deterministic and easy to audit.
- Encryption is chunked and naturally stream‑friendly.
- Each chunk is authenticated, so corruption is detected immediately.
Error Behavior: What Actually Happens When Things Go Wrong
I find it helpful to explain failure modes in practical terms:
- With CBC, a single corrupted block breaks that block and usually the next one. That can cascade errors and make partial recovery harder.
- With CTR or stream ciphers, a single corrupted byte usually breaks only that byte on decryption. This is ideal for live media where you’d rather lose a frame than the whole stream.
- With AEAD modes (GCM, ChaCha20‑Poly1305), any tampering causes decryption to fail entirely. That’s a feature, not a bug. It prevents attackers from making controlled changes.
So I always align error behavior with product requirements. If partial data is useful, I might chunk and authenticate each chunk separately. That gives me integrity without turning a single error into a full‑stream outage.
Designing Around Authentication Tags
Authentication tags are not optional. They are the primary defense against manipulation. But they are also overhead. Here is how I think about them:
- Tags are usually 16 bytes. In tiny messages, this can be significant overhead.
- If you can afford it, always use full‑length tags.
- If bandwidth is extremely constrained, some modes allow smaller tags, but security is reduced. I only do this after a careful risk analysis.
A good practical pattern is to separate “transport format” from encryption. I define a simple message structure that includes:
- Version byte
- Nonce
- Ciphertext
- Tag
This keeps upgrades easy and avoids parsing mistakes.
Choosing Between AES‑GCM and ChaCha20‑Poly1305
In the modern world, this is the most common “block vs stream” decision. Here’s my simplified rubric:
- If you’re on servers with AES acceleration and need compliance‑friendly standards, use AES‑GCM.
- If you’re on mobile or embedded systems, or want consistent performance across platforms, use ChaCha20‑Poly1305.
- If you can’t guarantee nonces, consider AES‑SIV or XChaCha20‑Poly1305.
The key point: both are excellent. The wrong choice is not picking the “slower” cipher; it’s picking a cipher that your team can’t use safely.
Migration Tips: Moving From Legacy Crypto
A lot of teams still have legacy choices in production: ECB, CBC without authentication, or even RC4. If you’re stuck with old systems, here’s how I usually approach migration:
- Wrap the old encryption in an authenticated outer layer (e.g., encrypt old ciphertext inside AES‑GCM). This is not perfect, but it buys time.
- Introduce versioned message formats so new data uses AEAD while old data is still readable.
- Build automated tests that decrypt a corpus of old data and verify that new encryptions round‑trip correctly.
Migration is hard, but it’s often easier than you think if you start with versioned formats.
Troubleshooting Checklist When Encryption Fails
If you’re debugging an encryption issue, these are my go‑to checks:
- Are the keys the correct length? (AES expects 128/192/256 bits; ChaCha20 expects 256 bits.)
- Are the nonces the correct length? (GCM: 12 bytes; ChaCha20‑Poly1305: 12 bytes.)
- Are you passing the same associated data to encrypt and decrypt?
- Are you reusing nonces by accident (restarts, counters not persisted, collisions)?
- Are you using the correct tag length and reading it consistently?
This checklist has saved me hours in production incidents.
Practical Next Steps for Your Projects
Here’s a short checklist I give to teams:
- Use an AEAD mode by default: AES‑GCM or ChaCha20‑Poly1305.
- Enforce nonce uniqueness at the API boundary.
- Store the nonce and auth tag alongside ciphertext.
- Use a modern KDF for password‑derived keys.
- Write tests for “wrong key,” “wrong nonce,” and “tampered ciphertext.”
Key Takeaways and How I’d Apply Them
When I step back, I don’t think of block and stream ciphers as rivals. I treat them as two ways to package a strong symmetric key into a secure system. The cipher itself is only part of the story; how you manage keys, nonces, and authentication is what actually determines safety.
If I had to boil down my approach today, it would be this:
- Pick an AEAD mode, not just a cipher.
- Make nonce safety a non‑negotiable part of your API.
- Match the cipher to your hardware and operational constraints.
- Prefer well‑tested libraries and standardized algorithms over “clever” custom designs.
If you follow those principles, the block‑vs‑stream decision becomes straightforward. And when you’re discussing the choice with teammates, auditors, or reviewers, you’ll have a clear, practical story: this is how the cipher behaves, this is why it’s safe, and this is how we avoid the common pitfalls.
That’s the difference that matters in real systems.
