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

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 2

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.

Answer 3

It is not secure to use the same key for multiple messages unless some cipher mode that takes an unpredictable initialization vector is used.

The confidentiality of a single block of ciphertext is secure if you generate a new key for each message. If your message spans multiple blocks, then you're using ECB mode, which can reveal patterns in the plaintext.

---

Update:

Alright, I cracked open a book and found some information that surprised me. 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.

I had understood the concern about re-using keys with a keystream generator to apply here, but that was a mistake.

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 is a good fit for ECB.

Answer 4

If your 16 byte data is randomly assigned and there's no real chance that two of them overlap (like usernames), then this is perfectly safe. 2²⁵⁶ is just way too big for any attack.

The only imaginable attack is to find duplicates. (Highly unlikely with 2²⁵⁶ possibilities.) Any dictionary-based or guessing attacks are just as easy to perform on non-salted encrypted data.

Answer 5

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 6

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. :)