Repeating-Key XOR Disguised as AES
SecureBox is a file-sharing appliance sold to 40 clinics. Its marketing claims 'AES-256 encryption at rest.' A consultant finds that files are transformed by XOR with a repeating 16-byte key, where the key is the first 16 bytes of the MD5 digest of the user's password, and the result is Base64-encoded. Every file begins with the ASCII header PATIENT_RECORD_V3, followed by a fixed 128-byte metadata block. The appliance also stores 6-digit password-reset PINs as unsalted MD5 hashes in a local SQLite database. The vendor says the design is safe because MD5 and XOR are 'fast and lightweight' and the files are never shared outside the clinic. The consultant has 200 captured files and one known password. The clinics want a factual risk assessment, not a rewrite of the vendor's marketing.
1. Demonstrate how the file encryption can be broken with the available material. What is the minimum evidence needed to prove plaintext recovery?
Read the worked answer
Base64-decode a file first. The known header PATIENT_RECORD_V3 is 16 ASCII bytes, exactly the key length. XOR the first 16 ciphertext bytes with those header bytes to recover the 16-byte repeating key. Because the key repeats, that key decrypts the entire file and every other file encrypted under the same password-derived key. If the one known password is available, compute MD5(password), take the first 16 bytes, and compare; that confirms the derivation but is not required. If the header were unknown, the same attack works with crib dragging or by splitting the ciphertext into 16 columns and doing frequency analysis or index-of-coincidence on each column; the header just makes it trivial.
The minimum proof is recovered plaintext that matches the known header and the fixed 128-byte metadata block, plus successful decryption of a second file the consultant did not use to derive the key. That proves the design is broken without claiming AES is broken. Preserve hashes of the original ciphertext and plaintext for evidence.
2. Assess the PIN storage and the vendor's 'fast and lightweight' argument. What attack does unsalted MD5 enable, and what is the correct storage design?
Read the worked answer
A 6-digit PIN has only 1,000,000 possibilities. Unsalted MD5 lets an attacker precompute one table for all PINs and all clinics; on commodity GPUs, the entire space is exhausted in seconds to minutes. Because the hashes are unsalted, identical PINs produce identical digests, so the attacker can see which accounts share a PIN and target the most common values. 'Fast and lightweight' is precisely the wrong property for password or PIN storage; it is a property you want for bulk encryption with a proper AEAD, not for a low-entropy secret.
Store PINs with a per-PIN random salt and a memory-hard KDF such as Argon2id, plus a server-side pepper in an HSM or KMS. Enforce rate limiting and lockout, and treat the PIN as a weak second factor, not a password. If the PIN is used to unlock a key, derive that key with the KDF and bind it to the account. Migration requires forcing a reset because the old MD5 values cannot be strengthened retroactively.
3. Recommend a replacement architecture for the appliance that the clinics can require in procurement, with concrete parameters.
Read the worked answer
Require per-file AEAD: AES-256-GCM with a fresh random 96-bit nonce generated by a CSPRNG, and never reuse a nonce under the same key. Derive a per-user master key from the password with Argon2id, using a 16-byte random salt, 64 MiB memory, t=3, and p=1, then use HKDF-SHA-256 to derive per-file keys or wrap a random per-file data key. Authenticate the file header and metadata as AAD so the PATIENT_RECORD_V3 header cannot be altered. Store the nonce and wrapped key with the file.
For PINs, use Argon2id with a per-PIN salt and a pepper, plus rate limiting and lockout. Use a vetted library, not custom XOR or MD5. Require key rotation and a documented recovery process; if the vendor cannot export plaintext without the user key, test that claim. Procurement should ask for the exact algorithm, mode, nonce size, KDF parameters, and a third-party test report; 'AES-256' alone is not a specification.