Skip to content
All articles

Security Foundations: Cryptography, Hashing & Trust Models

Dean Jain

Dean Jain

Senior Staff Software Engineer · Enterprise AI, Data & Cloud Architect

· 6 min read

CryptographySecurityHashingFundamentals
---
config:
  theme: neutral
  fontSize: 16
---
flowchart LR
    CIA["CIA goals"]:::gov --> SYM["Symmetric<br/>confidentiality"]:::server
    CIA --> ASYM["Asymmetric<br/>auth · non-repudiation · key exchange"]:::obs
    CIA --> HASH["# Hashing<br/>integrity"]:::gate
    SYM --> TRUST["Trust model<br/>(makes keys believable)"]:::good
    ASYM --> TRUST
    HASH --> TRUST
    classDef gov fill:#FFFFFF,stroke:#333333,stroke-width:1px,color:#111111
    classDef server fill:#F0F0F0,stroke:#333333,stroke-width:1px,color:#111111
    classDef obs fill:#DAE8FC,stroke:#333333,stroke-width:1px,color:#111111
    classDef gate fill:#DCDCDC,stroke:#333333,stroke-width:1px,color:#111111
    classDef good fill:#E8E8E8,stroke:#333333,stroke-width:1px,color:#111111

Figure 1: Security's goals (CIA) are delivered by three cryptographic tool types and every one of them depends on a trust model to make keys believable.

Cryptography is taught as a pile of algorithms, which is why most people come away knowing the names (AES, RSA, SHA) but not which problem each one solves. The clean mental model is smaller than the algorithm list: security is about CIA confidentiality, integrity, availability and cryptography delivers it through exactly three kinds of tools. Symmetric crypto buys confidentiality, asymmetric crypto buys authentication and key exchange, hashing buys integrity. And all of it is worthless without a fourth thing nobody mentions first: a trust model that makes a key believable. Here’s the foundation, mapped to what each piece actually protects.

Summary

  • Security = CIA. Confidentiality (no unauthorized reads), Integrity (no undetected changes), Availability (it’s there when needed). Cryptography serves the first two directly.
  • Five crypto functions: confidentiality, authentication, integrity, non-repudiation (can’t deny you sent it), and key exchange.
  • Three tool types: symmetric (SKC one shared key, fast, confidentiality), asymmetric (PKC key pair, slow, auth + non-repudiation + key exchange), hash (one-way, integrity).
  • Block vs stream. Block ciphers (DES/AES) use substitution + permutation for confusion + diffusion; stream ciphers XOR a keystream fast, for data of unknown length.
  • Trust models make keys believable web of trust (PGP), trusted third party (Kerberos), and certificates (PKI/CAs). Without one, you’re encrypting to a stranger.

1. The job: CIA and the five functions

Start with what security is for. The bedrock is the CIA triad:

  • Confidentiality information is readable only by those authorized.
  • Integrity information isn’t altered without detection.
  • Availability information and systems are accessible when needed.

Security architecture exists to deliver CIA across an organization, and it’s never just tools it’s people, processes, and tools working in layers (network, platform, application, physical), all tied back to risk management. You don’t secure everything equally; you secure in proportion to risk. Cryptography is the engine behind the C and the I, and it performs five functions:

  1. Confidentiality keep the message secret.
  2. Authentication prove who you’re talking to.
  3. Integrity prove the message wasn’t tampered with.
  4. Non-repudiation the sender can’t later deny having sent it.
  5. Key exchange safely agree on a shared secret over an open channel.

Hold onto these five the three tool types map onto them almost perfectly, which is what makes the whole field memorable instead of a name-soup.

2. The three tool types each solves different functions

Every cryptographic algorithm falls into one of three families, and the trick is to remember which CIA functions each one is good at:

---
config:
  theme: neutral
  fontSize: 16
---
flowchart TD
    SKC["Symmetric (SKC)<br/>one shared secret key<br/>fast · bulk data<br/>confidentiality"]:::server
    PKC["Asymmetric (PKC)<br/>public + private key pair<br/>slow · small data<br/>auth · non-repudiation · key exchange"]:::obs
    H["# Hash function<br/>one-way, no key<br/>fixed-size digest<br/>integrity"]:::gate
    classDef server fill:#FFFFFF,stroke:#333333,stroke-width:1px,color:#111111
    classDef obs fill:#F0F0F0,stroke:#333333,stroke-width:1px,color:#111111
    classDef gate fill:#DAE8FC,stroke:#333333,stroke-width:1px,color:#111111

