Apple Cryptographer (Mid-Level) Interview Preparation Guide

Direct answer

Start from the decision the ritual has to produce, not the calendar slot. Invite only the people who can actually make or unblock that decision, not everyone with an interest in the topic. Set the cadence to match how fast the underlying work changes, and instrument the ritual itself so you can tell whether it is producing decisions or just producing a meeting.

Structured elaboration

1. Name the single output first. Before picking attendees or a cadence, write down the one decision or artifact the ritual exists to produce (for example, "which cross-team dependencies get prioritized this cycle"). If you cannot name it, you are designing a status meeting, not a working ritual.
2. Minimum viable roster. Invite decision-owners, not stakeholders who only want visibility. A rule of thumb: if someone in the room has to say "let me check with my team" before committing to anything, they are a proxy, not an owner, and the room is one person too big.
3. Cadence tied to decision half-life. Match the frequency to how fast the thing being decided actually changes, not to habit. Too frequent and there is nothing new to decide between sessions; too infrequent and blockers age past the point where the ritual could have caught them early.
4. Session shape. Require light pre-work (so room time is spent deciding, not getting everyone up to speed), time-box the agenda to the decision at hand, and keep a running decision log so the group is not re-litigating the same question every time.
5. How you would know it is working (leading indicators, not attendance):

Worked example

Say the ritual is a recurring dependency review for a platform initiative touching four delivery teams. The roster is the four team leads plus the program owner as facilitator, five to six people, not the fifteen who are merely affected. The teams plan in two-week sprints, so a dependency raised today needs to be resolved before the next sprint's planning starts or it blocks that team. That reasoning sets the floor: the review has to run at least once per sprint, so biweekly, thirty minutes, is the minimum cadence that keeps blockers from aging past one planning cycle. A weekly cadence would mean showing up with nothing new most weeks; a monthly one would let a blocker sit for up to two sprints before anyone with authority to fix it even hears about it.

Trade-offs & pitfalls

• The most common wrong turn is defaulting the invite list to "everyone affected." The ritual becomes a broadcast, decision-owners tune out because nothing gets decided with fifteen people in the room, and the ritual quietly becomes theater.
• Choosing cadence by convention ("let's do it weekly like standup") instead of the decision's actual refresh rate produces either a hollow meeting or a slow one, and both erode trust in the ritual over time.
• Junior candidates describe running the meeting well. Senior candidates describe designing the meeting so it can be evaluated and retired: a built-in check for whether it is still adding value, and a plan for what replaces it if it is not.
• Skipping the decision log is a quiet failure mode: without a record of what was already decided and why, the group re-opens the same debate every session and the ritual's real cost shows up as fatigue, not as an obvious complaint.

Direct answer
Two well-chosen SMART goals for a mentee should target different dimensions, not two flavors of the same gap, typically one concrete skill or output gap and one behavioral or collaboration gap, each tied to real upcoming work (not an abstract exercise) with a defined timeframe and a way to verify progress that isn't just your own impression.

Structured elaboration

Picking the goals

• Start from an actual observed gap, not a generic template. Watch the person's real work for a pattern (recurring rework in reviews, difficulty scoping ambiguous tasks, avoiding certain kinds of conversations) rather than picking goals off a checklist.
• Pick goals from different dimensions on purpose. Two goals that are both "write better code" don't cover as much ground as one technical goal and one collaboration or communication goal; below-the-bar performance and stalled growth are rarely single-dimensional.
• Anchor each goal to real, upcoming work rather than an artificial exercise, so achieving it has actual value beyond the goal itself.

Making them SMART without making them hollow

• Specific: named against a real, current gap, not a generic aspiration ("get better at code review" is weak; "flag the two or three highest-risk issues in a review instead of commenting on every minor style choice" is usable).
• Measurable: defined by evidence you can point to later, not a feeling. This doesn't require an invented precision metric; "the last three reviews they gave focused on real risk rather than style nits" is legitimate evidence.
• Achievable: a real stretch, not guaranteed, but genuinely possible in the timeframe given their current level.
• Relevant: tied to what actually matters for their next step, not an arbitrary skill.
• Time-bound: a defined window, short enough to check in on meaningfully, long enough for real practice to happen.

Verifying they were met

Verification should come from something observable in the work itself, ideally corroborated by someone other than just you (a peer's comment, a second reviewer's read), not solely your own subjective sense that things feel better.

Worked example

Situation

A mentee was technically solid but had two recurring gaps: their code reviews tended to focus on minor style points while missing the real risk in a change, and they rarely spoke up in group design discussions even when they clearly had a relevant opinion afterward.

The two goals

1. Review focus: over the next 6 weeks, shift their code review comments toward flagging genuine risk (correctness, edge cases, design concerns) rather than style, verified by a second reviewer independently agreeing their flagged issues were the real risk areas in at least the majority of reviews they gave in that window.
2. Speaking up in design discussions: over the next 8 weeks, raise at least one substantive point live in a design discussion, rather than only afterward privately, verified simply by whether it happened and by a peer noticing the shift unprompted.

Why these two, not two code-quality goals

Picking a technical goal and a behavioral goal together addressed two independent gaps at once, rather than doubling down on the dimension that was already their relative strength.

Result

Both goals gave something concrete to check in on during regular 1:1s, and both had a verification method that didn't rely purely on my own impression, which mattered for making the conversation feel objective rather than a subjective judgment.

Trade-offs & pitfalls

• Goals that sound measurable but aren't actually verifiable. "Be more proactive" dressed up with a number attached is still not a real SMART goal if there's no real way to check it.
• Two goals in the same dimension. Picking two technical goals, or two soft-skill goals, leaves a real gap uncovered and wastes the opportunity a second goal represents.
• Goals set without the mentee's buy-in. A goal the mentee didn't help shape, or doesn't actually agree reflects a real gap, is much less likely to stick, even if it's technically well-formed.
• No connection to real work. An artificial exercise goal ("complete this course") is weaker evidence of growth than a goal embedded in work they were doing anyway.

Direct answer

Common Vulnerability Scoring System (CVSS) and DREAD (Damage potential, Reproducibility, Exploitability, Affected users, Discoverability) answer different questions, CVSS is a standardized technical severity score, DREAD is a lightweight, team-scored relative-priority tool, and neither alone tells you whether something is actually likely to be attacked. A modern addition, the Exploit Prediction Scoring System (EPSS), closes that specific gap by estimating the probability of real-world exploitation. The strongest practice combines a standardized severity or exploitability signal with an organization-specific business-impact rating, then presents that combination differently to technical and business audiences rather than reporting the same raw number to both.

