Can you tell if this ECB mode mitigation idea is “OK”?

Question

The context: you have to encrypt passwords (reversible, for accessing external services), and also some customer data for privacy reasons, and you need to use AES-ECB mode...

The idea to mitigate the worst of ECB is, we encrypt each single ''message'' with a new random key. Then we encrypt this unique key with a master key, and store it alongside the ''message'', while the master key is kept somewhere else completely.

(As additional measure, also ensuring that the encrypted unique key has its padding block filled with randoms, so the padding doesn't show up as repeating pattern either between the unique keys.)

When considering the general ECB issues, I take note of the fact that:

1. the master key will ever encrypt only random, single-block ''messages'' (the unique keys), and that
2. the most critical data to be protected is passwords, also of a single-block nature.

Makes any sense? Has any major issue? I was mainly concerned with avoiding the textbook-messup situation of an ecb mode password db where you could see every repetition of common passwords, making for extremely easy, non-specialist ''attacks''.

Answer 1

As already mentioned, if you've got ECB you can certainly design other modes of operation. Probably the easiest one to implement is CTR mode: you simply line up a number of counters (each of the block size of the underlying cipher) and then encrypt them using ECB. You can XOR the result with the plaintext to encrypt or decrypt data.

You'd still have to use a nonce for the initial counter value of course, if you want to reuse the same key.

---

Limiting passwords to a certain size is a bad idea. So is storing an encrypted password instead of storing a hash of the password.

If you use CTR mode I'd say limit the password size to 64 bytes and pad the password to that size using zero padding - then encrypt the result. That way you'd allow longer passwords and you would not leak the password size right away.

Answer 2

I was mainly concerned with avoiding the textbook-messup situation of an ecb mode password db where you could see every repetition of common passwords, making for extremely easy, non-specialist ''attacks''.

It seems your design avoids those types of ''attacks''. That said, it is an awful idea for many other reasons. Managing all those keys is a nightmare of complexity that you should not have to deal with. There is also extra computation overhead.

If you are working through this exercise for learning purposes, I suppose you have reached the desired goal of protecting against pattern analysis possible in ECB mode encryptions. If you are doing this for real-world purposes, there are much better options, and I suggest you hire an expert consultant for a few hours of their time looking at your problem and helping design a real-world solution.