The encryption techniques that matter, and what the industry uses by default

Most encryption decisions in a company are not about choosing an algorithm. They are about confirming that the standard choices are already in place, that a named person owns the keys, and that nobody has built something custom. This guide lists the techniques that matter, the default each one has today, and the questions to ask a vendor. Sources were checked in October 2026.

Which types of encryption matter, and what does the industry use by default?

Use the standard default for each job, and do not design your own. The table covers the techniques you will meet in cloud and AI work.

Symmetric encryption

Symmetric encryption uses one secret key to scramble data and the same key to restore it. It is fast, so it does the bulk work. In AES-256-GCM, AES is the cipher, 256 is the key length in bits, and GCM is the mode. GCM is authenticated encryption: it scrambles the data and also attaches a tag, so any tampering is detected on decryption. NIST describes it in SP 800-38D as an algorithm for authenticated encryption with associated data, and AWS says all symmetric encrypt commands inside its KMS hardware use AES in Galois Counter Mode with 256-bit keys.

OWASP says authenticated modes should always be used where available, names GCM and CCM as the first preference, and says ECB should not be used outside very specific circumstances. ECB encrypts identical blocks of input to identical output, which leaks patterns.

ChaCha20-Poly1305 is the other common choice. RFC 8439 says ChaCha20 is considerably faster than AES in software-only implementations, around three times as fast on platforms without specialized AES hardware, which is why it appears on older phones and small devices.

Asymmetric (public-key) encryption

Asymmetric cryptography uses a pair of keys: a public key you can hand to anyone and a private key you never share. It solves the problem symmetric encryption cannot, which is how two parties who have never met agree on a secret. It is slower, so it handles the start of a session and signatures, then a symmetric key takes over the bulk work.

RSA and elliptic-curve cryptography are the two families. AWS KMS supports RSA keys of 2048, 3072 and 4096 bits and elliptic curves including NIST P-256 and Ed25519. RFC 7748 defines two curves for key agreement at roughly the 128-bit and 224-bit security levels, and X25519 is the 128-bit one. RFC 8032 defines the EdDSA signature scheme, whose edwards25519 instance is Ed25519. In short, X25519 agrees on keys and Ed25519 signs.

How does TLS 1.3 protect data in transit?

TLS is the protocol under HTTPS. RFC 8446, published in August 2018, says TLS is designed to prevent eavesdropping, tampering and message forgery. TLS 1.3 removed the static RSA and Diffie-Hellman cipher suites, pruned the list of symmetric algorithms of everything considered legacy, and left only authenticated ones.

It also made forward secrecy standard. The RFC says all public-key key exchange mechanisms now provide it, which means a server key stolen next year cannot decrypt traffic recorded this year. The exception is 0-RTT data, a speed feature the RFC says is not forward secret.

The specification has since been reissued. RFC 9846 obsoletes RFC 8446, keeps the TLS 1.3 version number and forbids negotiating TLS 1.0 and 1.1. Those two older versions were formally deprecated in 2021 by RFC 8996.

For a business, the action is concrete. Configure load balancers and API gateways to refuse TLS 1.0 and 1.1 and to prefer 1.3. TLS protects one hop and ends at the server that terminates it, so traffic between your own internal services needs its own TLS.

How does encryption at rest work with AWS KMS and Azure Key Vault?

Both clouds use envelope encryption, which AWS defines as encrypting plaintext data with a data key, and then encrypting the data key under another key. The encrypted data key is stored beside the encrypted data, and the key that wraps it stays in a protected service.

Microsoft's documentation calls the two layers the data encryption key, an AES-256 key that encrypts a block of data, and the key encryption key, which encrypts the data keys and never leaves Key Vault. Bulk encryption stays fast because data keys are used locally, and control stays central because disabling the key encryption key makes dependent data unreadable. AWS adds that its KMS keys never leave FIPS 140-3 Security Level 3 validated hardware security modules unencrypted, so using one means calling the service.

Azure encrypts storage at rest by default with platform-managed keys. Customer-managed keys in Key Vault are optional and, in Microsoft's words, bring extra control at the cost of increased management responsibility and complexity. Most organizations can rely on platform-managed keys, and customer-managed keys make sense when a contract or regulation requires you to control the key lifecycle.

Key management is where real-world problems tend to sit, so it deserves a named owner. The algorithms above are public and heavily reviewed. What goes wrong is more often a key left next to its data, a role that can decrypt more than it should, or a rotation nobody has tried. OWASP advises storing keys in a separate location from encrypted data and having the code and processes to rotate a key in place before the day you need them.

Is hashing the same as encryption?

No. Encryption is reversible by anyone holding the key. A hash is a one-way fingerprint that cannot be turned back into the original. Passwords are the main business use, because a login system only needs to check a guess, never recover the password. OWASP states that passwords should not be stored using reversible encryption.

Password hashing uses deliberately slow functions, and the best of them (Argon2id) also demand memory, so each guess costs an attacker real resources. OWASP's Password Storage Cheat Sheet ranks them this way:

1. Argon2id is the first choice, at a minimum of 19 MiB of memory, 2 iterations and a parallelism of 1.
2. bcrypt is for legacy systems, with a work factor of at least 10 and a 72-byte limit on password length.
3. PBKDF2 with HMAC-SHA-256 at 600,000 iterations is the choice when FIPS-140 compliance is required.