Figure 2: The three algorithm families symmetric (confidentiality), asymmetric (auth/non-repudiation/key exchange), and hashing (integrity).

  • Symmetric / Secret Key Cryptography (SKC) one shared key both encrypts and decrypts. It’s fast, so it does the heavy lifting of bulk confidentiality. The catch is in the name: both sides need the same secret, so you have a key-distribution problem how do you share the key without someone intercepting it?
  • Asymmetric / Public Key Cryptography (PKC) a key pair: a public key anyone can hold and a private key you guard. Encrypt with the public key, only the private key decrypts (confidentiality to a recipient); sign with the private key, anyone verifies with the public key (authentication + non-repudiation). It’s slow, so it’s used on small data signatures and, crucially, key exchange (it solves SKC’s distribution problem). RSA is the classic.
  • Hash functions one-way, no key. They crunch any input into a fixed-size digest. You can’t reverse it (a “trapdoor”), and any change to the input changes the digest which is exactly what makes them the tool for integrity. Hash a file, store the digest; re-hash later and compare. Mismatch = tampered.

The pairing is the whole game: real systems use all three together PKC to exchange an SKC key, SKC to encrypt the bulk data, and a hash to prove integrity. That’s essentially how TLS works.

Block vs stream (inside symmetric)

Symmetric ciphers come in two shapes:

Block cipherStream cipher
UnitFixed-size blocksBit/byte at a time
HowSubstitution + permutationXOR plaintext with a keystream
GoalConfusion + diffusion (Shannon)Speed, simplicity
UseData of known size, at restData of unknown length, streaming
ExamplesDES, AESRC4-style XOR streams

Block ciphers (DES, then AES) repeatedly substitute (replace bits confusion, hiding the key/ciphertext relationship) and permute (shuffle positions diffusion, spreading each plaintext bit across the output). Stream ciphers just XOR the data against a generated keystream fast and ideal when you don’t know the length up front. Same goal (confidentiality), two engineering trade-offs.

3. The part nobody mentions first: trust models

Here’s the gap in most explanations. Asymmetric crypto lets you encrypt to “Alice’s public key.” But how do you know that key is actually Alice’s and not an attacker’s? Encrypting to the wrong key is encrypting to the enemy. Solving that binding a key to an identity you can believe is a trust model, and there are three classic answers:

---
config:
  theme: neutral
  fontSize: 16
---
flowchart TD
    Q["Is this key really theirs?"]:::gov
    Q --> WOT["Web of trust (PGP)<br/>peers vouch for peers<br/>no central authority"]:::obs
    Q --> TTP["Trusted third party (Kerberos)<br/>a central server both sides trust<br/>issues session tickets"]:::server
    Q --> CERT["Certificates (PKI)<br/>a CA signs identitykey bindings<br/>chain of trust to a root"]:::gate
    classDef gov fill:#FFFFFF,stroke:#333333,stroke-width:1px,color:#111111
    classDef obs fill:#F0F0F0,stroke:#333333,stroke-width:1px,color:#111111
    classDef server fill:#DAE8FC,stroke:#333333,stroke-width:1px,color:#111111
    classDef gate fill:#DCDCDC,stroke:#333333,stroke-width:1px,color:#111111

Figure 3: Three trust models for binding a key to an identity peer vouching (PGP), a trusted central server (Kerberos), and CA-signed certificates (PKI).

  • Web of trust (PGP) decentralized. Peers sign each other’s keys; you trust a key if someone you trust has vouched for it, transitively. No central authority resilient, but trust is fuzzy and bootstrapping is on you.
  • Trusted third party (Kerberos) centralized server. Both parties trust a common authority (the Key Distribution Center) that authenticates them and hands out time-limited session tickets. Great inside an enterprise; the third party is a single point of trust (and failure).
  • Certificates / PKI hierarchical. A Certificate Authority digitally signs a certificate binding an identity to a public key; you trust the cert because you trust the CA, up a chain to a root your system already trusts. This is what padlocks your browser every HTTPS site presents a CA-signed certificate.

The unifying point: cryptography proves math; trust models supply identity. A perfect signature from an unverified key proves only that someone holds the matching private key not who. The trust model is what turns “a valid key” into “Alice’s valid key.”

Why it matters: crypto feels like an unlearnable pile of acronyms until you stop memorizing algorithms and start mapping tools to jobs. Confidentiality → symmetric (fast, but you must share the key). Authentication, non-repudiation, key exchange → asymmetric (slow, solves key sharing). Integrity → hashing (one-way, tamper-evident). Then the insight most foundations skip: every one of those leans on a trust model to make a key believable web of trust, trusted third party, or certificates. Get that four-part map and the whole field TLS, signed software, your browser’s padlock stops being magic and becomes legible. You’ll know not just what AES or RSA or SHA is, but which problem it was built to solve, and what still has to be true (trust) for any of it to mean anything.

References