What cryptography is and what it’s for

Cryptography is the study and practice of methods for protecting information. In practical terms, it helps achieve goals such as:

  • Confidentiality: keeping data unreadable to unauthorized parties.
  • Integrity: detecting whether data was changed.
  • Authenticity: proving who created something (or that it came from a trusted source).
  • Non-repudiation (in some setups): making it hard for a sender to later deny authorship.

Cryptography is not “security” by itself; it’s one set of tools that contribute to security when used correctly in a broader system.

How cryptography works at a high level

Most cryptographic systems combine three components:

  1. An algorithm (the defined procedure, like an encryption or hash function).
  2. A key (secret or public material that controls what the algorithm does).
  3. A protocol (the rules for how components interact across steps, messages, and time).

A common pattern is:

  • Encryption converts plaintext into ciphertext using a key.
  • Decryption recovers plaintext only with the right key.
  • Hashing converts data into a fixed-length “fingerprint” that changes when the input changes.
  • Digital signatures let a verifier check that data was signed by a corresponding private key, and that it hasn’t been altered.

Cryptography comes in several families:

  • Symmetric cryptography uses the same key for encryption and decryption.
  • Asymmetric cryptography uses a public key and a private key for encryption, key exchange, or signatures.
  • Hash functions support integrity checks and underpin signatures and key derivation.

Limits and common misconceptions

A key limitation is that cryptography usually protects specific properties under certain assumptions.

  • Key management is often the weak point: if keys leak, are reused incorrectly, or are not rotated when needed, the mathematical strength may not help.
  • Encryption may not guarantee integrity unless designed for it: encryption alone might not detect tampering; many systems use combined “authenticated” designs.
  • Authenticity depends on trust in keys and identifiers: if you can trick someone into accepting a wrong public key, the signature check may still succeed—just for the wrong party.
  • Side channels and implementation issues matter: timing leaks, faulty random number generation, or bugs can undermine security even when the algorithm is strong.
  • “Guaranteed” outcomes are unrealistic: cryptography reduces risk when applied properly, but it cannot eliminate all operational failure modes.

Practical checks you can do

You can validate cryptographic expectations by focusing on what is measurable rather than marketing claims:

  1. Check how integrity is handled: look for signatures (public-key) or message authentication codes (symmetric) depending on the system’s design. If you only see raw encryption with no authentication, be cautious.
  2. Verify signatures end-to-end: ensure you are checking the signature over the intended exact data (and not a modified subset).
  3. Confirm randomness requirements are met: for encryption schemes that need nonces/IVs or key generation, verify that the system uses a cryptographically secure source of randomness.
  4. Match algorithm choices to your threat model: the best approach depends on whether the main concern is confidentiality, integrity, authentication, or key agreement.
  5. Inspect key lifecycle practices: confirm there is a process for storage, access control, rotation, and revocation where applicable.

If you’re analyzing a protocol, document what each cryptographic primitive is meant to provide, then verify that the system actually uses it in that role.

Cryptography often gets mixed with adjacent ideas:

  • Cryptanalysis: methods of attacking cryptographic schemes.
  • Steganography: hiding the existence of a message rather than its content.
  • Key exchange: how parties agree on shared secrets (often using asymmetric cryptography).
  • PKI (public key infrastructure): how public keys are distributed and associated with identities (certificates, trust chains).

A useful way to keep things straight is to map each component to its goal: secrecy, tamper detection, or identity verification—and then check whether the chosen primitives and protocol steps actually support that goal.