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 the cost is linear. Every iteration is one HMAC-SHA-256 that needs the previous one's output, so a guess costs c HMACs and you can't parallelise inside a single 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. More iterations only scale the cost by a constant, while every extra bit of entropy doubles it.

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 undoes itself: P = C ⊕ keystream, so flipping bit j of C flips bit j of P and nothing else. Counter mode hides data but doesn't protect it. Why GCM catches it. The blocks B₁ … B_m (the AAD, the ciphertext, then one block holding both lengths) are the coefficients of a polynomial, evaluated at the secret point H by Horner's rule. Change any block and the polynomial changes. 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 whenever the degree reaches 128 the field polynomial folds it back. The code here does that 128 times per block and has to 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 has to 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 you need 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 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 are enough. Two different polynomials of degree below k agree on at most k−1 points, so k shares allow exactly one, and Lagrange's formula gives it to you. Why k−1 tell you nothing. Add any candidate point (0, s) to k−1 shares and exactly one polynomial of degree k−1 goes through all k. Every s is possible, each by exactly one polynomial, and the random coefficients make each of them equally likely.

The field. In GF(256) a byte is a polynomial over bits. Adding (and subtracting) is XOR, and multiplying is shift-and-XOR reduced by x⁸ + x⁴ + x³ + x + 1 (0x11B). 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 it took would tell you which slot it was. Try all four slots and compare tags in constant time, and every case costs the same. 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 compares against an unrelated 128-bit value, and that passes with probability 2⁻¹²⁸ per slot.

What crypto-shred does. Each slot starts with 60 bytes that wrap its own random data key. Overwrite those 60 bytes and the 4,036 bytes of sealed content stay in place but useless, even to someone who knows the passphrase. That's how a phone wipes in a second.

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 is enough. 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 you only reach the root if the file and every sibling are the originals, short of a SHA-256 collision. Why the prefixes. Without them, an interior node's 64-byte input could pass as a leaf's data and prove a "file" that was never in the tree. With 0x00 for leaves and 0x01 for nodes, a leaf hash and a node hash never share an 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. 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.