2
$\begingroup$

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''.

$\endgroup$
  • 8
    $\begingroup$ If you can encrypt a single block with ECB, you can encrypt a multi-block message with other modes, like CBC. So why not just encrypt with CBC? Not specifically asked for in your question, but you have no integrity protection. Should use something like HMAC. $\endgroup$ – mikeazo Jan 13 '17 at 12:40
  • $\begingroup$ With the proposed method, each encrypted password requires 32, 40, or 48 bytes of storage (depending on if the auxiliary key is for AES-128, AES-192, or AES-256), and two or three encryptions using two different keys. Compare to 24 to 32 bytes (depending on size of IV), two encryptions using the same key, and one XOR, when using CBC. $\endgroup$ – fgrieu Jan 13 '17 at 13:19
  • $\begingroup$ To clarify further, you can very easily compose ECB into either CBC or CTR mode. And if you can build CBC, you can build CMAC to use as an authenticator on top. $\endgroup$ – Stephen Touset Jan 16 '17 at 7:52
  • 1
    $\begingroup$ If you can build CTR and CMAC you can build SIV, which was designed precisely for wrapping cryptographic keys (as well as just general AEAD). $\endgroup$ – Luis Casillas Jan 16 '17 at 19:29
3
$\begingroup$

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.

$\endgroup$
2
$\begingroup$

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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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