Structured elaboration

CVSS. A standardized, vendor-neutral score from 0 to 10, maintained by the Forum of Incident Response and Security Teams (FIRST), based on exploitability and impact metrics: attack vector, attack complexity, privileges required, user interaction, scope, and impact on confidentiality, integrity, and availability for the base score, with optional temporal and environmental metric groups that adjust the score for real-world exploit maturity and the specific deployment context. Strengths: standardized and widely adopted, giving a shared, comparable vocabulary across security teams, vendors, and researchers, and technically precise about exploit mechanics. Weaknesses: the base score alone does not reflect the actual likelihood of exploitation against a specific system or the asset's business importance, so a 9.8 against an internal system with no interesting data can rank the same as a 9.8 against a crown-jewel payment system unless the environmental metrics are actually used, which many organizations skip, and speaking a raw CVSS number directly to business stakeholders does not naturally translate into a business decision without added context.

DREAD. Each of the five factors, damage potential, reproducibility, exploitability, affected users, and discoverability, is rated on a scale and combined, commonly averaged, into a single relative score. It was originally developed for lightweight, rater-driven relative prioritization rather than as a standardized industry benchmark. Strengths: simple and fast to apply, and each of its five factors is easy to explain in plain language, how bad, how repeatable, how hard to pull off, how many affected, how easy to find, which can actually make it more approachable to a mixed audience than CVSS's more technical metric vocabulary. Weaknesses: subjective, since ratings depend heavily on who is scoring, unlike CVSS's more structured metric definitions, so scores from different raters or teams are not reliably comparable to each other, and it lacks CVSS's broad industry standardization, a DREAD score is really only meaningful within one team's own consistent rating practice, not across organizations or against externally published scores.

A modern alternative: EPSS. A data-driven score estimating the probability that a vulnerability will actually be exploited in the wild within a near-term window, based on observed exploitation activity and vulnerability characteristics, also maintained by FIRST. Strength: it directly addresses CVSS's biggest practical gap, distinguishing "severe if exploited" from "likely to actually be exploited," the same realized-risk signal that matters for prioritizing a large backlog of findings. Weakness: it is a probability of exploitation, not a measure of impact to a specific organization, so it needs to be combined with asset criticality or business impact rather than used alone. The broader best practice, regardless of which specific score, is to combine a standardized technical or exploitability signal (CVSS and, where available, EPSS) with an organization-specific business-impact rating, rather than relying on any single score as a complete answer.

Choosing and combining scores for two audiences. For technical stakeholders, engineers and security analysts, lead with the standardized, precise scores: CVSS's metric breakdown to explain exactly why something is severe, which specific vector, what privilege is needed, and, where relevant, EPSS or observed-exploitation status to explain urgency. This audience wants the mechanism, not just a label. For business stakeholders, executives, product, or compliance leadership, translate the same underlying findings into business terms: likelihood expressed as "how likely, in plain terms, and why" rather than a raw percentage, and impact expressed in terms the business already tracks, regulatory exposure, customer-facing downtime, or a financial-loss magnitude tier, rather than a confidentiality, integrity, and availability breakdown. A small number of prioritized tiers, critical, high, medium, low, communicates far better to this audience than the underlying numeric scores themselves. The bridge between the two: maintain one underlying scoring approach and present two views of it, a detailed technical view for engineers and a summarized tiered view for business stakeholders, rather than two disconnected narratives that can drift apart or contradict each other when someone compares them.

Worked example

(Illustrative scenario, not a specific published vulnerability.) Consider a hypothetical flaw in a cryptographic library: a weak pseudo-random number generator used for session-key generation, producing predictable keys under specific conditions.

CVSS v3.1 (illustrative): the flaw is reachable over the network, needs no privileges and no user interaction, and breaks the confidentiality of session data without directly altering it, which is the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N and a base score of 7.5. Quote the vector, not just the number: the vector is what makes the score reproducible by anyone who wants to recompute it, and it is exactly the mechanism-level detail the technical audience below is asking for.

DREAD (illustrative, each factor rated 1-10, then averaged): Damage 8 (compromised session keys enable session hijacking); Reproducibility 6 (requires specific, not universal, conditions to trigger predictable output); Exploitability 7 (once conditions are known, exploitation is straightforward); Affected users 9 (affects any session using the library under the vulnerable configuration); Discoverability 5 (requires cryptographic analysis to notice, not immediately obvious from black-box testing).

EPSS (illustrative): a low-to-moderate initial exploitation probability, since weaponizing the flaw requires cryptographic expertise, flagged for ongoing re-monitoring because EPSS updates as real-world exploitation activity is observed, and a public proof-of-concept would likely raise it quickly.

To technical stakeholders: "CVSS 7.5, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, so network-reachable, low complexity, no privileges needed, breaking confidentiality via predictable session-key generation; exploitation probability currently low but expected to rise if a public proof-of-concept for the random-number-generator weakness appears."

To business stakeholders: "A high-severity flaw in how we generate session keys could let an attacker hijack user sessions under specific conditions. Current real-world exploitation likelihood is low but could rise quickly, and because this touches every session across the platform, we are prioritizing a fix within the critical remediation window rather than the normal patch cycle."

Trade-offs and pitfalls

Reporting a raw DREAD or CVSS number to business stakeholders with no translation is a common failure; "it's a 7.0" means nothing to someone who does not work with the scale daily, and repeatedly doing this trains business stakeholders to tune out security reporting entirely. Relying on CVSS base score alone for prioritization, ignoring exploitation evidence and business impact, systematically over-invests in high-severity-but-unlikely findings and under-invests in moderate-severity-but-actively-exploited ones. DREAD's subjectivity means using it for cross-team or cross-organization comparison, for example benchmarking one team's DREAD scores against a vendor's, is not meaningful; it is only self-consistent within one team's own disciplined rating practice. For cryptographic findings specifically, discoverability and exploitability ratings can be systematically mis-scored by raters without cryptographic expertise, rating a subtle cryptographic weakness as hard to discover and low priority when it is actually well known in the cryptographic research community, so pull in genuine cryptographic expertise for that specific factor rather than defaulting to a generalist's intuition.

Direct answer

Modeling an authentication or secrecy goal in ProVerif or Tamarin means writing down the protocol as a precise set of processes or rules, an explicit attacker model, and a formal query or lemma stating the property you want checked, then letting the tool exhaustively search for a way to violate it; the tool's output is either a proof that no such violation exists (within what was modeled) or an attack trace showing exactly how the property fails. The most common source of a wrong result is not a bug in the tool, it is a mismatch between what you actually modeled and what the real protocol does.

