Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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.

share|improve this question
Well, putting aside the problematic fact that AES uses a 128-bit block regardless of the key size (you may want to fix that), it depends. If you encrypt it multiple times, an observer can know the same SSN (or whatever) is used at two different places, which may leak information. –  Thomas Apr 20 '13 at 5:41
Fixed the title to reflect a 128bit block (thanks) –  edhill Apr 20 '13 at 14:22

2 Answers 2

up vote 3 down vote accepted

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.

share|improve this answer
SHACAL-2 (i.e. the compression function of SHA-256) is a block cipher with a 256 bit block, which was approved e.g. by NESSIE. FWIW, considering the security proof of the Davies-Meyer construct, I presume SHACAL-2 might be assumed to be a secure block cipher if SHA-256 might be assumed to be a CSOWHF. –  Henrick Hellström Apr 20 '13 at 12:41
@HenrickHellström Doesn't the proof goes in the other direction? Or do you mean "if SHA-256 is believed to be secure based on this proof"? –  Paŭlo Ebermann Apr 21 '13 at 17:05
The latter, but it is an intriguing question on its own. Is it generally possible to break collision resistance of a Merkle-Damgaard chaining of a Davies-Meyer construct that is built around a compression function that is not pseudo random? –  Henrick Hellström Apr 21 '13 at 19:00

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.

share|improve this answer
OK for the first paragraph. But public key crypto is a bad idea given the "encrypted value of the block (is) to be consistent between encryptions": it is extremely unsafe, since there are few enough SSNs that they can all be enciphered by anyone (knowing the public key). –  fgrieu Apr 20 '13 at 10:23
Almost all public key encryption will include padding and enough randomness to prevent that kind of problem. –  Scrivener Apr 21 '13 at 2:21
Indeed, public key encryption is usually randomized. But then it does not match the "encrypted value of the block (is) to be consistent between encryptions" nor support the "check if a value already exists by just comparing the uniqueness of the cipherText" requirements worded in the question. –  fgrieu Apr 21 '13 at 7:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.