Cryptography & TLS

A certificate binds an identity (domain, organization) to a public key, signed by a trusted Certificate Authority (CA). A raw public key proves nothing about who owns it; the certificate adds the CA-vouched binding. Browsers trust it by validating the signature up a chain to a root CA they already trust.

Never store plaintext, and never use fast hashes like MD5/SHA-1 — they are brute-forced at billions/sec. Use a slow, salted password hash built for the job: bcrypt, scrypt, or Argon2. The unique per-user salt defeats rainbow tables; the slowness makes mass guessing infeasible.

Symmetric encryption uses one shared secret key to encrypt and decrypt (AES) — fast, but the key must be delivered securely. Asymmetric uses a key pair: a public key encrypts, a private key decrypts (RSA) — solves key delivery but is much slower.

It builds a chain from the leaf up to a root in its own trust store, checking every signature and that each intermediate is a CA allowed to sign certificates. It also checks validity dates, the hostname against the SAN entries, and revocation status. One failed link invalidates the chain.

Encryption alone hides data but detects no tampering — altered ciphertext still decrypts, into plaintext the attacker influenced. AEAD modes such as AES-GCM or ChaCha20-Poly1305 add an authentication tag, so any modification makes decryption fail instead of returning data.

Hashing is one-way — a fixed-size digest that cannot be turned back into the input. Encryption is reversible with a key and is what gives confidentiality. Encoding is a keyless, reversible change of format, so base64 hides nothing and protects nothing.

A salt is a unique per-user random value stored next to the hash; it makes identical passwords hash differently and defeats precomputed tables. A pepper is one secret held outside the database, in config or a KMS, so a stolen dump alone cannot be used to test guesses.

Forward secrecy means that recording traffic now and stealing the server key later still will not decrypt it. TLS 1.3 makes every handshake an ephemeral (EC)DHE exchange whose private values are discarded, and the certificate key only signs it — static RSA key transport is gone.

Use envelope encryption — a per-tenant key in a KMS or HSM wraps a per-object data key generated fresh for each document and stored beside its ciphertext. Rotation rewraps data keys, not data. Offboarding destroys the tenant key, so the wrapped data keys become useless. The KMS logs every unwrap.

A signature covers a hash of the data and verifies with a public key, so the payload stays readable — signing gives integrity, authenticity and non-repudiation, never secrecy. Encrypt-then-MAC is the safe symmetric order, and signature schemes must bind both parties inside the data.

Client and server agree on a cipher suite; the server then presents a certificate the client validates up the chain to a trusted CA. Asymmetric crypto derives a shared symmetric session key, and all bulk data is encrypted symmetrically — confidentiality plus server authentication.

ECB encrypts every block independently, so identical plaintext blocks give identical ciphertext and structure survives. CBC chains blocks and needs a random, unpredictable IV per message; CTR builds a keystream and needs a never-repeating nonce.

A symmetric key must reach every party over an already-secure channel, and each holder can both read and forge messages. Pairwise secrecy among n parties needs n(n-1)/2 keys, and removing one member rekeys everyone. A public key may be published — only its authenticity must be assured.

A key pair is mathematically linked: the public key can be shared freely, the private key is kept secret. What one key encrypts, only the other can decrypt. Encrypt with the recipient's public key for confidentiality; sign with your private key (verified by your public key) for authenticity.

Key length is comparable only inside one algorithm family. RSA rests on integer factoring, which sub-exponential methods attack, so its keys must be large. Elliptic curves rest on a discrete-log problem whose best attacks are square-root, so 256 bits give about 128-bit strength.

Repeating a GCM nonce under one key is catastrophic, not merely weak. The keystream repeats, so relationships between plaintexts leak, and the authentication subkey becomes recoverable, so integrity is lost for every message under that key. Fix with a per-message nonce and a new key.

A CRL is a signed list the client downloads periodically — bulky, and stale between publications. OCSP asks the CA about one certificate, costing a round trip and revealing browsing to the CA. Stapling has the server attach a fresh signed OCSP response, removing both drawbacks.

A hardcoded key shares the trust boundary of the code: it lives in the repository, in every build artifact and container image, and in the clone history of everyone who ever checked it out. It cannot be rotated without a redeploy, and one leak exposes everything encrypted under it.

Asymmetric crypto is slow and limited to small payloads (message ≤ key size), while symmetric is fast but needs the key delivered securely. Hybrid encryption combines them: generate a random symmetric key, encrypt the data with it, encrypt that key with the recipient's public key, and send both. This is how CMS/TLS protect bulk data.

Any trusted root may vouch for any domain, so the system is only as strong as its weakest CA — one mis-issuance produces a valid certificate for a site you own. Certificate Transparency records every issuance in public append-only logs, so owners spot certificates they never requested.

An adversary stores encrypted traffic today and decrypts it once RSA and ECC fall, so data with a long secrecy lifetime is already at risk. Migration starts with hybrid key exchange pairing a classical and a post-quantum KEM, then signatures; symmetric crypto only needs larger parameters.