Structured elaboration

Modeling message syntax. Both tools require the protocol's messages to be described as terms built from a fixed set of function symbols, encryption, signing, pairing, hashing, together with an equational theory stating what an honest participant (and, implicitly, an attacker) can compute from those terms, for example that decrypting an encrypted value with the matching key recovers the plaintext. ProVerif expresses protocol roles as processes in an applied-pi-calculus-style language (the pi calculus is a small language built specifically for describing communicating, concurrent processes; "applied" means it is extended with data terms, so a process can build and take apart real messages using encryption, pairing, and hashing rather than only passing around opaque names); Tamarin expresses them as multiset rewrite rules describing how the global system state changes as each protocol step fires.

Modeling agent processes. Each protocol role, an initiator, a responder, a trusted server if one exists, is written as a process (ProVerif) or a set of rules (Tamarin) that a participant can execute, typically allowing an unbounded number of concurrent sessions in any role, since a real deployment does not run just one session at a time and some attacks, like the Needham-Schroeder relay attack, only appear when multiple sessions can interleave.

Modeling attacker capabilities. Both tools default to the Dolev-Yao model: an attacker with complete control of the network, able to intercept, block, reorder, duplicate, and inject any message it can construct from what it currently knows, but unable to break the underlying cryptographic primitives themselves (it cannot decrypt without the key, cannot forge a signature without the private key). This is a deliberately pessimistic, worst-case network attacker, not a cryptanalyst, the equational theory is what encodes "the primitives are assumed to be perfect."

Queries and lemmas. In ProVerif, a secrecy goal is a query like query attacker(secret_value), asking whether the attacker can ever learn that term, and an authentication goal is typically a correspondence assertion, event(ResponderFinished(x)) ==> event(InitiatorStarted(x)), meaning any time the responder believes it finished a session with some peer, that peer must have genuinely started one. In Tamarin, the same kinds of properties are expressed as lemmas in a guarded first-order logic over the sequence of actions (a trace: "first-order logic" here just means statements built with "for all" and "there exists" quantifiers over the events in that trace, for example "for every ResponderFinished event there exists an earlier InitiatorStarted event with the same nonce"; "guarded" restricts how those quantifiers can be combined so the logic stays decidable enough for automated search), often as an injective correspondence, which additionally requires a one-to-one matching between events rather than merely "at least one," ruling out an attacker satisfying the property by replaying a single genuine run against many claimed completions.

Interpreting output. ProVerif returns one of: the query is true (proved, no attack exists under the model), the query is false (an attack trace is printed, a concrete sequence of attacker actions violating the property), or "cannot be proved," meaning its resolution-based proof procedure (an automated-theorem-proving search that repeatedly combines the Horn-clause facts derivable from your model, trying to either derive the query or derive a contradiction with it) could not settle the question either way, which is not the same as "insecure." Tamarin either finds a proof, finds an attack trace, or fails to terminate, since the underlying verification problem is undecidable in general; open cases often require adding auxiliary "helper" or "sources" lemmas to guide the search, or switching to Tamarin's interactive mode to manually resolve the branches the automated search could not close.

Worked example

A concrete model, end to end. Take a two-message shared-key handshake: the initiator sends a fresh nonce encrypted under a long-term shared key k, and the responder echoes that nonce back together with its own fresh nonce nb, still encrypted under k; a real deployment might use nb to seed a session key, so its secrecy is worth checking. In ProVerif's applied-pi syntax, with concrete constants instead of placeholders, this is:

free c: channel.
type key.
fun senc(bitstring, key): bitstring.
reduc forall m: bitstring, k: key; sdec(senc(m, k), k) = m.

event InitiatorStarted(bitstring).
event ResponderFinished(bitstring).

let Initiator(k: key) =
    new na: bitstring;
    event InitiatorStarted(na);
    out(c, senc(na, k)).

let Responder(k: key) =
    in(c, msg1: bitstring);
    let na2 = sdec(msg1, k) in
    new nb: bitstring;
    event ResponderFinished(na2);
    out(c, senc((na2, nb), k)).

process
    new k: key;
    ( !Initiator(k) | !Responder(k) )

