Cryptography

A fictional school wants to publish an authentic announcement, keep student records private, and verify its backups. “Use encryption” is not a complete design. Each goal needs a particular guarantee and a plan for the keys or trusted references that support it.

Separate the guarantees

Confidentiality concerns who can read information. Integrity concerns unauthorized changes. Authenticity concerns the claimed source. The A in the CIA triad means availability, not authenticity; reliable storage and tested recovery remain necessary even when cryptography is correct.

Symmetric encryption uses a shared secret key. Suitable authenticated-encryption schemes protect both confidentiality and integrity when used correctly. Public-key encryption instead uses a recipient’s public key for encryption and the corresponding private key for decryption. Not every public-key algorithm is an encryption algorithm.

A Digital signature is produced with a signing private key and checked with the public key. It does not hide the message or prove that its claims are true. The verifier also needs a reason to trust the association between that public key and the claimed source.

A fingerprint needs a trusted comparison

A cryptographic Hash produces a digest. Comparing against an independently trusted digest can detect a change. An untrusted file accompanied by an untrusted digest does not establish authenticity. “One-way” also does not prevent guessing an input and comparing its hash.

Password verification therefore needs a purpose-built password-hashing scheme, a unique salt, and an appropriate cost. A salt separates otherwise identical password records; the cost makes guesses more expensive. A password manager has a different job: it must encrypt stored passwords so their owner can retrieve them.

The backup is encrypted. Can the school definitely restore it?

No. It also needs usable keys, intact backups, supported software, and a tested recovery path. Encryption with a lost key may preserve secrecy while making recovery impossible.

TLS combines separate jobs

In a typical certificate-based TLS 1.3 handshake, certificate validation and a signature authenticate the server, while ephemeral key agreement helps establish shared key material. Derived symmetric keys protect application traffic with authenticated encryption. Those roles are distinct; the diagram is not a packet-by-packet handshake.

TLS also supports pre-shared-key modes and resumption. HTTPS protects the connection to the chosen site; it does not certify that the site is honest. Correct algorithms still require protected keys, suitable parameters, careful nonce handling where required, and reliable implementations.

Plan for long-lived protection

Post-quantum cryptography addresses future quantum threats to particular public-key mechanisms. NIST has standardized ML-KEM for key encapsulation and ML-DSA and SLH-DSA for signatures. These are different jobs, not interchangeable replacements for every cipher.

Long-lived secrets may face “harvest now, decrypt later” risk, depending on their protocol and confidentiality lifetime. Inventory affected dependencies and follow maintained implementation guidance. Increasing any key length is not a universal migration strategy. Continue with data protection to connect cryptography to ownership and recovery.

Give each school document the right protection

Consider three copies of a fictional school announcement. A public copy needs no secrecy, but families need confidence that it came from the school and was not altered. A signed copy can support those checks if the families already have a trustworthy way to obtain the school’s verification key. Anyone holding that public key may verify; they do not need the private signing key.

An internal message between two school services has a different audience. A message authentication code, such as HMAC, can let parties sharing a secret key check integrity and origin within that shared-key relationship. Either party with the same key can produce a valid code. It therefore does not provide the same public verification model as a digital signature, and neither mechanism by itself hides the message.

Student records need confidentiality as well. A suitable authenticated-encryption scheme can protect content and detect unauthorized modification. But a valid encrypted record could still contain an original administrative mistake. Cryptography checks defined relationships among bytes and keys; it does not decide whether an address is correct or a staff member should be allowed to read it.

The key has a lifecycle too

The school needs to know which keys protect which records, who may use them, and how authorized recovery works. Changing to a new encryption key does not automatically make old backups recoverable with the new key. If old records remain protected with an earlier key, recovery must account for that dependency. Deleting keys without understanding it can destroy useful access.

A verification key also needs context: what source is it associated with, for what purpose, and through which trusted process? Trusting a key because it arrived beside the message merely moves the original question to another file.

Continue with hashes, MACs, and signatures to compare evidence, then encryption, keys, and trust to follow protection through storage, communication, and recovery.