Cryptography often disappears when it is working. A browser shows a padlock, a password becomes an unreadable database value, and a software update proves who published it. Then one reused nonce or exposed private key turns strong mathematics into very expensive decoration.

The field supplies building blocks for confidentiality, integrity, authentication, and key establishment. Encryption is one of those blocks, not a synonym for all of cryptography. The mathematics matters, but real failures more often come from choosing the wrong tool, mishandling a key, accepting an invalid certificate, or inventing a fragile protocol around a sound algorithm.

This article is therefore less about performing cryptography by hand and more about understanding what each tool promises, what it does not promise, and which implementation mistakes can undo it.

Symmetric Encryption

Symmetric encryption uses the same secret key to encrypt and decrypt data. It is fast enough for files, databases, network sessions, and large message streams.

Current designs should normally use authenticated encryption with associated data (AEAD), such as:

  • AES-GCM;
  • AES-GCM-SIV where misuse resistance is valuable and supported;
  • ChaCha20-Poly1305.

AEAD provides confidentiality and detects modification. Associated data—such as a protocol version or record identifier—is authenticated without being encrypted.

Nonces are part of the security contract

Many AEAD modes require a nonce that never repeats with the same key. Reusing an AES-GCM nonce can reveal relationships between plaintexts and compromise authentication. A nonce is not necessarily secret, but its uniqueness rule is not optional.

Use a mature library’s high-level API and follow its key and nonce requirements. Do not design an “AES plus hash” construction from scratch.

Asymmetric Cryptography

Public-key systems use a public key and a private key for related but different operations.

  • Key establishment: agree on or transport a shared secret.
  • Digital signatures: sign with a private key and verify with a public key.
  • Public-key encryption: encrypt for the private-key holder when the algorithm and protocol support it.

Diffie–Hellman and elliptic-curve Diffie–Hellman are key-agreement methods, not asymmetric encryption algorithms. Elliptic-curve cryptography is a family of constructions, including ECDH for agreement and ECDSA or EdDSA for signatures.

RSA can support encryption and signatures, but it needs separate, appropriate encodings. RSA-OAEP is used for encryption and RSA-PSS for signatures in current designs. “Encrypting with the private key” is not a good general explanation of signing.

Authentication of Public Keys

Public-key cryptography does not solve identity by itself. If an attacker substitutes a different public key, an unauthenticated key exchange can still be intercepted.

TLS commonly uses certificates to bind a public key to a DNS name through a certificate-authority system. Other systems use pre-shared fingerprints, SSH’s known-hosts model, a web of trust, or an organization’s own public-key infrastructure.

Certificate validation must check the name, trust chain, validity, allowed use, and relevant revocation policy. Encryption without authenticating the peer can produce a private connection to the attacker.

Hash Functions

A cryptographic hash maps arbitrary input to a fixed-size output:

h=H(m)h=H(m)

Important properties include resistance to finding a preimage, a second preimage, or a collision. A hash is not mathematically unique; a fixed-size output guarantees that collisions exist. The security goal is that finding a useful collision is infeasible.

SHA-256 and SHA-3-family functions are current general-purpose choices. MD5 and SHA-1 have practical collision attacks and should not protect signatures, certificates, or adversarial integrity checks.

An unkeyed hash can detect accidental corruption when the expected value is trusted. It cannot authenticate a message against an attacker who can replace both the message and hash.

Message Authentication Codes

A message authentication code (MAC) uses a shared secret to authenticate data:

t=MAC⁡k(m)t=\operatorname{MAC}_k(m)

HMAC-SHA-256 is a common example. Anyone with the shared key can create a valid tag, so a MAC does not provide a public proof of which key holder created the message.

Digital Signatures

A digital signature lets a holder of the private signing key sign data and lets others verify it with the public key. Current examples include Ed25519, ECDSA with approved curves and careful nonce handling, RSA-PSS, ML-DSA, and SLH-DSA.

Signatures provide integrity and proof that the signing key was used. They do not establish a human identity unless the public key is reliably bound to that identity. Broad claims of legal “non-repudiation” also depend on key custody, policy, process, and law.

