Symmetric, Asymmetric, Hashing + Crypto Agility

Almost every control you will ever audit eventually rests on cryptography. "Data is encrypted at rest," "traffic is encrypted in transit," "passwords are not stored in plaintext," "audit logs are tamper-evident" — every one of those claims is a cryptographic primitive doing a specific job. You do not need to implement these primitives, and you will almost never be asked to choose an algorithm. But you must be able to tell which primitive belongs in which sentence, recognize when the wrong one is being used, and explain why "we encrypt the passwords" is a sentence that should make you nervous.

This lesson gives you the working mental model: the three families of cryptographic operation (symmetric, asymmetric, hashing), what each is actually for, how they combine into the envelope-encryption pattern every cloud uses, and why "crypto agility" — the ability to swap an algorithm out — is itself a control auditors increasingly ask about.

When the vendor says they 'encrypt' the passwords

Three families, three jobs

Cryptography in practice comes down to three kinds of operation. The single most useful thing you can do is keep straight what each one is for, because each protects a different property.

Symmetric encryption — one shared secret key both encrypts and decrypts. It is fast, which is why it does the bulk-data work: encrypting the disk, the database, the object in the bucket. The classic algorithm is AES (typically AES-256). Its weakness is the obvious one: everyone who needs the data needs the same key, so distributing and protecting that key is the entire problem.
Asymmetric encryption — a mathematically linked key pair: a public key anyone can hold, and a private key the owner guards. What the public key encrypts, only the private key can decrypt; what the private key signs, the public key can verify. It is slow, so it is not used for bulk data. Its jobs are key exchange (safely agreeing on a symmetric key over an open network — the heart of TLS) and digital signatures (proving who sent something and that it was not altered). Algorithms: RSA, and the more modern elliptic-curve family (ECDSA, Ed25519).
Hashing — a one-way function that turns any input into a fixed-length fingerprint. It is not encryption: there is no key and no way back. Its jobs are integrity (the same input always produces the same hash, so a changed file produces a changed hash) and verification without storage (you store the hash of a password, never the password). Algorithms: the SHA-2 family (SHA-256) for integrity; purpose-built password hashes (bcrypt, scrypt, Argon2) for credentials.

The reason "we encrypt the passwords" should worry you is now visible: encryption is reversible by design. If the system can decrypt a password to check it, so can an attacker who steals the key. Passwords should be hashed with a slow, salted password hash — a one-way operation — not encrypted. The verb gives away whether the vendor understands the control.

Encryption is reversible; hashing is not

This is the distinction that separates people who understand the controls from people repeating words. Encryption protects confidentiality and is meant to be undone with a key. Hashing protects integrity and is meant to never be undone. When a system needs to store something it should never be able to read back — passwords, above all — the right primitive is a one-way password hash (bcrypt/scrypt/Argon2), not encryption. "We encrypt the passwords" is a red flag, not a reassurance.

How they combine: envelope encryption

In the real world these primitives are not used in isolation — they are layered, and the dominant pattern across every cloud is envelope encryption. Understanding it once explains how AWS, GCP, and Azure all actually encrypt your data, and why the key hierarchy matters more than the algorithm.

The idea: you do not encrypt a terabyte of data directly with a key you carefully guard. Instead:

A fast symmetric data encryption key (DEK) encrypts the actual data.
That DEK is itself encrypted ("wrapped") by a key encryption key (KEK) that never leaves a hardened key-management service.
The wrapped DEK is stored next to the encrypted data; the KEK stays locked in the KMS.

To read the data, the service asks the KMS to unwrap the DEK (an access that is logged and authorized), uses the DEK to decrypt the data, then discards it. Rotating the KEK does not require re-encrypting petabytes — you only re-wrap the small DEKs. And because every unwrap is an authorized, logged KMS call, "who can decrypt this data" becomes a permission you can grant, revoke, and audit rather than a secret that has leaked into a dozen config files.

Envelope encryption: a fast data key protects the data, a guarded key encryption key protects the data key

This is why, when you read "encryption at rest is enabled," the interesting questions are almost never about the algorithm (it is AES-256 nearly everywhere). They are about the key: who controls the KEK, how often it rotates, who is allowed to ask for an unwrap, and whether those unwraps are logged. That is the substance of the next lesson.

Quick check

A vendor's security questionnaire says: 'All customer passwords are encrypted with AES-256 and can be recovered by our support team if a user is locked out.' What is the problem?

AES-256 is too weak for passwords; they should use AES-512

Passwords should be hashed with a one-way password hash (bcrypt/scrypt/Argon2), never encrypted; the fact that support can recover them proves they are reversible, which means a key compromise exposes every password

There is no problem — AES-256 is strong encryption and recovery is a helpful feature

The problem is only that they did not mention rotating the AES key

Crypto agility: the algorithm will be deprecated

Algorithms do not last forever. MD5 and SHA-1 were once standard and are now broken for security use. DES gave way to AES. RSA-1024 is no longer acceptable; the industry is already preparing for post-quantum algorithms because a future quantum computer could break today's RSA and elliptic-curve key exchange. The lesson of history is not "pick the perfect algorithm" — it is "assume today's algorithm will someday be deprecated, and make sure you can swap it without re-architecting."

That property is crypto agility: the ability to change algorithms, key sizes, or providers with minimal disruption. A system has it when algorithms are referenced by configuration rather than hard-coded, when keys are versioned and rotatable, and when there is an inventory of where crypto is used. A system lacks it when an algorithm is welded into a hundred places and nobody knows them all.

For a GRC Engineer, crypto agility shows up as concrete questions: Do we know everywhere we use cryptography? Could we move off SHA-1 / RSA-1024 / a deprecated TLS version if we had to, and how long would it take? Increasingly, frameworks and customers ask this directly, and "we have a cryptographic inventory and a documented migration path" is a far better answer than discovering the scope during an incident.

GRC Engineer's lens

You are not the cryptographer — you are the translator and the verifier. Your job is to map each control sentence to the right primitive ("encrypted at rest" → symmetric AES via a KMS-managed key; "tamper-evident logs" → hashing/signatures; "passwords protected" → one-way password hash), then verify the implementation matches the claim and that approved algorithms are in use. When you read a vendor answer or a control narrative, you should be able to flag the three classic tells: encryption used where hashing belongs, a deprecated algorithm still in play, and a key whose access nobody can account for. You do not need the math — you need to know which sentence each primitive belongs in.

What to carry forward

Three primitives, three jobs: symmetric for fast bulk confidentiality, asymmetric for key exchange and signatures, hashing for integrity and one-way verification. They combine into envelope encryption, which is why the real control is the key, not the algorithm. And crypto agility is the recognition that any algorithm will eventually be deprecated, so the controls worth verifying are inventory, configurability, and rotation.

The phrase "data is encrypted at rest" is now something you can interrogate rather than accept. In the next lesson we follow the key into the cloud key-management services — AWS KMS, GCP Cloud KMS, Azure Key Vault — and the distinction that decides who really holds the keys: CMK versus BYOK.