Three queries get asked of this model: query attacker(nb) (can the attacker ever learn the responder's fresh value), the plain correspondence from the Queries and lemmas section above (event(ResponderFinished(na)) ==> event(InitiatorStarted(na))), and its injective form (inj-event on both sides), which additionally requires a one-to-one match rather than merely "at least one." Reasoning through the model by hand: k is never sent on the wire and the only way to produce a term the attacker could pass off as senc(_, k) is to already hold k, so attacker(nb) is unsatisfiable and the plain correspondence holds too, every ResponderFinished(na) really does have a genuine InitiatorStarted(na) somewhere earlier in the trace. The injective correspondence is a different story: because Responder never checks whether it has already seen a given na before, an attacker who intercepts message 1 (senc(na, k)) can simply resend that exact captured bitstring to a fresh instance of Responder later on. That instance decrypts it successfully (same k), generates its own fresh nb, and fires a second ResponderFinished(na), an event with no second matching InitiatorStarted(na) behind it, since only one initiator session ever produced that na. That is precisely the attack trace the tool would report for the injective query: a replay, not a forged message, breaking the "exactly one" guarantee while leaving secrecy and the plain correspondence untouched. The same two rules, in Tamarin's shape, need one addition ProVerif's single new k: key; gave for free: a rule that actually generates the shared key and hands it to both roles, since a fresh-sorted Tamarin variable has to come from a Fr() premise before it can appear anywhere else, including a rule's own conclusion:

rule Setup_key:
  [ Fr(~k) ] --> [ !Ltk(~k) ]

rule Initiator_1:
  [ !Ltk(~k), Fr(~na) ] --[ InitiatorStarted(~na) ]-> [ Out(senc(~na, ~k)) ]

rule Responder_1:
  [ !Ltk(~k), In(senc(na, ~k)), Fr(~nb) ] --[ ResponderFinished(na) ]-> [ Out(senc(<na, ~nb>, ~k)) ]

Setup_key fires once, generating ~k via Fr(~k) and depositing it in a persistent fact !Ltk(~k) (the ! means the fact is not consumed when read, so every Initiator_1 and Responder_1 instance can take it as a premise without exhausting it). This is not a stylistic choice: a bare ~k written directly into Initiator_1's conclusion with no Fr(~k)-sourced premise anywhere in that rule is not legal Tamarin, since every fresh name occurring in a rule's conclusion must also occur in that rule's premises, and naming a variable ~k the same way in two separately-defined rules does not by itself make them share a value, only a fact flowing from one rule's conclusion into another's premise does that. Routing both roles through !Ltk(~k) is what actually ties every Initiator_1 and Responder_1 instance to the same long-term key. With that in place, a secrecy lemma over reachable states and an injective-correspondence lemma matching the queries above behave exactly as in ProVerif: the same replay produces the same attack trace, because nothing in Responder_1 checks freshness of an incoming na either. The fix in both models is the same: give the responder rule a way to reject an na it has already accepted, exactly the kind of state the injective query exists to force you to think about explicitly, rather than something you would notice from reading the message-sequence diagram alone.

A common, concrete modeling pitfall: ProVerif's core verification technique is based on an OVER-approximation of the protocol (it abstracts away exactly how many times a rule has fired, tracking only what facts are derivable), which means ProVerif is sound for a positive secrecy result, if it says a secret stays secret, it genuinely does, but it can also report a spurious attack trace that does not correspond to any real, reachable execution, because the abstraction lost the correlation between session instances that the real protocol would have preserved. A practitioner who gets an attack trace from ProVerif has to manually check whether it is a genuine finding or an artifact of that abstraction before concluding the protocol is actually broken. Tamarin's multiset-rewriting model is more precise about state and avoids this specific false-positive class, but pays for it with search termination problems on complex protocols, an under-specified or overly permissive equational theory there (for example, modeling an operation as fully invertible when the real primitive only partially is) can instead produce a false NEGATIVE, the tool proves security under a theory that is quietly more forgiving to the attacker's own use of that operation than reality, or less forgiving, hiding a real attack.

Trade-offs and pitfalls

The single biggest practical pitfall across both tools is treating "the tool did not find an attack" as equivalent to "the protocol is secure," when it may instead mean the search did not terminate (Tamarin), the resolution procedure could not settle the query (ProVerif's "cannot be proved" outcome), or, most subtly, the model itself does not actually match the real protocol, an omitted attacker capability, an over-restrictive equational theory, or a session-bound assumption that does not hold in the real unbounded-session deployment all produce a clean-looking proof that says nothing true about the actual implementation. Getting real value out of either tool requires treating the modeling step itself as the primary source of risk, not an afterthought before "the interesting part."

Direct answer

For a large, dynamic group (thousands of members, frequent joins and leaves), a balanced ratchet tree, the design used by TreeKEM inside MLS (Messaging Layer Security, IETF (Internet Engineering Task Force) RFC 9420), gives $O(\log_2 n)$ message size and per-member computation for both a join and a leave, versus $O(n-1)$ for a naive broadcast KEM (key encapsulation mechanism, a public-key primitive that produces a fresh symmetric key together with a ciphertext that only the intended recipient's private key can open) that must re-encapsulate a fresh group key directly to every remaining member. Contributory security (every active member's own randomness feeds the eventual key, not just a controller's) and forward secrecy on leave both fall out of the same mechanism: every member holds the secrets along its own leaf-to-root path, and a single "commit" operation refreshes every secret on the path that changed, so a former member who no longer has a leaf cannot derive anything past that point. Broadcast KEM stays the simpler, lower-latency choice for small or slowly-changing groups, or for genuinely one-to-many "trusted server pushes content" cases where contributory security is not required; it does not scale efficiently to large, high-churn membership without added subset-cover machinery that itself gives up most of the contributory property.

Structured elaboration

Definitions first. Contributory key agreement means the final group key is a function of contributions from every currently active member, not something one controller can unilaterally pick and hand out. Forward secrecy for a group means a member who has left cannot decrypt messages sent after their removal. Post-compromise security (a related but separate property, worth naming since group protocols get asked about both) means a member who was temporarily compromised recovers security once ordinary rekeying continues, without needing to detect or announce the compromise.

Tree-based (TreeKEM / MLS). Members sit at the leaves of a binary tree; every internal node holds a secret derived from its two children by a KDF (key-derivation function) chain. When one member updates (a join adds a leaf, a leave blanks one), only the nodes on that leaf's path to the root need a fresh secret. The committing member re-derives each of those path secrets bottom-up and, for each node on the co-path (the sibling of each path node), encrypts the new secret under that sibling subtree's existing public key (an HPKE, Hybrid Public Key Encryption, ciphertext per co-path node), so only members who need that particular secret can read it. Message size and each receiving member's decryption work are both proportional to the tree height, $O(\log_2 n)$.

Broadcast KEM. A sender (a designated controller, or whoever is performing the membership change) encapsulates a fresh group key directly under every current member's own public key, or under a subset-cover structure such as a logical key hierarchy (LKH, itself essentially a fixed, centrally-managed key tree). A join or leave that must exclude or include exactly one member's key, done naively, means re-encapsulating to every one of the other $n-1$ members so the group key changes under everyone else, $O(n-1)$ ciphertexts. Subset-cover techniques can reduce the sender's work below $O(n)$ at the cost of larger ciphertexts and protocol complexity, but the design remains sender-driven rather than contributory.

Join complexity. TreeKEM: add a leaf, the new member receives the current path secrets it needs (typically via a separate "welcome" message containing the current tree's public state, not the O(log n) path update itself, since it has no prior path secrets to update); existing members whose path intersects the new leaf's insertion point update $O(\log_2 n)$ secrets. Broadcast KEM: add the new member's key to the sender's encapsulation target set, and if the new member should not read history, rotate the group key immediately, touching the full sender-side key material.

Leave complexity. TreeKEM: blank the departing leaf; on the next commit, the remover refreshes the $O(\log_2 n)$ ancestor secrets on that leaf's former path, and every surviving member updates only the portion of its own path that changed. Broadcast KEM: naively exclude that member's key from the next encapsulation, which means re-encrypting to all remaining $n-1$ members, $O(n-1)$; a subset-cover scheme trades that down for message-size and complexity overhead.

Worked example

A concrete tree update, then the general cost table, both computed rather than asserted:

import hmac, hashlib, math

def ratchet(secret, label):
    return hmac.new(secret, label, hashlib.sha256).digest()[:16]

def direct_and_copath(n_leaves, leaf):
    levels = int(math.log2(n_leaves))
    direct, copath, idx = [], [], leaf
    for lvl in range(levels):
        copath.append((lvl, idx ^ 1))
        idx //= 2
        direct.append((lvl + 1, idx))
    return direct, copath

# trace one leaf update on an 8-member tree
direct, copath = direct_and_copath(8, leaf=3)
secret = b"toy-commit-secret"
print("Updating leaf 3 in an 8-member ratchet tree:")
for lvl, node in direct:
    secret = ratchet(secret, f"node-{lvl}-{node}".encode())
    print(f"  refresh path node (level {lvl}, index {node}): new secret = {secret.hex()}")
print(f"  co-path nodes each receiving one encrypted secret: {copath}")
print(f"  direct-path updates = {len(direct)} = log2(8) = {int(math.log2(8))}")

print()
print(f"{'members (n)':>12} | {'TreeKEM/MLS: O(log2 n)':>24} | {'naive broadcast: O(n-1)':>24}")
for n in (8, 128, 1024, 8192, 65536):
    print(f"{n:>12} | {int(math.log2(n)):>24} | {n - 1:>24}")

Output:

Updating leaf 3 in an 8-member ratchet tree:
  refresh path node (level 1, index 1): new secret = deef31cf87b73d8f10a22cc61e372705
  refresh path node (level 2, index 0): new secret = b914e4bedc78d34d8a1a79826a24e16a
  refresh path node (level 3, index 0): new secret = 5b88907c11b4855c55c4e70de7247321
  co-path nodes each receiving one encrypted secret: [(0, 2), (1, 0), (2, 1)]
  direct-path updates = 3 = log2(8) = 3

 members (n) |   TreeKEM/MLS: O(log2 n) |  naive broadcast: O(n-1)
           8 |                        3 |                        7
         128 |                        7 |                      127
        1024 |                       10 |                     1023
        8192 |                       13 |                     8191
       65536 |                       16 |                    65535

Reading this: updating leaf 3 in an 8-member tree touches exactly 3 path nodes and sends exactly 3 encrypted co-path secrets, matching $\log_2 8 = 3$ exactly, not approximately. The cost table then generalizes the same arithmetic to realistic group sizes: at 8,192 members, TreeKEM-style rekeying touches 13 nodes per membership change while naive broadcast re-encapsulation touches 8,191, a gap that only widens as the group grows, which is the whole reason a "thousands of members" requirement rules out the broadcast approach on its own.

Trade-offs and pitfalls

• $O(\log_2 n)$ is the cost of a single commit; concurrent membership changes from different members need to be serialized (MLS delegates this ordering to an external, non-cryptographic "Delivery Service"), and assuming the cryptographic protocol alone solves conflict resolution and ordering is a common design mistake.
• A member who has been offline through several commits cannot cheaply "catch up": correctly re-synchronizing to the current epoch can cost as much as replaying every intervening commit or fetching a full welcome, so the $O(\log_2 n)$ figure is a best case that assumes members stay roughly current, not an unconditional guarantee.
• Broadcast KEM is not obsolete: for a group that stays under a few dozen members and rarely churns, or a genuinely one-to-many content-distribution case with a trusted sender, adopting full TreeKEM/MLS machinery is unwarranted complexity for no measurable benefit. Some real systems deliberately mix the two: a tree-based group for the actively contributing membership plus a broadcast layer for read-only observers who do not need contributory guarantees.
• "Forward secrecy on leave" is not retroactive and not instantaneous: it protects epochs starting from the next completed commit onward. If the remover does not actually complete and distribute a fresh commit before further messages are sent, the removed member's exclusion has not taken effect yet, a gap that is easy to overlook when reasoning about removal as if it were atomic with the decision to remove.

Direct answer

Both encrypt-then-MAC (AES-CBC plus a separately computed HMAC) and a dedicated AEAD cipher
like AES-GCM protect confidentiality and integrity together, but AEAD bundles them into one
call with one failure mode to get right, while encrypt-then-MAC is two separate primitives you
must sequence correctly yourself. For a new HTTP API payload, AES-GCM is the default choice
unless there's a specific reason to prefer the older combination.

Structured elaboration

• Performance and hardware acceleration: AES-GCM benefits from dedicated CPU instructions
  (AES-NI plus carryless multiplication for the authentication step), making it very fast on
  essentially all modern server and mobile hardware. Encrypt-then-MAC with AES-CBC plus HMAC
  requires two separate passes over the data (one for the cipher, one for the MAC), roughly
  doubling the work, though both individual pieces can still be hardware-accelerated.
• Streaming support: HMAC can be updated incrementally as data arrives, since it just
  needs the full message to compute a final digest, which suits streaming reasonably well.
  AES-GCM also supports incremental processing but has an internal limit on how much data one
  nonce can safely encrypt before the underlying counter risks exhaustion; for very large or
  long-lived streams under one key, that limit needs to be tracked.
• IV/nonce requirements: CBC needs an unpredictable IV per message (repetition leaks
  structure but is not immediately catastrophic). GCM needs a nonce that is never reused
  under the same key (repetition is catastrophic: see the nonce-reuse mechanics above, up to
  full key-material exposure).
• Where each is more likely to be implemented incorrectly: encrypt-then-MAC has several
  places to get wrong: MAC-then-encrypt or encrypt-and-MAC (rather than encrypt-then-MAC)
  order can reopen padding-oracle-style attacks; the MAC comparison must be constant-time to
  avoid a timing oracle; padding itself must be handled carefully. AES-GCM collapses most of
  that into a single library call, but concentrates all the risk into one rule: never reuse a
  nonce. In distributed services, where many stateless instances encrypt independently under
  a shared key, coordinating nonce uniqueness (a monotonic counter plus a per-instance ID, or
  purely random 96-bit nonces) becomes the operational version of the same problem, and it is
  what drives the key-rotation volume worked out below. A cipher with a larger nonce space,
  like XChaCha20-Poly1305's 192-bit nonce, removes that
  practical ceiling by making random-nonce collisions negligible even at very high message
  volumes.

Worked example

Take NIST's rule of thumb that a random 96-bit nonce under one key should be retired once
roughly 2^32 messages have been encrypted. That 2^32 is NIST's deliberately conservative
invocation limit, chosen to keep the IV-collision probability down around 2^-32 to 2^-33; it
sits far below the true birthday bound of 2^48 (the square root of the 96-bit space, the point
where the chance of some collision reaches about 50 percent). 2^32 = 4,294,967,296. A service encrypting 10 million API payloads per day reaches
that count in 4,294,967,296 / 10,000,000 ≈ 429.5 days, a little over a year. That is a
concrete, calendar-relevant reason to build key rotation into the design up front rather than
treating AES-GCM as "safe forever" once it is wired up.

Trade-offs & pitfalls

• If you must support encrypt-then-MAC (say, for interoperability with an existing system),
  the order matters: authenticate the ciphertext, not the plaintext, and use a
  constant-time comparison when checking the tag.
• "AEAD is simpler" does not mean "AEAD is foolproof"; it moves the single point of failure to
  nonce management, which still requires real design attention in a distributed system.

Direct answer

An improper MAC (message authentication code, a keyed checksum proving a message is both intact and genuinely from the holder of the key) verification leaks side-channel information whenever it processes or reacts to a message BEFORE the whole tag has been checked in constant time: checking pieces of a message as they arrive and stopping at the first bad one tells an attacker exactly where the corruption is, and comparing the computed tag to the supplied one with an ordinary byte-by-byte == that exits on the first mismatch leaks how many leading bytes matched. The correct approach buffers the full message, computes one MAC over the whole thing, and compares it to the supplied tag using a constant-time comparison that always inspects every byte regardless of where or whether they differ, then reports a single generic accept/reject outcome with no distinguishing detail.

Structured elaboration

Where the leak actually comes from

• Per-chunk early rejection: verifying and reacting to each chunk of a streamed message as it arrives, then stopping at the first invalid chunk, directly reveals the INDEX of the corrupted chunk through observable behavior (how much was processed, or a distinguishable error).
• Naive tag comparison: a hand-written loop that returns False as soon as it finds a differing byte does less work the earlier the mismatch occurs, which is exactly the kind of secret-dependent timing difference a constant-time comparison exists to remove.
• Both are instances of the same underlying mistake: letting the AMOUNT of matching work performed become a function of how much of the input was correct.

A correct constant-time verification approach

• Buffer the entire message (or the entire logical unit that the protocol authenticates as one thing) before verifying anything.
• Compute the expected tag over the buffered message and compare it to the supplied tag with a comparison function specifically designed to take the same amount of time and touch every byte regardless of where a mismatch occurs (Python's hmac.compare_digest, or the equivalent in any serious crypto library, XORs every byte pair and ORs the results together rather than short-circuiting on the first difference).
• Report exactly one outcome for every failure: reject, generically, with no detail about which byte, which chunk, or which check failed.

Trade-off between early rejection, full processing, and protocol-level handling

• Early rejection (verify and act per chunk): lowest memory footprint and lowest latency for a legitimate, unbounded stream, but it is the leakiest option and is only safe when each chunk carries its OWN independent authentication tag whose failure genuinely should not reveal anything about later chunks, which is rarely true for a message meant to be authenticated as a whole.
• Full processing (buffer everything, verify once): the safest default, since it collapses the entire message into a single constant-time decision, but it costs memory proportional to the largest message you are willing to accept, and it means legitimate work only starts after the full message has arrived, adding latency for large messages.
• Protocol-level error handling (e.g., TLS's, Transport Layer Security's, approach of a single generic bad_record_mac alert that immediately terminates the connection, rather than a byte- or field-specific error): pushes the "report one outcome" discipline up to the protocol layer itself, so even if an implementation bug leaks something at a lower layer, the observable behavior a remote peer actually sees stays uniform. This is the right complement to, not a replacement for, doing the comparison itself in constant time.

Worked example

import hmac

MAC_KEY = bytes(range(32))

def per_chunk_tag(chunk, index, key):
    return hmac.new(key, index.to_bytes(4, 'big') + chunk, digestmod='sha256').digest()

def whole_message_tag(message, key):
    return hmac.new(key, message, digestmod='sha256').digest()

def early_rejection_processor(chunks_with_tags, key):
    """BAD: verifies each chunk as it streams in, and stops at the FIRST chunk
    whose tag does not match, revealing exactly which one failed."""
    for i, (chunk, tag) in enumerate(chunks_with_tags):
        expected = per_chunk_tag(chunk, i, key)
        if not hmac.compare_digest(expected, tag):
            return f'rejected at chunk {i}'
    return 'accepted'

def full_processing_processor(chunks_with_tags, key):
    """GOOD: buffer the whole message, verify ONE mac over the concatenation in
    constant time, and report only a single generic outcome."""
    message = b''.join(chunk for chunk, _tag in chunks_with_tags)
    expected = whole_message_tag(message, key)
    supplied = chunks_with_tags[-1][1]  # protocol convention: final tag covers the whole frame
    if not hmac.compare_digest(expected, supplied):
        return None
    return message

raw_chunks = [b'HEADER--', b'PAYLOAD1', b'PAYLOAD2', b'PAYLOAD3']
tagged = [(c, per_chunk_tag(c, i, MAC_KEY)) for i, c in enumerate(raw_chunks)]

corrupt_at_2 = list(tagged)
bad = bytearray(corrupt_at_2[2][0]); bad[0] ^= 0x01
corrupt_at_2[2] = (bytes(bad), corrupt_at_2[2][1])
print('early_rejection_processor, corruption at chunk 2 ->', early_rejection_processor(corrupt_at_2, MAC_KEY))

corrupt_at_0 = list(tagged)
bad0 = bytearray(corrupt_at_0[0][0]); bad0[0] ^= 0x01
corrupt_at_0[0] = (bytes(bad0), corrupt_at_0[0][1])
print('early_rejection_processor, corruption at chunk 0 ->', early_rejection_processor(corrupt_at_0, MAC_KEY))

whole = b''.join(c for c, _ in tagged)
framed = tagged[:-1] + [(tagged[-1][0], whole_message_tag(whole, MAC_KEY))]

framed_corrupt2 = list(framed)
c2 = bytearray(framed_corrupt2[2][0]); c2[0] ^= 0x01
framed_corrupt2[2] = (bytes(c2), framed_corrupt2[2][1])
print('full_processing_processor, corruption at chunk 2 ->', full_processing_processor(framed_corrupt2, MAC_KEY))

framed_corrupt0 = list(framed)
c0 = bytearray(framed_corrupt0[0][0]); c0[0] ^= 0x01
framed_corrupt0[0] = (bytes(c0), framed_corrupt0[0][1])
print('full_processing_processor, corruption at chunk 0 ->', full_processing_processor(framed_corrupt0, MAC_KEY))

print('full_processing_processor, no corruption          ->', full_processing_processor(framed, MAC_KEY))

Output:

early_rejection_processor, corruption at chunk 2 -> rejected at chunk 2
early_rejection_processor, corruption at chunk 0 -> rejected at chunk 0
full_processing_processor, corruption at chunk 2 -> None
full_processing_processor, corruption at chunk 0 -> None
full_processing_processor, no corruption          -> b'HEADER--PAYLOAD1PAYLOAD2PAYLOAD3'

early_rejection_processor tells the caller exactly where the corruption was, chunk 2 versus chunk 0 produce visibly different results. full_processing_processor returns the identical None regardless of which chunk was corrupted, giving an attacker no positional signal at all.

Trade-offs and pitfalls

The most common pitfall is a protocol designed to be genuinely streamable (video, large file transfer) reaching for per-chunk verification purely for the latency win, without recognizing that each chunk needs its own independently meaningful security boundary for that to be safe, most authenticated-streaming designs actually solve this by chaining tags (each chunk's tag depends on the previous chunk's tag or an explicit sequence counter) so that a chunk can be rejected without revealing information about chunks the attacker has not sent yet, rather than by accepting arbitrary reordering. A second pitfall is assuming protocol-level generic error handling is a substitute for a constant-time comparison underneath it: a uniform bad_record_mac alert is worthless if the SERVER's internal comparison already spent a measurably different amount of time getting to that alert.

Role of randomness in asymmetric keys
Randomness provides unpredictability for private keys, nonces, and ephemeral secrets in key exchange (e.g., ECDH ephemeral private scalar). Without sufficient entropy, keys become guessable and protocols collapse.

CSPRNG properties

• Unpredictability: future outputs infeasible to predict from past.
• Forward secrecy: compromise of state should not reveal prior outputs.
• Backward secrecy (resilience): compromise shouldn't reveal future outputs after reseed.
• Uniformity and absence of bias.
• Resistance to state recovery (entropy stretching without leaking seed).

Entropy sources & seeding

• TRNGs: hardware sources (ring oscillators, jitter, photon counts) — high-quality raw entropy.
• OS sources: /dev/random, getrandom(), Windows CNG — mix in multiple sources (timers, interrupts) vetted by OS.
• Seeding strategy: collect sufficient min-entropy, mix using a vetted extractor (e.g., HKDF, SHA-256-based DRBG), seed CSPRNG at boot and reseed regularly from TRNG/OS entropy, protect seed in memory.

Consequences of weak randomness

• Predictable private keys, replayable nonces, broken signatures (e.g., repeated k in ECDSA leaks private key).
• System-wide compromise and undetectable backdoors.

Historical example
Debian OpenSSL (2006): a maintainer removed entropy-mixing code, shrinking keyspace and producing predictable SSH/TLS keys — millions of weak keys issued and required replacement.

My practical habit: use vetted primitives (NIST/DRBG or libsodium), ensure TRNG health checks, and enforce regular reseeding and key rotation.

Approach (high level)
Use per-device asymmetric keys in a hardware-protected root (TEE/SE), a signed one-time QR payload from factory, and a cloud PKI + challenge-response to prevent cloning and bind identity. Recovery uses multi-party escrow and authenticated out-of-band (OOB) approval.

Protocol (stepwise)

• Factory: for each device generate DeviceKeyPair (sk_D in SE, pk_D exported), create FactoryToken = { device_id, pk_D, expiry, nonce } signed by ManufacturerSK. Encode FactoryToken and a one-time ProvisioningSecret S (high-entropy random) into QR; print QR and store hashed S in manufacturer/cloud DB. QR marked single-use.
• Boot (offline): sealed image reads QR, SE imports nothing—SE uses internal key to sign a proof-of-possession of pk_D (or reveals pk_D via attestation). Device connects to cloud, sends FactoryToken, manufacturer signature, attestation statement from SE, and a challenge-response proving possession of S or sk_D. Cloud verifies manufacturer signature, checks one-time S hash, verifies attestation and freshness, then mints DeviceCertificate bound to cloud account and records pk_D.

Preventing QR cloning

• QR contains a one-time S and manufacturer signature over device_id+nonce; cloud marks S used on first successful provisioning.
• DeviceKeyPair protected in SE—an attacker cloning QR without SE cannot complete challenge-response or produce SE attestation.
• Use tamper-evident packaging and printing secure holographic markers to raise bar for physical cloning.

Identity binding

• Cloud issues X.509/ED25519 certificate for pk_D tied to user account after mutual attestation and optional user authentication (email/phone + OTP). Certificates include device_id and attestation claims.

Secure recovery if QR lost

• Multi-option recovery: (1) Account-based recovery: user authenticates to cloud (MFA) and requests issuance; cloud requires manufacturer attestation or proof from other enrolled devices. (2) Escrow: manufacturer stores encrypted recovery token K_enc = Enc( user_pubkey, K ) where K is wrapped with SE-protected key; release requires user OOB MFA plus manufacturer policy checks. (3) Hardware fallback: bring device to authorized service with physical attestation and manufacturer private approval.

Security considerations / properties

• Freshness: nonces + timestamps prevent replay.
• Forward secrecy: short-lived provisioning tokens; DeviceCertificate rotation.
• Compromise containment: revocation CRL/OCSP; mark S as used.
• Privacy: avoid embedding user-identifying info in QR; use linking only after cloud minting.

Rationale: asymmetric keys + SE attestation enforce that possession of QR alone is insufficient; one-time secret prevents replay/cloning; multi-factor recovery balances usability and security.

Direct answer

Encrypt and authenticate each chunk independently under a monotonic per-stream counter as the nonce (never reused, and needing no storage since sender and honest receiver both track it locally), and additionally maintain a running authenticator, a keyed hash chain over each chunk's authentication tag and position, computed with a key separate from the per-chunk AEAD (Authenticated Encryption with Associated Data) key. A receiver accepts chunk i only if it is exactly the next expected counter value, which is also the re-synchronization signal, and its AEAD tag verifies. The security argument reduces cleanly: any adversary who gets an honest receiver to accept a chunk that was not exactly what the sender produced has, by definition, forged a valid ciphertext-tag pair under the per-chunk AEAD scheme, so the stream's authenticity is exactly as strong as one chunk's AEAD security.

Structured elaboration

Algorithmic steps. Sender processes chunks m_1, m_2, ... in order. For chunk i: c_i, t_i = AEAD.Enc(K1, nonce=i, m_i, AD=stream_id||i), then update the running authenticator T_i = HMAC(K2, T_{i-1} || t_i || i) with T_0 a fixed initial value. Receiver expects the next counter value, decrypts and verifies the chunk's AEAD tag (rejecting on any mismatch), and independently recomputes the same running value from T_{i-1}.

The reduction argument. Define "forging the stream" as getting an honest receiver to accept a chunk at some position that differs from what the sender legitimately produced there. The receiver's accept condition strictly requires AEAD.Dec(K1, i, c', t', AD_i) to succeed for the adversary's ciphertext-tag pair (c', t') without raising an error. Since the adversary does not hold K1, producing such a pair is exactly a successful forgery against the single-chunk AEAD scheme's own integrity notion (INT-CTXT, integrity of ciphertexts): given only wire access to the sender's legitimate outputs, produce a new, valid ciphertext-tag pair the encryption oracle never actually output. This gives a direct reduction: an adversary that forges the stream with some probability, in some running time, yields an adversary against the underlying AEAD's INT-CTXT game with essentially the same probability and running time, by simulating the multi-chunk protocol with its own AEAD oracle for legitimate chunk generation and forwarding the attacker's final forged chunk as the AEAD forgery attempt. So the stream's forgery advantage is bounded by the per-chunk AEAD's own forgery advantage, up to a small additional term from the running authenticator itself being a secure PRF (pseudorandom function) or MAC.

What the running authenticator actually adds. The counter check alone, a receiver's own local state, already prevents reorder, duplication, and gaps at that receiver, and the worked example's forgery attempt is caught by the per-chunk AEAD tag directly, not by the chain. What the running authenticator buys on top is a portable transcript commitment: a value that lets a third party, or the receiver itself after the fact, verify that a claimed full transcript is authentic using only the final running value and the sequence of tags, without having watched the stream live or needing to re-decrypt every chunk's payload. That is useful for later audit or dispute resolution, and for a receiver that joins mid-stream wanting to verify a stored prefix cheaply; it is not the primary forgery defense, which the per-chunk AEAD tag already provides on its own.

Bounded memory. Both sides need only (expected counter, running authenticator value) between chunks, O(1) state regardless of how long the stream runs, and the sender needs only (counter, running authenticator, keys).

Re-synchronization after loss. Because the accept condition is strict, any gap, a chunk lost over a lossy real-time transport, halts the stream at the receiver by design. Real-time delivery over lossy transport needs an explicit resync mechanism layered on top: periodic checkpoint chunks carrying a freshly authenticated (counter, running authenticator) pair let a receiver that missed chunks jump to the next checkpoint, reset its expected state, and resume, at the honest cost of being unable to verify that the skipped chunks were never tampered with. That is a real, explicit availability-versus-verifiability trade-off: strict sequencing gives the strongest guarantee with zero loss tolerance, checkpointed resync trades verifiability of the skipped region for continued availability.

Worked example

import hmac as hmac_mod
import hashlib
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

K1 = bytes(range(32))   # AES-256-GCM key for per-chunk AEAD
K2 = bytes(range(32, 64))  # HMAC-SHA256 key for the running authenticator (PRF)
aesgcm = AESGCM(K1)
stream_id = b"stream-9"

def nonce_for(ctr: int) -> bytes:
    return ctr.to_bytes(12, "big")  # sender-side monotonic counter, never reused

def send_chunk(ctr, T_prev, m):
    ad = stream_id + ctr.to_bytes(8, "big")
    sealed = aesgcm.encrypt(nonce_for(ctr), m, ad)
    c, t = sealed[:-16], sealed[-16:]
    T = hmac_mod.new(K2, T_prev + t + ctr.to_bytes(8, "big"), hashlib.sha256).digest()
    return (ctr, c, t), T

def recv_chunk(ctr, c, t, T_prev, expect_ctr):
    if ctr != expect_ctr:
        raise ValueError("out-of-order / gap: needs resync")
    ad = stream_id + ctr.to_bytes(8, "big")
    m = aesgcm.decrypt(nonce_for(ctr), c + t, ad)  # fails on any tamper (AEAD integrity)
    T = hmac_mod.new(K2, T_prev + t + ctr.to_bytes(8, "big"), hashlib.sha256).digest()
    return m, T

messages = [b"chunk-A", b"chunk-B", b"chunk-C"]
T = hashlib.sha256(b"init").digest()
wire = []
for i, m in enumerate(messages, start=1):
    pkt, T = send_chunk(i, T, m)
    wire.append(pkt)
T_final_sender = T

# --- honest receiver reconstructs the same running authenticator ---
Tr = hashlib.sha256(b"init").digest()
recovered = []
expect = 1
for ctr, c, t in wire:
    m, Tr = recv_chunk(ctr, c, t, Tr, expect)
    recovered.append(m)
    expect += 1
print("round trip ok:", recovered == messages)
print("sender/receiver running authenticator agree:", Tr == T_final_sender)

# --- empirical support for the reduction: an adversary who does not hold K1 (chunk AEAD
# key) or K2 (chain PRF key) and tries to splice in a forged chunk fails, because forging
# EITHER the AEAD tag or the chain value requires breaking one of the two primitives ---
forged_wire = list(wire)
forged_ct, forged_tag = b"XXXXXXX", wire[1][2]  # attacker keeps the old (valid) AEAD tag,
forged_wire[1] = (wire[1][0], forged_ct, forged_tag)  # but swaps the ciphertext body

Tr2 = hashlib.sha256(b"init").digest()
ok = True
expect = 1
for ctr, c, t in forged_wire:
    try:
        m, Tr2 = recv_chunk(ctr, c, t, Tr2, expect)
    except Exception as e:
        print(f"forged chunk at position {ctr} rejected by AEAD integrity ({type(e).__name__}); "
              f"attacker could not have produced a valid tag for the new ciphertext without K1")
        ok = False
        break
    expect += 1
print("forgery blocked before it could corrupt the chain:", not ok)

Output:

round trip ok: True
sender/receiver running authenticator agree: True
forged chunk at position 2 rejected by AEAD integrity (InvalidTag); attacker could not have produced a valid tag for the new ciphertext without K1
forgery blocked before it could corrupt the chain: True

Trade-offs and pitfalls

The per-chunk AEAD tag is doing the actual forgery-prevention work, as the demonstration shows directly; do not design a deployment where the running-authenticator check runs but the per-chunk AEAD verification is accidentally skipped or short-circuited, since that would remove the real security guarantee and leave only a linkage mechanism with no independent forgery resistance of its own.

A monotonic counter as the nonce requires the sender to never reuse a counter value for a genuinely different chunk under the same key; after a sender-side crash or restart mid-stream, it must either know precisely where it left off or derive a fresh key per stream session so counters restart safely at zero under a new key rather than colliding with the previous session's counter space under the same key.

The real-time, bounded-memory requirement rules out any Merkle-tree-style construction, which wants the full transcript or at least a large lookahead window to build. The chained, counter-based design here is the right shape specifically because it needs no lookahead, at the cost of no true random access mid-stream, which the question's own framing, a continuous, real-time stream, already signals is the correct trade to accept, in contrast with a bounded file where random access matters more and a different construction earns its keep.