4
$\begingroup$

What are the pros/cons of using AES ECB mode to encrypt encryption keys (data encryption keys or DEKs)? Aware of the significant weaknesses when it come to encrypting low-entropy data that's greater than a block size and also aware of AES Key wrapping functions (nice post). The low efficiency of AES KW in high throughput cases is an issue in our case (thousands/millions of fields flowing, each encrypted with own DEK).

In our case, the data encryption keys

  1. are high entropy (hardware RNG + 4 PRNG sources + crypto-hash expansion) and
  2. will be 128/256 bits long (concerns on even longer keys?)

We're avoiding AES-GCM etc to skip the IV to reduce the size since every byte is precious (big data/high volume)

Update:

  1. Integrity of the DEK isn't a concern in the threat model. DEK tampering will trigger decryption failure affecting Availability. Availability is a concern at a higher system level. (Also, if an attacker can modify the DEK bits, they can simply delete the entire field/data payload just after the encrypted DEK)
  2. The main concerns are Confidentiality and Integrity of the data itself.
Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ Note that if you want to save bytes then you should make sure that you either use ECB without padding. You could use PKCS#7 padding for 192 bit keys, but those seem to be excluded (good call to exclude those buggers). And yes, this comment is more for future readers than the author of the question, I presume you are aware of this. $\endgroup$
    – Maarten Bodewes ♦
    Sep 4, 2016 at 11:15
  • 1
    $\begingroup$ Some observations: millions of flowing fields is an odd phrase for record transfer, untrustworthy TRNG (buy a better one), can't spare a few bytes on a TB+ sized DB (shove more discs in the SAN), and key wrapping inside a server? You could just use a courier or a fill device (military). It's a very odd project... $\endgroup$
    – Paul Uszak
    Jul 1, 2017 at 12:43

2 Answers 2

Reset to default
5
$\begingroup$

If you are encrypting a 128-bit key, then it's "OK" since the key size is the same as the block size. However, if you encrypt a 256-bit key, then it's possible to tamper with the result. For example, you can drop one of the blocks and it "looks like" a 128-bit key, or you can make a 256-bit key be the same block twice (so it's of the form $k\|k$ where each $k$ is 128 bits, and so on.

Having said the above, even in the case of 128-bit key, you have the problem that an attacker can tamper with the ciphertext and you won't be able to detect it. It is true that the result will be random garbage, but in most cases, we like to be able to detect the tampering.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Good point about the stripping of key data to create a 128 bit key; many systems would happily accept such a trick (not that you can then proceed to crack it without QC, but still). Obviously those kind of attacks can be avoided within the protocol rather than the mode of operation. $\endgroup$
    – Maarten Bodewes ♦
    Sep 4, 2016 at 8:19
  • $\begingroup$ Thanks. Fortunately integrity of the DEK itself isn't a concern for us. Updated question. $\endgroup$
    – DeepSpace101
    Sep 4, 2016 at 14:08
0
$\begingroup$

Use ECB mode in CTR mode :)

AES_Encrypt(counter#1) XOR (1st_DEK_block) || AES_Encrypt(counter#2) XOR (2nd_DEK_block)

If your XOR is fast enough, the performance will be adequate and you'll avoid "k||k" concerns.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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