AES encryption of 16 bytes without salt

Question

How secure is it to encrypt 16 bytes of data as a single block with AES? No salt/IV, no mode of operation, millions of different 16 byte blocks encrypted. I don't know enough about crypto but this smells to me.

Edit: to give a bit more detail this is not about encrypting a message but a database table column where the plain text length happens to be 16 bytes. The data is not totally random (the first 8 bytes will frequently be the same) and there is a checksum to identify a successful decryption.

I'm going into a meeting with the guys proposing this next week and, if there is a problem, would greatly appreciate some pointers to reference material with which I can show that the design is insecure. I'm not totally familiar with the system but I think this could require a major redesign to get around so there is likely to be a lot of resistance. Most of the people (and the power) involved are on the business side where the motivation is to get a working system...

Answer 1

ECB is not secure for general use. A given plain text always encrypts to the same cipher text, so patterns can be revealed. However, there are special cases where it is safe, and this application may be one of them.

Quoting Applied Cryptography, second edition pg. 190, with regard to ECB mode for a block cipher:

On the plus side, there is no security risk in encrypting multiple messages with the same key. In fact, each block can be looked at as a separate message encrypted with the same key.

Later on (p. 208), Schneier says:

If simplicity and speed are your main concerns, ECB is the easiest and fastest mode to use a block cipher. It is also the weakest. Besides being vulnerable to replay attacks, an algorithm in ECB mode is the easiest to cryptanalyze. I don't recommend ECB for message encryption.

For encrypting random data, such as other keys, ECB is a good mode to use. Since the data is short and random, none of the shortcomings of ECB matter for this application.

The common prefix and check digit in your case won't produce common ciphertext. This happens only if an entire plaintext block is duplicated. From what you've described, your application may be a good fit for ECB—especially if each plain text value, as a whole, is unique.

Answer 2

Without a salt, also known as the initialization vector or IV, the security of the cyphertext (and, I believe, the key as well) is greatly reduced. A potential attacker will much more easily be able to make out repeating patterns in the encrypted text. IIRC this was the same basic mistake that Microsoft made when upgrading the MS Office encryption scheme.

Answer 3

AES is pretty strong against ciphertext-only attacks. However, encrypting a lot of plaintexts with the same key makes your system more vulnerable to known-plaintext and chosen-plaintext attacks.

That being said, if the encryption key is random, and if the plaintexts are seemingly random, you might still be safe. But I would definitely consider using different keys.

On the other hand, if the plaintexts are related to each other and/or not seemingly random, ECB is not secure at all.

Answer 4

I am not aware of any weaknesses in AES for short messages. The algorithm should be plenty happy.

To take to your meeting you do want:

1) A threat model (who may see what, when, and what happens when they leave or become a "bad guy).

2) Some use cases from your threat model.

With this you should be able to determine if you really need to salt AES and, does encryption really protect the value in the column if you can derive it elsewhere making the use of AES kinda pointless. Finally, ask the question, "Is the key truly safer than the data?" I've seen schemes like this where the key was the same size as the data (where size = "kinda small") and was just as accessible as the data it was protecting. Yes, it will buy you a few hours while the attacker figures out what on earth you've done, but it doesn't give you much in the way of solid security.

Hope that helps and gives you something to chew on. Not knowing your particular position, it's tough to tailor the answer. :)

Answer 5

In cryptography terms, this is insecure only if the attacker knows the specific algorithm and IV.

A certain assumption is made: Once decrypted, will the attacker know what the data looks like to know the decryption attempt was successful? e.g. Is there an MD5, CRC, or some form of checksum that can verify a successful decryption attempt? If so, you give the attacker a way to validate the attempt.

But in terms of hacking, there's still 2^128 combinations of keys (for 128-bit cipher), which is just as safe as using the same key on terabytes of data. Mode of operation is irrelevant because 16 bytes of data is only one block, so you cipher-block-chaining (CBC) doesn't apply.

However, the salt IV does apply and that value should be just as secret as the key itself. A rainbow table can be used to accelerate a brute force attack on ciphers not using a salt; this is your weak link.