Is encrypting a single 128 bit block with AES ECB "safe"

Question

I want to encrypt a small piece of data that is less that 16 bytes in size (think SSN), and I'll be using a 256bit encryption key. The typical suggestion is to never use ECB, but if there is just a single block being encrypted, is it a concern?

The reason I want to use ECB is because I want the encrypted value of the block to be consistent between encryptions for other reasons (so I can check if a value already exists by just comparing the uniqueness of the cipherText).

Updated: Also note that these encrypted values will be stored in a set, so there will not be data leakage by having multiple encrypted values of the same plainText available.

Answer 1

16 bytes is 128 bits, which matches the block size of AES-256, but not "256 bit block" in the (original) title. Hence the question is ambiguous: was it meant 16, or 32 bytes?

For 16 bytes: ECB reduces to single-block encryption, and yes ECB is safe, for a definition of safe that let one test identity of plaintexts by testing identity of the ciphertexts.

For 32 bytes (e.g. a US SSN encoded in UTF16 or perhaps ASN.1 or XML): no, ECB is unsafe. This extend to any standard block cipher mode of operation modified by fixing IV. Problem is, plaintexts that match in the first block, but not the second, will match in the first block of the ciphertext, but not the second, which leaks information (e.g. in the US SSN format, it allows to cluster plaintexts by identical area number if the block frontier happens to be on the right of that). You need a 256-bit block cipher, such as Rijndael (a superset of AES) instantiated with 256-bit block. There are ways to construct a 256-bit block cipher from AES-256, but I know none with both a sound security argument and either a short statement, or performance close to Rijndael.

Note: Public key encryption can not be used in the context where "encrypted value of the block (is) to be consistent between encryptions" and the plaintext is low-entropy (enumerable, or guessable). Here, there are few enough SSNs that they can all be enciphered by anyone (knowing the public key), and compared with the ciphertext, leaking the plaintext.

Update: it is now clear that the question is about 16 bytes. I wonder if some day, UTFx with x>8 will catch in the US.

Answer 2

Thomas' comment is correct. While, theoretically, ECB is perfectly acceptable for use in a single block, the lack of any IV means your crypto system will leak information if you ever encrypt the same plaintext with the same key. Even if you are encrypting discrete messages, I highly recommend using something that has an IV to prevent this kind of attack.

Though I don't know what application you are thinking of, in many cases when you are encrypting SSNs or similar, it may be worth using public/private key cryptography so as not to require having the private key anywhere on the machines that are accepting the input.