4. Cryptography

Cryptography turns the problem of protecting a lot of data into the problem of protecting a small key. It can provide confidentiality, integrity and authenticity, but never more security than the key management around it.

What crypto can and cannot do

It can hide content, detect modification, prove who produced something, and let two strangers agree on a secret over a public channel. It cannot protect data while a program is using it in plaintext, fix a compromised endpoint, or decide who should have access.

The first rule: do not invent cryptography. Use well-reviewed libraries with high-level interfaces (libsodium, or the Python cryptography package’s recipes). Real-world crypto failures are almost always in how primitives are combined and used, not in the math.

The primitives

Primitive	What it gives you	Mental model	Current examples
Hash function	A fixed-size fingerprint of any data; integrity if the hash itself is trusted	One-way: easy to compute, infeasible to reverse or find two inputs with the same hash	SHA-256, SHA-3, BLAKE3 (MD5 and SHA-1 are broken)
MAC	Integrity and authenticity between parties sharing a key	A keyed fingerprint only key-holders can make	HMAC-SHA256
Authenticated encryption (AEAD)	Confidentiality and integrity with one shared key	A tamper-evident lockbox	AES-GCM, ChaCha20-Poly1305
Key exchange / public-key encryption	A shared secret with no prior contact	A public mailbox only you can open	X25519 (ECDH), RSA
Digital signature	Authenticity, integrity, non-repudiation - verifiable by anyone	A seal only you can make, anyone can check	Ed25519, ECDSA, RSA-PSS
Password hash / KDF	Turns low-entropy passwords into keys or stored verifiers; slow on purpose	Makes each guess expensive	Argon2id, scrypt, bcrypt
Secure random generator	Unpredictable values for keys, tokens, nonces	Dice the attacker can’t predict	Python secrets, os.urandom (never random)

Three ideas people often get wrong:

• Hashing is not encryption or anonymization. No key is involved, so anyone can compute the same hash. If the input space is small (phone numbers, emails, birthdates), an attacker simply hashes every possible value and matches. Under GDPR, hashed identifiers are pseudonymous data, not anonymous data.
• Encryption without integrity is dangerous. Attackers can flip bits in unauthenticated ciphertext and get predictable changes in plaintext. Use AEAD modes.
• Nonces must never repeat for the same key. Reusing a nonce in AES-GCM can expose plaintext and let attackers forge messages.

Key management is the real work: how keys are generated, where they are stored (a cloud KMS or hardware security module, not a config file), who can use them, how they are rotated, and how they are revoked after a leak.

Public-key infrastructure: whose key is this?

Public-key crypto moves the problem: now you must know that a public key really belongs to who you think. Certificates solve this by delegation. A certificate authority (CA) signs a statement like “this key belongs to example.com”. Browsers and operating systems ship with a list of trusted root CAs. Certificate Transparency logs publish every issued certificate, so wrongly issued ones can be spotted.

A newer model is keyless signing (Sigstore). A signer proves their identity through an existing login (OIDC), receives a short-lived certificate, signs, and the signature is recorded in a public transparency log. No long-lived private key exists to steal. This is increasingly used to sign software releases and ML models.

Storing passwords

Never store passwords in plaintext, encrypted, or with a fast hash like SHA-256. Use a slow, salted password hash such as Argon2id. The salt (random per password) stops precomputed lookup tables. The slowness makes each guess expensive, so a stolen database cannot be cracked cheaply. Better still is not having passwords at all (passkeys, Part 5).

Data at rest, in transit, in use

• At rest - disk, database and object-storage encryption. Mostly protects against stolen disks and misplaced backups, not against a compromised application that can read the data anyway.
• In transit - TLS (Part 3).
• In use - the hardest. Confidential computing uses hardware trusted execution environments (TEEs) that isolate memory even from the cloud operator, plus remote attestation that proves which code runs inside. Modern GPUs support such modes for confidential inference. Homomorphic encryption and secure multi-party computation compute on encrypted data; they are mathematically elegant but still too slow for large models.

Common mistakes

• Designing your own cipher or protocol.
• Hardcoding keys in source code or notebooks; keys surviving in git history after “deletion”.
• Comparing secrets with ==, which can leak timing information; use hmac.compare_digest.
• Generating tokens with random instead of secrets.
• Turning off certificate verification.
• No plan for crypto agility. NIST standardized its first post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA) in 2024. Data encrypted today can be recorded now and decrypted once quantum computers mature (“harvest now, decrypt later”).

AI link

• Artifact integrity. Hash and sign models and datasets; verify before loading. The OpenSSF model-signing effort builds on Sigstore for exactly this.
• Embeddings are not encryption. Research has shown text can be reconstructed with high fidelity from its embeddings. Protect a vector database as carefully as the documents it was built from.
• Confidential inference. TEEs can shield prompts and model weights from the infrastructure operator, with attestation that the expected model and code are running.
• Content provenance. Standards like C2PA attach signed manifests to images and media, recording where they came from and how they were edited. Watermarks embed signals in generated content; signatures attach proof beside it.

Questions to ask

• Which property do we need here: confidentiality, integrity, authenticity - or several?
• Where do the keys live, who and what can use them, and how are they rotated and revoked?
• Are we using a high-level, reviewed library, or assembling primitives ourselves?
• Is hashed, tokenized or embedded data being treated as if it were anonymous?
• How do we verify that this model file or dataset is exactly the one we expect?
• What protects the data while it is in use, not only at rest and in transit?