Each password also gets its own random salt, so identical passwords produce different hashes. A practical test for any vendor: if its product can email you your existing password, it stores passwords reversibly.

Fast general-purpose hashes are a separate matter. RFC 6151 says MD5 is no longer acceptable where collision resistance is required, such as digital signatures. NIST announced the retirement of SHA-1 in December 2022, with a phase-out deadline of December 31, 2030, and recommends SHA-2 or SHA-3. NIST's 2017 notice on Triple DES urges all users to migrate to AES, because a 64-bit block cipher risks ciphertext collisions after about 2^32 blocks under one key.

What does end-to-end encryption add, and how does Signal do it?

End-to-end encryption means only the sender's and recipient's devices hold the keys, so the service in the middle cannot read the content. TLS alone does not give you this, because the server at the end of a TLS connection decrypts the traffic.

Signal's published specifications show the pieces. X3DH establishes a shared secret between two parties who authenticate each other with public keys. The Double Ratchet then derives new keys for every message, so earlier keys cannot be calculated from later ones, and Diffie-Hellman results mixed into the chain give some protection to later messages after a compromise. PQXDH is the post-quantum variant of the session setup. In October 2025 Signal announced SPQR, a further ratchet that uses ML-KEM and is combined with the Double Ratchet, and it says conversations will move over without user action.

For most business systems you do not need end-to-end encryption. It has a cost buyers miss: if the provider cannot read the content, neither can its search, its AI summaries or your records archive.

Do you need to act on post-quantum cryptography now?

You need to take stock now and change very little. A large quantum computer could break today's public-key methods, and an attacker can record encrypted traffic now to decrypt later, so key exchange is moving first.

On August 13, 2024, NIST published three standards. FIPS 203 specifies ML-KEM, a key-encapsulation mechanism NIST says is believed secure even against adversaries with a quantum computer. FIPS 204 specifies the ML-DSA signature scheme, and FIPS 205 specifies SLH-DSA, a stateless hash-based signature scheme based on SPHINCS+. NIST's transition report, IR 8547, is listed as final on October 27, 2026.

The practical deployment is hybrid key exchange. X25519MLKEM768 runs the classical X25519 exchange and ML-KEM together, so a session stays protected unless both are broken. Cloudflare reports it enabled by default in Chrome on desktop in March 2024, in Chrome on Android and Firefox on desktop in November 2024, and in Apple's operating systems from October 2025. In the last week of October 2025, Cloudflare said the majority of human-initiated traffic through its network used post-quantum encryption.

For a 20 to 200 person company the work is modest. Keep browsers, TLS libraries and cloud services current, ask vendors for their post-quantum plan, and list where long-lived sensitive data travels. AWS KMS already lists ML-KEM and ML-DSA key specifications, so adoption can come through the provider.

What does encryption not protect against?

Encryption protects data from people who lack the key. It does little against identities the system already trusts.

• Stolen credentials. A valid login or cloud access key is allowed to decrypt. AWS notes that using a KMS key means calling the service, so any identity with permission to call it gets plaintext back.
• Plaintext sent to an AI vendor. TLS protects the prompt on its way to the model provider, then the provider decrypts it to process it. Treat what you send as readable by that vendor. The wider controls are covered in data security and governance for AI.
• Compliance by itself. Encryption helps meet requirements such as those in HIPAA and PCI, and it is not a compliance outcome on its own.

Illustrative example: Consider an 80-person distributor that stores customer contracts in cloud object storage with encryption at rest switched on. A former contractor's access key is never revoked, and the contractor's role is permitted to use the encryption key. When the key is later pasted into a public code repository, the files download in readable form, because the storage service decrypts them for any permitted identity. The encryption worked as designed. The failure was an unreviewed permission, which key-use reviews and short-lived credentials would have caught.

What should you ask a vendor about encryption?

Ask for documentation, not assurances. These questions suit any SaaS, AI or hosting provider.

1. Which TLS versions do you accept, and are 1.0 and 1.1 disabled?
2. How is our data encrypted at rest, and are the keys platform-managed or customer-managed?
3. Which roles and services can use the key, and how often is that access reviewed?
4. How are keys rotated, and has a rotation been tested on production data?
5. How do you store passwords? The answer should name Argon2id, bcrypt or PBKDF2, never reversible encryption.
6. Is our data sent to a model provider in readable form, for how long is it kept, and can it be used for training?
7. What is your plan for post-quantum key exchange?
8. Does any part of your product use cryptography you wrote yourself? Anything other than no is a reason to stop. OWASP's section on custom algorithms says only "Don't do this."

How Kastling approaches encryption in cloud and AI projects

Kastling would start by mapping where data lives, who and what touches it, and which systems it moves between, because that decides which controls matter. It would use the encryption services in AWS or Azure, such as KMS and Key Vault, instead of custom code, connect to the systems you already run, and keep a named person in control of decisions about key access. Success is agreed up front, for example that every key-use permission has been reviewed and vendors have answered the questions above in writing. This work sits within AI & Cloud Infrastructure, and the cloud choice itself is covered in AWS or Azure for AI.