A challenge-response protocol should sign a fresh, context-bound challenge or authenticate it with a MAC. Describing this as “encrypt the challenge with the private key” hides the encoding and protocol details that make the construction safe.

Password Storage

Passwords should not be stored with a fast general-purpose hash. Attackers who steal the database can try billions of guesses offline.

Use a password hashing function designed to make guesses expensive:

  • Argon2id;
  • scrypt;
  • bcrypt where its input-length and cost limits are understood;
  • PBKDF2 where required by platform or compliance constraints.

Each password needs a unique random salt. Tune memory and time costs for the server, store the parameters with the hash, and plan to rehash after successful login when settings change. A server-side pepper may add another barrier if it is kept separately in a secret-management system.

Password hashing does not prevent phishing or credential reuse. Pair it with breached-password screening and phishing-resistant MFA where appropriate.

Algorithms to Treat as Legacy or Broken

  • DES: brute-forceable due to its small key space.
  • 3DES/TDEA: withdrawn or disallowed for applying new protection in current NIST guidance.
  • RC4: biased and prohibited in modern TLS.
  • MD5 and SHA-1 signatures: collision-broken.
  • ECB mode: reveals repeated plaintext patterns and provides no authentication.
  • Blowfish: historically important, but its 64-bit block size makes it unsuitable for new general-purpose designs.

Legacy decryption may be needed during migration. That is different from recommending the algorithm for new data.

Hybrid Encryption

Public-key operations are not normally used to encrypt an entire large file. A hybrid scheme:

  1. creates a random symmetric content-encryption key;
  2. encrypts the data with AEAD;
  3. encapsulates or wraps the content key for the recipient;
  4. binds algorithm identifiers and context into authenticated data.

Protocols such as TLS implement their own carefully reviewed form of key agreement and authenticated encryption. Application developers should use those protocols rather than reproduce the design.

Key Management

Strong algorithms cannot compensate for exposed keys. A key-management plan covers:

  • secure generation from an approved random source;
  • storage in a suitable key-management service, HSM, TPM, or protected software store;
  • least-privilege access and audit logs;
  • separation between environments and purposes;
  • rotation based on cryptoperiod, exposure, and operational need;
  • backup or escrow only where recovery requirements justify it;
  • revocation and destruction;
  • algorithm and key-version metadata needed for future decryption.

Rotating a key does not automatically re-encrypt old data. Define whether new writes, existing ciphertext, or both move to the new version.

Post-Quantum Cryptography

Large, fault-tolerant quantum computers would threaten widely used RSA and elliptic-curve public-key systems through Shor’s algorithm. They do not break symmetric cryptography in the same way; larger symmetric keys can address the weaker quadratic speedup associated with Grover’s algorithm.

In 2024, NIST finalized its first post-quantum standards:

  • FIPS 203, ML-KEM: key encapsulation;
  • FIPS 204, ML-DSA: digital signatures;
  • FIPS 205, SLH-DSA: stateless hash-based signatures.

Migration is more than swapping names in a configuration file. Inventory where public-key cryptography is used, record certificate and protocol dependencies, test message and key sizes, plan hybrid deployments where appropriate, and account for data that must remain confidential for many years.

A Safer Decision Process

Before choosing cryptography, write down:

  1. what property is needed—confidentiality, integrity, peer authentication, signature, or password verification;
  2. who holds each key;
  3. how keys are provisioned, rotated, revoked, and recovered;
  4. what happens if a nonce repeats or a random source fails;
  5. which standards and libraries the environment supports;
  6. how algorithm agility will work without downgrade attacks.

Then use a documented protocol and a maintained implementation. Custom cryptography is rarely justified by application requirements.

Conclusion

Cryptography is precise engineering. “Encrypted,” “hashed,” and “signed” are incomplete statements unless they name the purpose, algorithm, key handling, and verification rule. Choosing a current primitive is the easy part; using it in a protocol that protects keys, nonces, identities, and failure paths is the real work.

References