EUC-EO common mistakes
EUC-EO · Understand the traps and how to avoid them.
Treating encryption and hashing as interchangeable, so a candidate says a password should be 'decrypted' or that a hash 'encrypts' data, and picks a hash when confidentiality is required or a cipher when integrity is required.
Both are described as 'scrambling' data in casual study material, and the candidate never builds a clean mental split between reversible keyed transformation (encryption) and one-way fixed-length digest (hashing). Exam items deliberately test this boundary.
What to do instead
Before answering, ask two questions: must the original be recoverable (encryption) and must tampering be detectable without recovering the original (hash/MAC). Memorize the one-line rule 'encryption = confidentiality, hashing = integrity, MAC = integrity plus keyed authenticity' and apply it to every scenario item.
Assuming AES always means 256-bit keys, or that a longer key makes a weak mode safe, and then choosing 'AES-256' as the fix for a problem that is actually about ECB mode or a reused IV.
Marketing language equates 'AES-256' with 'secure', and the candidate conflates key length with mode-of-operation properties. Exam items often present a strong cipher in a broken mode to see if the candidate notices.
What to do instead
Separate the two axes explicitly: cipher and key size give resistance to brute force; mode and IV/nonce handling give semantic security. When a scenario mentions identical ciphertext blocks for identical plaintext or a repeated IV, the answer is a mode/IV fix (CBC with random IV, CTR/GCM with unique nonce), not a bigger key.
Confusing the roles of the two asymmetric keys, for example saying the sender encrypts with its own private key to keep a message confidential, or that a signature is verified with the signer's private key.
Textbook diagrams show 'encrypt with public, decrypt with private' and 'sign with private, verify with public' as symmetric-looking pairs, and candidates memorize one and apply it to both operations.
What to do instead
Anchor on purpose, not direction: confidentiality means only the recipient may read, so use the recipient's public key to encrypt; authenticity means anyone may check who sent it, so sign with the sender's private key and verify with the sender's public key. Write both sentences from memory before the exam and test each option against them.
Choosing a plain hash such as SHA-256 as a message authentication code, or accepting a 'hash(secret || message)' construction, when the item asks how to detect tampering by an active attacker.
Candidates learn that hashes detect change and stop there, missing that an unkeyed digest can be recomputed by anyone who alters the message, and that naive secret-prefix concatenation is vulnerable to length-extension attacks.
What to do instead
Map the threat model first: accidental corruption only needs a checksum or hash; an adversary who can modify data needs a keyed MAC (HMAC) or an authenticated mode (GCM, CCM). Remember HMAC exists precisely to avoid length-extension problems of secret-prefix hashing.
Believing a digital signature provides confidentiality, or that encrypting a message also proves who sent it, and answering items on S/MIME or PGP accordingly.
Signatures and encryption are often deployed together in the same product, so candidates attribute the combined guarantee to each individual mechanism.
What to do instead
State the guarantee of each primitive in one word: signature = authenticity and integrity plus non-repudiation; encryption = confidentiality. For 'signed and encrypted' scenarios, identify which operation supplies which property, and note that signing does not hide content.
Judging certificate trust by the subject name alone, ignoring the chain to a trusted root, validity dates, revocation status, and the name constraints or key usage in the certificate.
Candidates see a certificate 'issued to bank.example' and treat the name as proof, skipping the path-building and revocation checks that real validators perform.
What to do instead
Walk a fixed checklist for any certificate item: who signed it, does the chain terminate in a trusted root in the relying party's store, is it within its validity window, is it revoked (CRL or OCSP), and do key usage and subject alternative names permit the intended use. Answer based on the first failing check.
Describing key distribution as 'send the key encrypted with the same key' or storing keys alongside the ciphertext, and failing to distinguish key-encryption keys from data-encryption keys.
Key management is abstract and candidates collapse it into a single 'keep the key secret' slogan, missing envelope encryption, key wrapping, and separation of duties.
What to do instead
Learn the envelope pattern as a story: a random data key encrypts the data, a long-lived key-encryption key or public key wraps the data key, and the wrapped key travels with the ciphertext while the wrapping key stays in a KMS or HSM. For storage items, prefer HSM/KMS-backed keys, rotation, and split knowledge over any scheme that ships the key next to the data.
Mixing up TLS, IPsec, and SSH at the wrong layer, for example saying TLS protects all IP traffic, that IPsec runs above TCP, or that SSH is used to secure web sessions.
All three are 'secure channel' protocols and study guides list them together without stressing the layer and typical use, so candidates pattern-match on the word 'secure'.
What to do instead
Build a layer table: IPsec at network layer protecting host-to-host or gateway traffic (AH for integrity, ESP for confidentiality plus integrity); TLS above TCP protecting application sessions such as HTTPS; SSH at application level for remote shells, file transfer, and tunneling. Answer by locating the scenario's layer and use case first.
Treating steganography as encryption, so an item about hiding the existence of a message is answered with 'encrypt it' or 'use AES', and conversely assuming a steganographic payload is unreadable without the key.
Both conceal content and both are used in 'secret communication' examples, so the different goals (confidentiality of content versus concealment of the fact of communication) blur together.
What to do instead
Memorize the pair: cryptography hides the meaning, steganography hides the presence. Note that steganography is usually combined with encryption for defence in depth, and that detection tools (statistical analysis, file-size and metadata anomalies) can reveal a hidden payload even without extracting it.
Naming a defense without matching it to the attack class, for example answering 'use a salt' for a brute-force attack on a cipher, or 'use a longer key' for a padding-oracle or timing attack.
Candidates memorize a list of countermeasures and retrieve the most familiar one rather than classifying the attack first, and oracle and side-channel attacks are conceptually harder than brute force.
What to do instead
Classify the attack before choosing: brute force and dictionary attacks on passwords call for salts, slow KDFs, and length; padding oracles call for authenticated encryption and uniform error handling; timing and side channels call for constant-time comparison and blinding; chosen-ciphertext issues call for AEAD or proper padding checks. Practise labeling a scenario with its attack class, then recall the matching control.