EECC common mistakes
EECC · Understand the traps and how to avoid them.
Confusing the security goals of confidentiality, integrity, authentication, and non-repudiation when asked which property a given primitive or mode provides, e.g. claiming a block cipher mode alone guarantees integrity or that encryption prevents tampering.
Candidates learn primitives by name rather than by the property they deliver, and forget that unauthenticated encryption (e.g. plain CBC or CTR) is malleable and provides no integrity check.
What to do instead
Build a property matrix: for each primitive (AES-CBC, AES-GCM, RSA-OAEP, HMAC, digital signature, keyed hash) list which of confidentiality, integrity, authenticity, and non-repudiation it gives and under what key setup. Drill on the rule that authenticated encryption (GCM, CCM, encrypt-then-MAC) is required when both confidentiality and integrity are needed.
Mixing up block cipher modes of operation, describing ECB as secure for multi-block data, treating IVs as secret, or reusing a nonce/IV with CTR or GCM.
Mode diagrams look similar and candidates memorize names without understanding the counter/feedback structure, so they miss that ECB leaks patterns and that IV reuse in stream-like modes breaks confidentiality catastrophically.
What to do instead
Trace one block through ECB, CBC, CTR, and GCM on paper and note where the IV/nonce enters and what happens on reuse. Memorize: IV is public but must be unique/random per encryption; ECB is deterministic and pattern-leaking; GCM nonce reuse destroys both confidentiality and the authentication key.
Applying symmetric reasoning to asymmetric keys, e.g. saying the sender encrypts with their own private key to send a confidential message, or that a public key can decrypt data encrypted with itself.
The 'private key decrypts what the public key encrypts' rule from key exchange gets overgeneralized, and the signature use of private keys gets conflated with encryption.
What to do instead
Anchor on the purpose: to send confidential data to Bob, encrypt with Bob's public key (only Bob's private key decrypts). Signing uses the sender's private key and is verified with the sender's public key; that provides authenticity and non-repudiation, not confidentiality of the message body. Practice sorting scenario descriptions into 'encrypt for recipient' vs 'sign as sender'.
Assuming a hash function provides confidentiality or that hashing a password with a fast general-purpose hash (MD5, SHA-1, SHA-256) is adequate storage, or treating encryption and hashing as interchangeable.
Hashing is introduced alongside encryption in introductory material, and the one-way property is confused with secrecy; candidates also miss that fast hashes are brute-forceable for low-entropy passwords.
What to do instead
State the invariant: a hash is one-way and collision-resistant but reveals nothing secret only if the input has high entropy; it is not encryption and cannot be reversed. For password storage use a salted, memory-hard KDF (Argon2, scrypt, bcrypt, PBKDF2 with high iterations). For message integrity use HMAC or a signature, not a bare hash.
Misreading certificate chain validation: trusting a self-signed leaf, ignoring expiry or hostname mismatch, or not checking revocation, and confusing the roles of root, intermediate, and leaf certificates.
The chain-of-trust model is abstract and candidates treat 'has a certificate' as 'is trusted', forgetting that trust flows from a pre-installed root through intermediates to the leaf and that name, validity, and revocation are separate checks.
What to do instead
Walk a validation checklist in order: signature chain up to a trusted root, validity period, subject/SAN matches the hostname, key usage permits the operation, and revocation status (CRL/OCSP). Remember roots are self-signed and trusted by distribution, intermediates are signed by roots, leaves are signed by intermediates and are never used to sign other certs.
Confusing digital signature schemes and their parameters, e.g. thinking RSA signatures encrypt the message, or that DSA/ECDSA signing and verification use the same key or that ECDSA signatures are recoverable without the public key.
Signature and encryption both use asymmetric keys, so the operations blur; candidates also skip the role of the hash in the signature and the difference between deterministic (RSA PKCS#1 v1.5) and randomized (ECDSA, PSS) schemes.
What to do instead
Write the signing equation for each family: RSA signs a hash with the private exponent and verifies with the public exponent; DSA/ECDSA sign a hash with the private key and a per-message nonce k and verify with the public key. Emphasize that the message is hashed first, that ECDSA nonce reuse leaks the private key, and that verification always needs the signer's public key.
Treating TLS, IPsec, SSH, and S/MIME as single opaque protocols, so questions about which layer they operate at, what they protect, or how key exchange and authentication are separated are answered by guesswork.
Protocols are studied as configuration recipes rather than as compositions of key exchange, authentication, and record protection, so the handshake's purpose and the meaning of 'encrypt-then-MAC' inside a record layer are not internalized.
What to do instead
For each protocol draw a three-part diagram: key exchange (e.g. ECDHE), authentication (certificates or pre-shared keys), and record/channel protection (AEAD). Map each to its layer (TLS above transport, IPsec at network, SSH at application/session). Then answer scenario questions by naming which phase provides the property being asked about.
Naming an attack without matching it to the correct weakness: calling a padding-oracle attack a brute-force attack, describing a meet-in-the-middle attack as applicable to RSA, or confusing chosen-plaintext with known-plaintext models.
Attack names are memorized as vocabulary rather than tied to the assumption (what the attacker can observe or submit) and the target (key, plaintext, or implementation).
What to do instead
Build an attack table with columns: attacker capability (ciphertext-only, known-plaintext, chosen-plaintext, chosen-ciphertext), target primitive, and exploited weakness. Place padding oracle under chosen-ciphertext against CBC with padding, meet-in-the-middle under double encryption key search, and side-channel attacks under implementation leakage rather than algorithm weakness.
Confusing standards bodies and what each document actually specifies, e.g. attributing AES to RFC, treating FIPS 140 as an algorithm standard, or mixing up key sizes and security levels across AES, RSA, and ECC.
Standards are listed as acronyms without the scope of each body (NIST FIPS/SP, IETF RFC, ISO/IEC, ANSI X9), and equivalence between key sizes is assumed to be linear.
What to do instead
Make a reference sheet: FIPS 197 defines AES, FIPS 180-4 defines SHA-2, FIPS 186-5 defines digital signatures, SP 800-38 covers modes, SP 800-57 covers key management, FIPS 140-3 covers module validation, and IETF RFCs cover TLS and PKIX profiles. Add the rough equivalence table (AES-128 ≈ RSA-3072 ≈ ECC-256) and note that RSA and ECC key sizes are not comparable by bit length.
Ignoring key management lifecycle questions: not distinguishing key generation, distribution, storage, rotation, and destruction, or assuming key escrow, key wrapping, and key derivation are the same operation.
Key management is treated as an operational afterthought, so candidates answer algorithm questions correctly but fail scenario items about rotation intervals, separation of duties, or protecting keys at rest.
What to do instead
Learn the lifecycle as a sequence and the purpose of each control: generation in a validated RNG/module, distribution via key wrapping or asymmetric transport, storage in an HSM or protected keystore, rotation on cryptoperiod expiry or compromise, and destruction by zeroization. Distinguish KDF (derive keys from a secret), key wrapping (encrypt a key for transport or storage), and escrow (third-party recovery).