Cryptography experimental

Cryptography The mathematics that makes secrecy provable: modular arithmetic, symmetric and public-key schemes, hashes and signatures, each built from first principles. Modular arithmetic. Modular arithmetic. Compute in modular arithmetic.. Explain the modular-arithmetic operations that underpin public-key cryptography.. Groups and fields, Modular arithmetic, GCD and inverses, Hard problems Groups and fields Cryptography is arithmetic wearing a disguise. A group is a set with one operation that combines two elements into a third, has an identity element, gives every element an inverse, and is associative. The integers mod n under addition form a group of size n. When n is prime, the nonzero residues mod n also form a group under multiplication, and together with addition this makes a field, where every nonzero element has a multiplicative inverse. Fields are the stage on which Rivest-Shamir-Adleman (public-key cryptosystem) (RSA), Diffie-Hellman, and elliptic curves all perform; without inverses, none of them can decrypt what they encrypt. Modular arithmetic Working mod n means every result wraps back into {0, 1, ..., n-1}: only the remainder after division by n survives. Addition, subtraction, and multiplication behave predictably mod n: (a + b) mod n = ((a mod n) + (b mod n)) mod n, and likewise for multiplication. This lets us compute with enormous numbers, such as 3^1024, without ever storing the full value, using fast exponentiation (repeated squaring): square and reduce mod n at every step, using the bits of the exponent to decide when to multiply in the base. This is the operation every public-key scheme performs millions of times per second. GCD and inverses The Euclidean algorithm finds the greatest common divisor (GCD) of two integers by repeated remainder-taking, and its extended form, back-substituting through the same steps, produces integers x and y such that ax + by = gcd(a,b). When gcd(a,n) = 1, that x is exactly a's multiplicative inverse mod n: a·x ≡ 1 (mod n). This inverse is what turns 'encrypt' into 'decrypt' in RSA and what solves the discrete-log style equations that key exchanges rely on. Not every number has an inverse mod n; only those coprime to n do, which is why choosing n carefully (prime, or a product of primes with known factorization) matters enormously. Hard problems Security rests on problems that are cheap to set up but expensive to reverse. Integer factorization, given n = p·q for large primes p and q, recover p and q, underlies RSA. The discrete logarithm problem, given g, p, and g^x mod p, recover x, underlies Diffie-Hellman and much of elliptic-curve cryptography. Both problems are easy to state, easy to verify an answer for, and (with current classical computers and well-chosen parameters) infeasible to solve directly. Cryptographic strength is a statement about computational cost, not mathematical impossibility: as computers get faster or new algorithms appear, key sizes must grow to keep the gap between 'compute' and 'break' safely wide. Key sizes and margins Choosing a key size is a judgment about how much computational margin to buy against both today's hardware and a reasonable projection of tomorrow's. A 2048-bit RSA modulus and a 256-bit elliptic-curve key are not arbitrary round numbers; each reflects the best known classical attack's estimated cost against that specific problem instance, with enough margin built in that the parameter choice remains safe for a defined planning horizon even as attacker compute grows. This is also why cryptographic agility, the ability to swap an algorithm or key size without a ground-up redesign, matters as much as the initial choice: a system hard-coded to one fixed key size cannot respond when that margin erodes, whether from faster classical hardware, a new cryptanalytic technique, or the more distant but real prospect of a fault-tolerant quantum computer. Related CCI capabilities Computer Architecture (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/computer-architecture/). Optics Primer Series (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/optics/). Maths Refresher Series, Finance (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/maths-finance/). System Dynamics (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/system-dynamics/). CCI Lab: Run it, build with it, read the thinking, reuse the data. (https://www.cambridgecyberinternational.com/en/insights/lab/) Symmetric encryption. Symmetric encryption. Explain block ciphers and modes.. Implement and compare block-cipher modes of operation for a given confidentiality requirement.. Block ciphers, Modes, Stream ciphers, Authenticated encryption Block ciphers A block cipher is a keyed permutation on fixed-size chunks of data: Advanced Encryption Standard (AES)-128 shuffles 16-byte blocks under a 128-bit key, and that shuffle must look indistinguishable from a random permutation to anyone without the key. AES achieves this through rounds of substitution (a nonlinear S-box that breaks algebraic structure) and permutation (byte shuffling and mixing that spreads influence across the whole block), repeated 10-14 times depending on key length. A single block cipher call is deterministic: the same key and the same input block always produce the same output block. That determinism is exactly the property that makes using a block cipher directly on real messages dangerous, which is why modes of operation exist. Modes A mode of operation turns a single-block cipher into a scheme that handles arbitrary-length messages. Electronic codebook (ECB) encrypts each block independently, which is simple, but identical plaintext blocks produce identical ciphertext blocks, so patterns in the input (a solid-color region of an image, a repeated header) leak straight through into the output. Cipher block chaining (CBC) XORs each plaintext block with the previous ciphertext block before encrypting, using a random initialization vector (IV) for the first block, which hides repetition but requires padding and is fragile if the IV is reused or predictable. Counter mode (CTR) encrypts a counter value and XORs the result with the plaintext, turning a block cipher into a stream cipher, parallelizable and free of padding; it is, however, catastrophic if the same counter value is ever reused with the same key, since XORing two ciphertexts then cancels the keystream and exposes the eXclusive OR (XOR) of the two plaintexts. Stream ciphers Stream ciphers such as ChaCha20 generate a pseudorandom keystream from a key and a nonce, then XOR it with the plaintext directly, avoiding block-alignment and padding entirely. Their entire security rests on never reusing a (key, nonce) pair: reuse produces the same keystream twice, and XORing the two ciphertexts cancels it out, leaking the XOR of the two plaintexts. This is the same failure mode as CTR-mode counter reuse, because CTR mode is, structurally, a stream cipher built from a block cipher. Authenticated encryption Confidentiality alone is not enough: an attacker who cannot read a CTR-mode ciphertext can often still flip bits in it and flip the corresponding bits in the decrypted plaintext, undetected. Authenticated encryption with associated data (AEAD), such as AES-GCM, Advanced Encryption Standard in Galois/Counter Mode (GCM), or ChaCha20-Poly1305, binds encryption to a message authentication code (MAC)-like authentication tag computed over the ciphertext (and optional associated data that stays unencrypted, like a header), so any tampering is detected before decryption is even attempted. Modern practice treats plain encryption without authentication as a bug: always prefer an AEAD mode, verify the tag before trusting any decrypted output, and never reuse a nonce under the same key. Choosing a mode in practice Given the failure modes above, production guidance narrows quickly: prefer an AEAD mode over any non-authenticated mode by default, since the authentication tag closes the tampering gap that confidentiality-only modes leave open. Between AEAD choices, AES-GCM is the common default on hardware with AES acceleration instructions, while ChaCha20-Poly1305 is preferred on platforms without that acceleration, since a software-only AES implementation without hardware support is both slow and vulnerable to timing side channels that hardware-accelerated AES avoids. Whatever mode is chosen, nonce management is the practical failure point in real deployments far more often than the underlying algorithm: a random 96-bit nonce generated correctly for every single encryption call, never reused under the same key, is what the security proof for these modes actually depends on, and getting that one operational detail wrong quietly breaks every guarantee the mode otherwise provides. Related CCI capabilities Computer Architecture (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/computer-architecture/). Optics Primer Series (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/optics/). Maths Refresher Series, Finance (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/maths-finance/). System Dynamics (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/system-dynamics/). CCI Lab: Run it, build with it, read the thinking, reuse the data. (https://www.cambridgecyberinternational.com/en/insights/lab/) Public-key. Public-key. Explain public-key and key exchange.. Implement a key-exchange protocol and derive a shared secret between two parties.. RSA, Diffie-Hellman, Elliptic curves, Post-quantum note Rivest-Shamir-Adleman (public-key cryptosystem) (RSA) RSA generates a keypair from two large primes p and q: compute n = p·q and φ(n) = (p-1)(q-1), pick a public exponent e coprime to φ(n) (commonly 65537), and compute the private exponent d as the modular inverse of e mod φ(n). The public key is (n, e); the private key is d. Encryption is c = m^e mod n; decryption is m = c^d mod n, which works because e and d were constructed to undo each other exactly mod φ(n), a consequence of Euler's theorem. Security depends entirely on the hardness of factoring n: anyone who factors n into p and q can recompute φ(n) and then d, so key sizes (2048+ bits today) are chosen to keep factoring infeasible. Textbook RSA as described here is deterministic and insecure in practice; real systems use padding schemes (Optimal Asymmetric Encryption Padding (OAEP) for encryption, Probabilistic Signature Scheme (PSS) for signatures) to randomize and structure the input before the exponentiation. Diffie-Hellman Diffie-Hellman lets two parties agree on a shared secret over a public channel without ever transmitting the secret itself. Both agree on a public prime p and generator g. Alice picks a secret a and sends g^a mod p; Bob picks a secret b and sends g^b mod p. Alice computes (g^b)^a mod p and Bob computes (g^a)^b mod p: both equal g^(ab) mod p, the shared secret, while an eavesdropper who only sees g^a mod p and g^b mod p faces the discrete logarithm problem to recover a or b. Diffie-Hellman by itself has no authentication, since it is vulnerable to a man-in-the-middle who intercepts and replaces both exchanges, so real protocols (TLS) combine it with signatures or certificates to authenticate the parties. Elliptic curves Elliptic-curve cryptography replaces modular exponentiation with point addition on a curve defined by an equation like y^2 = x^3 + ax + b over a finite field. Points on the curve form a group under a geometric addition rule, and 'exponentiation' becomes repeated point addition (scalar multiplication). The elliptic-curve discrete logarithm problem (given a point P and Q = kP, recover k) is believed substantially harder per bit than the classic discrete-log or factoring problems, so Elliptic-Curve Cryptography (ECC) achieves comparable security to RSA with much smaller keys (256-bit ECC roughly matches 3072-bit RSA), which is why Elliptic Curve Diffie-Hellman (ECDH) and the Elliptic Curve Digital Signature Algorithm (ECDSA) dominate modern TLS and mobile cryptography. Post-quantum note Shor's algorithm, run on a sufficiently large fault-tolerant quantum computer, solves both integer factorization and discrete logarithms (including the elliptic-curve variant) efficiently, which would break RSA, Diffie-Hellman, and ECC simultaneously. No such machine exists yet at the scale required, but the threat is taken seriously enough that NIST has standardized post-quantum algorithms, namely lattice-based schemes such as the Key Encapsulation Mechanism (KEM) standardized as ML-KEM (Kyber) for key exchange and the Digital Signature Algorithm (DSA) standardized as ML-DSA (Dilithium) for signatures, whose hardness rests on different problems (short-vector and learning-with-errors problems) believed resistant to quantum attack. Migration is already underway via hybrid schemes that combine a classical algorithm with a post-quantum one, so that breaking either alone is not enough to break the connection. Key sizes across families Comparable security levels require very different key sizes depending on which hard problem underlies the scheme, which is why key size alone is a poor way to compare cryptosystems across families. Achieving roughly a 128-bit security margin needs about a 3072-bit RSA modulus, but only a 256-bit elliptic-curve key, because the best known attacks against factoring and against the elliptic-curve discrete logarithm problem scale differently with key size. Post-quantum lattice-based schemes complicate the comparison further still: their key and ciphertext sizes are typically larger than either classical RSA or elliptic-curve keys at a comparable classical security level, which is one practical cost of the migration this module's post-quantum note describes, alongside the cryptanalytic benefit of resisting Shor's algorithm. Related CCI capabilities Computer Architecture (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/computer-architecture/). Optics Primer Series (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/optics/). Maths Refresher Series, Finance (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/maths-finance/). System Dynamics (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/system-dynamics/). CCI Lab: Run it, build with it, read the thinking, reuse the data. (https://www.cambridgecyberinternational.com/en/insights/lab/) Hashes and signatures. Hashes and signatures. Use hashes and signatures correctly.. Explain hash and signature security properties and implement correct signing and verification for a given message.. Hash functions, MACs, Digital signatures, Certificates Hash functions A cryptographic hash function maps arbitrary-length input to a fixed-length digest (the Secure Hash Algorithm (SHA) family member SHA-256 produces 256 bits) and must satisfy three properties: preimage resistance (given a digest, you cannot find any input that produces it), second-preimage resistance (given one input, you cannot find a different input with the same digest), and collision resistance (you cannot find any two distinct inputs with the same digest at all). The last is the hardest to satisfy and the first to fail as a hash function ages: the Message-Digest Algorithm 5 (MD5) and SHA-1 are both considered broken for collision resistance and must not be used in new designs. A good hash function also exhibits the avalanche effect: flipping a single input bit changes roughly half the output bits, so digests reveal nothing about how similar two inputs were. MACs A hash alone provides no authentication, since anyone can compute SHA-256 of a message, including an attacker who alters it in transit and recomputes the hash to match. A message authentication code (MAC) fixes this by incorporating a shared secret key: the Hash-based Message Authentication Code (HMAC) construction builds a keyed hash by hashing the key together with the message (in a specific nested construction that resists length-extension attacks that naive key-then-hash approaches suffer from). Only someone holding the key can produce a valid HMAC tag, so a verifier who recomputes the tag and finds a match knows both that the message is unaltered and that it came from someone who knows the shared key: this gives integrity and authentication, but not non-repudiation, since any party who can verify the MAC could also have forged it. Digital signatures Digital signatures solve what MACs cannot: proving a message came from a specific party without a shared secret, and doing so in a way a third party can verify without being able to forge new signatures. Signing uses a private key to produce a signature over a message's hash; verification uses the corresponding public key. Rivest-Shamir-Adleman (public-key cryptosystem) (RSA) combined with the Probabilistic Signature Scheme (PSS), and the Elliptic Curve Digital Signature Algorithm (ECDSA), are the workhorses; both rely on the same hard problems (factoring, discrete log) that make the underlying public-key schemes secure. Because only the private-key holder can produce valid signatures, and anyone can verify them with the public key, signatures give non-repudiation: the signer cannot later credibly deny having signed, which MACs cannot provide. Certificates A signature only proves 'whoever holds this private key signed this,' which is useless unless you can bind a public key to a real-world identity. A certificate does that binding: a trusted certificate authority (CA) signs a statement asserting 'this public key belongs to this domain/entity,' and that CA signature is itself verified by chaining up to a small set of root CAs that come pre-trusted (in a browser or operating system (OS) trust store). This chain of trust is what lets Transport Layer Security (TLS) establish that you are really talking to your bank rather than an impersonator who merely holds some valid keypair: the server proves possession of the private key, and the certificate chain proves that public key belongs to the claimed domain. Certificate validity periods, revocation via a Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP), and the integrity of root trust stores are the practical failure points of the whole system: the cryptography rarely breaks, but the trust chain around it often does. Key management A signature or a certificate is only as trustworthy as the private key behind it, which makes key management, not the signing algorithm itself, the most common practical failure point. A private key generated with insufficient randomness, stored unencrypted on a machine reachable from the internet, or never rotated after employees with access leave, undermines every guarantee the underlying algorithm provides, regardless of whether that algorithm is RSA, ECDSA, or a post-quantum replacement. Hardware security modules and cloud key-management services address this by ensuring the private key material never leaves a protected boundary in plaintext form, so that signing operations happen inside the boundary and only the result, never the key itself, is returned to the calling application. Related CCI capabilities Computer Architecture (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/computer-architecture/). Optics Primer Series (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/optics/). Maths Refresher Series, Finance (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/maths-finance/). System Dynamics (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/system-dynamics/). CCI Lab: Run it, build with it, read the thinking, reuse the data. (https://www.cambridgecyberinternational.com/en/insights/lab/)