Equal Blocks in the Badge Export
A contractor stores badge-reader exports as "encrypted" blobs: each record is exactly 48 bytes encrypted with AES-128 in ECB mode, then Base64-encoded. Each record is laid out as three 16-byte fields - badge ID (right-padded with spaces), site code, and access tier. A red-team analyst has 4,000 records and no key. She notices the blobs for badges 4471 and 9902 share identical second and third blocks, while badge 1180 shares no block with either. Badge numbers vary from three to five digits. Her lead says ECB is "just a style choice" because the output is Base64-encoded anyway and each record is only 48 bytes.
1. What does ECB leak here, and what can the analyst actually infer without a key?
Read the worked answer
ECB is deterministic and stateless: identical 16-byte plaintext blocks produce identical ciphertext blocks. That turns the ciphertext into an equality oracle at block granularity.
Direct inference from the three records: badges 4471 and 9902 share block 2 and block 3, so they are at the same site and same access tier. Badge 1180 matches neither, so it differs in at least one of those fields.
Inference across all 4,000 records: she can cluster records by block value, count distinct sites and tiers, identify which tier is the most common, find the block pattern for privileged access, and - once she matches block values to one badge she already knows (an employee ID on a public org chart, say) - read the site and tier of every other record by substitution, with no cryptanalysis at all. If block 1 is unique for every record, she also learns that badge IDs are unique and less than 16 digits. Because site codes come from a small known list, she can also mount an offline dictionary attack, encrypting candidates and matching blocks directly.
2. The lead argues that Base64 and a 48-byte record size make the mode choice irrelevant. Address both claims and give the correct fix.
Read the worked answer
Base64 is a transport encoding, not a control. It is reversible by anyone; it hides nothing about block equality, which is visible after trivial decoding.
48 bytes is exactly three 16-byte blocks, with no padding block. That is not a safety property - it confirms the record is block-aligned with fixed field boundaries, which is precisely the structure that makes ECB's block-level leakage so productive. It also tells the analyst where each field starts and ends.
Correct fix: authenticated encryption with a fresh random nonce per record - AES-GCM (or AES-CTR plus HMAC) - so identical plaintexts produce unrelated ciphertexts and tampering is detected. CBC with a random, unpredictable IV also hides equality, but only if IVs never repeat, and CBC provides no integrity, so it is not the recommended replacement. Key management belongs outside the export pipeline. The test of the fix: encrypt the same badge record twice and confirm the two outputs share no bytes.
3. Does the record size and block size tell the analyst the key length? What can and cannot be inferred from ciphertext alone?
Read the worked answer
No. A 16-byte block identifies a 128-bit block cipher (AES, in practice) but says nothing about whether the key is 128 or 256 bits - AES-128 and AES-256 outputs are indistinguishable without the key. The "AES-128" label in this case came from the contractor's documentation, not from the data.
What ciphertext alone does reveal here: block size (16 bytes), record granularity (three blocks, no padding), field boundaries, whether two plaintext blocks are equal, whether a field is constant across records, and the cardinality of low-entropy fields via clustering and dictionary matching. What it does not reveal: the key, the key length, plaintext content of a block that appears only once, or whether a mismatch means different site or different tier - block equality proves sameness, block inequality does not tell you which field differs.