5
$\begingroup$

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.

Improve this question
$\endgroup$
2
  • 3
    $\begingroup$ 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. $\endgroup$
    – Thomas
    Apr 20, 2013 at 5:41
  • $\begingroup$ Fixed the title to reflect a 128bit block (thanks) $\endgroup$
    – edhill
    Apr 20, 2013 at 14:22

2 Answers 2

Reset to default
3
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\begingroup$ 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. $\endgroup$
    – Henrick Hellström
    Apr 20, 2013 at 12:41
  • $\begingroup$ @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"? $\endgroup$
    – Paŭlo Ebermann
    Apr 21, 2013 at 17:05
  • $\begingroup$ 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? $\endgroup$
    – Henrick Hellström
    Apr 21, 2013 at 19:00
0
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\begingroup$ 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). $\endgroup$
    – fgrieu ♦
    Apr 20, 2013 at 10:23
  • $\begingroup$ Almost all public key encryption will include padding and enough randomness to prevent that kind of problem. $\endgroup$
    – Scrivener
    Apr 21, 2013 at 2:21
  • 1
    $\begingroup$ 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. $\endgroup$
    – fgrieu ♦
    Apr 21, 2013 at 7:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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