# Encrypting 256 bit AES keys with AES ECB?

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.
• 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. – Maarten Bodewes Sep 4 '16 at 11:15
• 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... – Paul Uszak Jul 1 '17 at 12:43

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