A secret chosen uniformly from A possibilities, L times over, carries

H = L log₂ A bits,   expected guesses = 2^H−1,   time = guesses × cost per guess

Why half the space. If the secret is equally likely to be any of 2^H values, a searcher who tries them in any order finds it, on average, halfway through. Why PBKDF2's cost is linear. Each of its c iterations is one HMAC-SHA-256 on 32 bytes, and each depends on the one before, so the work is c times one HMAC and cannot be split up for one guess.

Words against rounds. One more diceware word multiplies the space by 7,776, which is log₂ 7,776 = 12.925 bits. Doubling the iterations doubles the cost of every guess, which is worth exactly 1 bit. Iterations buy a constant factor; entropy buys an exponent.

C_i = P_i ⊕ E_K(counter_i),   counter₁ = J₀ + 1,   J₀ = IV ‖ 0³¹1

tag = E_K(J₀) ⊕ GHASH_H(A, C),   H = E_K(0¹²⁸)

X₀ = 0,   X_i = (X_i−1 ⊕ B_i) · H   in GF(2¹²⁸) modulo x¹²⁸ + x⁷ + x² + x + 1

Why a flipped bit survives counter mode. XOR is its own inverse: P = C ⊕ keystream, so flipping bit j of C flips bit j of P and nothing else. Counter mode hides, it does not protect. Why GCM catches it. The blocks B₁ … B_m (the AAD, the ciphertext, then one block of both lengths) are the coefficients of a polynomial evaluated at the secret point H by Horner's rule. A change to any block changes the polynomial, and a polynomial of degree m has at most m roots, so a forged record passes with probability at most about m / 2¹²⁸.

Multiplication in the field. Blocks are polynomials over bits; adding is XOR, multiplying is shift-and-XOR, and every time the degree reaches 128 the field polynomial folds it back. The code here does that 128 times per block and must land on the browser's tag exactly.

C₁ ⊕ C₂ = (P₁ ⊕ S) ⊕ (P₂ ⊕ S) = P₁ ⊕ P₂

P(repeat) = 1 − ∏_i=0ⁿ⁻¹ (1 − i / 2^b)  ≈  1 − exp(−n(n−1) / 2^b+1)  ≈  n² / 2^b+1

Why the product. The i-th nonce must miss the i already drawn, which it does with probability 1 − i/2^b, and the draws are independent. Why the exponential. 1 − x ≈ e^−x for small x, and the exponents add up to n(n−1)/2 over 2^b. With b = 96 and n = 2³² that is 2⁶⁴ / 2⁹⁷ = 2⁻³³, which is why guidance caps a key at about 2³² random-nonce messages.

The alternative. A counter nonce never repeats (zero risk) but needs state that survives crashes and is never shared between two writers. Misuse-resistant modes (AES-GCM-SIV derives the nonce from the message) and XChaCha20's 192-bit random nonces make an accidental repeat either harmless or vanishingly rare.

f(x) = a₀ + a₁x + … + a_k−1x^k−1,   a₀ = secret,   share_i = (x_i, f(x_i))

f(0) = ∑_i y_i ∏_j≠i x_j / (x_j − x_i)

Why k points suffice. Two different polynomials of degree below k can agree on at most k−1 points (their difference would have too many roots), so k shares allow exactly one, and Lagrange's formula names it. Why k−1 say nothing. Add any candidate point (0, s) to k−1 shares and there is exactly one polynomial of degree k−1 through all k. Every s is possible, each by exactly one polynomial, and the random coefficients make each of those equally likely.

The field. In GF(256) a byte is a polynomial over bits: adding is XOR (so minus is XOR too), multiplying is shift-and-XOR reduced by x⁸ + x⁴ + x³ + x + 1 (0x11B), and the inverse of a is a²⁵⁴, because every nonzero element satisfies a²⁵⁵ = 1.

K_i = PBKDF2(passphrase, salt ‖ i, c),   work per attempt = slots × c HMACs,   P(random bytes pass a 128-bit tag) = 2⁻¹²⁸

Why every slot, every time. If unlocking stopped at the first slot that opens, the time taken would say which slot it was, and a wrong passphrase would be visibly quicker than a right one. Trying all four slots and comparing tags in constant time makes the three cases cost the same, so neither the clock nor the error says which door, if any, was used. Why a wrong passphrase never opens anything by luck. Under a wrong key the tag check is a comparison with an unrelated 128-bit value, which passes with probability 2⁻¹²⁸ per slot.

Erase keys, not data. Each slot starts with 60 bytes that wrap its own random data key. Overwriting those 60 bytes leaves the 4,036 bytes of sealed content exactly as they were, and exactly as useless, even to someone who still knows the passphrase. That is how a phone wipes in a second: it forgets one key.

MTH({d}) = H(0x00 ‖ d),   MTH(D_n) = H(0x01 ‖ MTH(D[0:k]) ‖ MTH(D[k:n])),   k = the largest power of 2 below n

proof length = ⌈log₂ n⌉ hashes (or one fewer),   expected trials to a collision of a b-bit hash ≈ √(π/2 × 2^b)

Why a path suffices. The root depends on a file only through the nodes on its path, so the verifier needs just the sibling at each level: hash upward, and the result equals the root only if the file and every sibling are the ones the root was made from (anything else would be a SHA-256 collision). Why the prefixes. Without them, an interior node's input (left ‖ right, 64 bytes) could be presented as a leaf's data, proving a "file" that was never in the tree against the same root: a second-preimage attack on the tree's shape. With 0x00 for leaves and 0x01 for nodes, a leaf hash and a node hash can never come from the same input.

Why only half the bits. Among t random b-bit values there are t(t−1)/2 pairs, each equal with probability 2^−b, so a repeat becomes likely near t ≈ 2^b/2 (the birthday bound again, the same sum as Exhibit III). SHA-256's 256 bits give 128 bits of collision resistance.