Free Encryption: Symmetric, Asymmetric, and Key Exchange practice questions

Kerckhoffs's principle says a cipher's security should rest entirely on the key, not on hiding the algorithm, so relying on a secret design is security through obscurity. Forward secrecy protects past sessions after a key theft, non-repudiation is about proving who signed something, and key stretching slows password guessing; none of them is about hiding an algorithm.

GCM is an authenticated encryption (AEAD) mode: it adds an authentication tag, so altered ciphertext fails to decrypt instead of returning changed data. CBC provides confidentiality only and needs a separate integrity check, ECB leaks patterns and checks nothing, and RC4 is a broken stream cipher with no built-in integrity check.

Reusing a nonce under the same key makes ChaCha20 produce the same keystream twice, so XORing the two ciphertexts cancels it and leaves the XOR of the two plaintexts, from which both messages can often be recovered. The key itself is never revealed or weakened, so answers about deriving or brute-forcing the key miss the point; the flaw is the repeated keystream, not the key length.

A key is only as strong as the way it was made: anyone who guesses the password can rerun the same hash and get the key, which takes far fewer attempts than searching 2^256 keys. Keys should come from a cryptographically secure random generator, or from a password run through a deliberately slow key derivation function. A SHA-256 digest is already 256 bits, and AES keys don't have to come from a key exchange or an HSM.

3DES and Blowfish both use 64-bit blocks, and after roughly 32 GB under one key, repeated blocks become likely and start to leak plaintext, as the Sweet32 research showed. The 56-bit key is DES's flaw (3DES is about 112 bits effective and Blowfish allows up to 448), the biased keystream describes RC4, and both are block ciphers, not stream ciphers. The fix is to require AES-GCM or ChaCha20-Poly1305.

An RSA modulus is the product of two large primes, and anyone who could factor it back into those primes could rebuild the private key. Discrete logarithms are the hard problem behind Diffie-Hellman and elliptic curve cryptography, finding matching hashes is a hash function concern, and searching every key is a brute-force attack on symmetric ciphers.

ECC reaches the same strength as RSA with far smaller keys, which means less computation, smaller messages and less battery drain, and ECDSA is the elliptic curve signature algorithm. RSA-4096 works but is slow and bulky for low-power devices, AES-GCM is symmetric and gives no public key identity, and Diffie-Hellman agrees on keys rather than creating signatures.

Diffie-Hellman doesn't prove who is on the other end, so an on-path attacker can run one exchange with each application and relay everything between them. With a 3,072-bit group, an eavesdropper can't compute the secret from the public values, because that would mean solving a discrete logarithm. The fix is to authenticate the exchange, as TLS does by having the server sign its Diffie-Hellman value.

S/MIME uses key transport: the client encrypts the message once with a random symmetric key, then encrypts that small key with each recipient's public key, so each extra recipient adds only a few hundred bytes. RSA can't encrypt anything larger than its key, so it never encrypts the full 50 MB, and anything encrypted with the sender's private key could be read by anyone with the public key. Diffie-Hellman key agreement is how live sessions such as TLS work, not stored email.

A 256-bit elliptic curve key such as P-256 provides about 128 bits of strength, the same as AES-128 or RSA-3072. RSA-2048, 3DES and a 224-bit curve all rate about 112 bits, so each falls short despite key sizes that look large. Bit counts only compare within one algorithm family.