Cryptography Study Portal

A: Encoding (e.g. Base64, hex, URL-encoding) is reversible with no key and provides no security — it's for safe representation/transport of data and anyone can decode it. Encryption is reversible with a key and provides confidentiality — without the key you can't recover the plaintext. Hashing is a one-way function — you can't recover the input — and is used for integrity checks and storing values you only need to compare (like passwords). The frequent failure is treating Base64 as if it were encryption.

A: Both are broken: practical collision attacks exist (you can find two inputs with the same hash), which destroys their use for digital signatures and certificates. They're also general-purpose fast hashes, so they're terrible for passwords. Use SHA-256/SHA-3/BLAKE2 for general hashing and a dedicated slow hash (Argon2id/bcrypt) for passwords.

A: SHA-256 is designed to be fast — a GPU can compute billions of hashes per second — so an attacker who steals the database can brute-force or dictionary-attack the hashes extremely quickly. Password hashing needs to be deliberately slow and memory-hard (Argon2id, scrypt, bcrypt) with a tunable cost factor, plus a per-password salt, so each guess is expensive.

A: Symmetric encryption (AES, ChaCha20) uses one shared secret for both encrypt and decrypt — it's fast and used for bulk data, but you must distribute the key securely. Asymmetric/public-key crypto (RSA, ECC) uses a public/private key pair — it solves key distribution and enables digital signatures but is much slower. In practice you combine them: asymmetric to authenticate and exchange a key, then symmetric for the actual data (this is exactly what TLS does).

A: ECB encrypts each block independently, so identical plaintext blocks produce identical ciphertext blocks. That leaks structure and patterns in the data (the classic "ECB penguin" image stays recognizable) and provides no integrity. Use an authenticated mode like AES-GCM with a unique IV/nonce per message instead.

A: An initialization vector or nonce is a value combined with the key so that encrypting the same plaintext twice yields different ciphertext. It must be unique per encryption under a given key (and for some modes unpredictable). Reusing a nonce with AES-GCM is catastrophic — it leaks the authentication key and lets an attacker forge messages — so generate a fresh CSPRNG nonce per message or use a guaranteed-unique counter.

A: Math.random() is a non-cryptographic PRNG — it's statistically predictable, and an attacker observing a few outputs can reconstruct its internal state and predict future values, letting them guess tokens, session IDs, or reset links. Use a CSPRNG instead (crypto.randomBytes/crypto.getRandomValues, secrets/os.urandom, SecureRandom, .NET RandomNumberGenerator).

A: In transit protects data moving over a network (TLS/HTTPS) against an attacker on the wire (MITM, sniffing). At rest protects stored data (full-disk, database/TDE, or field-level encryption) against an attacker who obtains the storage — a stolen disk, a leaked backup, or a database dump. A complete design needs both, plus integrity, because they defend against different threats.

A: HTTP Strict Transport Security is a response header telling the browser to only ever connect to the site over HTTPS for a set duration. It prevents SSL-stripping/downgrade attacks where an active attacker forces the first plaintext HTTP request and intercepts it. Adding includeSubDomains and submitting to the HSTS preload list closes the first-request gap.

A: Envelope encryption encrypts each piece of data with a unique data encryption key (DEK), then encrypts (wraps) that DEK with a key encryption key (KEK) held in a KMS/HSM, storing the wrapped DEK alongside the ciphertext. It lets you rotate the KEK cheaply (re-wrap DEKs instead of re-encrypting everything), keep the master key in hardware, and limit how much data any single key protects.

A: Cryptographic implementations fail in subtle, non-obvious ways — timing side channels, padding oracles, weak randomness, nonce reuse, incorrect mode choices — that aren't visible from "it produces ciphertext that decrypts correctly." Audited libraries and standard protocols (libsodium, the platform provider, TLS) have survived years of expert scrutiny. Custom ciphers and naive schemes (XOR-with-a-key, Base64-as-encryption) are almost always broken.

A: Developers disable validation (verify=False, rejectUnauthorized: false, "trust all certs") to silence errors from self-signed or expired certs in dev. But it silently removes the only thing that proves you're talking to the real server, so any man-in-the-middle can present their own cert and read/modify all traffic — fully defeating TLS. The fix is to trust the correct CA or use a proper dev certificate, never to disable validation.

A: Plain AES-CBC provides confidentiality but not integrity — ciphertext is malleable and vulnerable to padding-oracle attacks, and you'd need to bolt on a separate MAC (carefully, with encrypt-then-MAC). Authenticated encryption (AES-GCM, ChaCha20-Poly1305) provides confidentiality and integrity in one step: any tampering makes decryption fail, so you can't be tricked into processing altered ciphertext.

A: Keys belong in a dedicated key store — a cloud KMS, an HSM, or HashiCorp Vault — which provides access control, audit logging, and rotation. A key hardcoded in source, config, a container image, or client-side code is a leaked key: anyone with repo or image access (or who decompiles the client) gets it, and you can't rotate it without a code change. Treat all secrets the same way via a secrets manager.