6

I need to save random 16 byte keys to a database. To encrypt these keys I currently use AES 128 with ECB Mode (because of smaller data to store, no IV needed), but now I read a lot about ECB being unsafe and should never be used.

I thought in this case (random data, just a single block) using ECB would be fine, but I'm no expert, so I would like to know whether this is right, or should I better switch to CBC to make it secure?

Scott Pack
  • 15,167
  • 5
  • 61
  • 91
Ruu
  • 61
  • 1
  • 2
  • 1
    What is the key protecting? How is the database protected? How many entries are in the database? Would it be possible for an adversary to guess some of the encrypted information (known plaintext attack) ? – this.josh Aug 23 '11 at 08:31
  • 1
    the keys are used to encrypt text data and files using CBC Mode with random IV. There are many thousands of keys, so I wanted to avoid generating and saving another IV for encrypting the keys. All guessable/structured data is encrypted with CBC mode. – Ruu Aug 23 '11 at 08:59

4 Answers4

4

If you only have ONE block, using other modes such as CBC does not offer extra security. Remember, the only secret here should be the key to encryption/decryption. IV is usually a known entity. If you hope to achieve better security by making IV a secret, you are approaching it from a wrong direction.

Saying so, I would still not recommend ECB ;). Think about two users having a same password. Their encrypted passwords are also the same, due to the "code book" nature of ECB.

In your case, I would probably use CTR mode with the counter value being simply the ID of the user.

Nam Nguyen
  • 1,450
  • 12
  • 14
  • Thank your for the advice! the chance that two keys are the same is pretty small (16 bytes from /dev/urandom). I didn't mean to make the IV secret, just want to save the additional overhead of generating and saving another IV for each of those keys. – Ruu Aug 23 '11 at 12:16
  • To correct the answer slightly, passwords should never directly be used as keys for modern encryption algorithms. You should use a KDF like PBKDF2 to derive your key from the password and a cryptographically random salt (the same size as the key being generated). So no two users should *ever* share the same key. Additionally, *authenticated* modes of encryption such as GCM do offer extra potential benefits over and above straight ECB. – Stephen Touset Jul 11 '13 at 22:29
3

If the keys are truly random ECB should be fine. However, in general you should not rely on this. Proper security design is to make the least necessary assumptions on the underlying data but simply work for all possible cases. So in my opinion you should only do this if the additional costs for the IV are really bad.

Moreover, I'd like to point out that you are not protecting the keys against manipulation. If some bits get flipped in that encrypted data field you'll never know that it happened, until some layer further up finds out that the key supplied by your system does not work. And then you still don't know if you entered the right key or if the storage is bad/manipulated. AES-GCM or CCM will tell you if the encrypted data was tampered with.

pepe
  • 3,536
  • 14
  • 14
1

In your particular situation, there is probably no need to switch from ECB to CBC mode. This is very specific to a set of assumptions, so make sure you document the reason why ECB is OK and all the assumptions you are making, if you decide to use it. (I am assuming you will never store the same key more than once. If you do, ECB will reveal which two ciphertexts correspond to the same key.)

A separate issue in your scheme is that you are missing a message authentication code. Generally speaking, you should use message authentication in every context where encryption is applied.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
0

ECB works good in your situation (encrypting 16 bytes of random data with AES-128 in ECB mode).

However, in my understanding, problems might occur if you ever decide to encrypt longer keys.

timoh
  • 499
  • 2
  • 9