Security of AES ECB for 128 bit random data

Question

I am using AES ECB mode to encrypt and decrypt 128 random data. I have read on drawbacks on using ECB but it seems that it is feasible to use it for random data. However my concern is that my implementation provides an oracle. What i am concerned is key extraction. Would it be possible in reasonable time or possible at all? Again the data is random, basically server generates 128 random bits and sends it to client, the clien then encrypts it and sends it back to server. However client and server communicate via a third party (tethered way) so third party can see both plaintext and ciphertext.

My two questions are: is it safe to use AES ECB when both plaintext and ciphertext are visible to a third party? (random data, replay is not a concern)

Also there is a case where it becomes an oracle (if i am using it correctly) anyone can send 128 bits data and get cipher of it back.. (possible but not that practical, though i am wondering of its implications)?

Answer 1

On the first part of your question

ECB used to encrypt 128 bit blocks is the same as directly using the block cipher. AES can be used in many ways, it depends on what it is used for to see if it is secure. Using AES in ECB mode to encrypt random data (such as symmetric key material) to keep it confidential can be secure. Using AES ECB on many blocks representing a counter is a secure way of generating a key stream; it basically implements the key stream generated by AES-CTR.

On the second part of your question

Any block cipher that is secure protects the secret key. Whatever the adversary does, the key should not become available to the adversary. In other words, it should be computationally impossible for any secure block cipher to retrieve the key (if the key is large and random enough), even given all possible plaintext / ciphertext blocks. So yes, it is "safe to use AES ECB when both plaintext and ciphertext are visible to a third party" when it comes to securing the key.

On the third part of your question

If such an Oracle is a problem depends. Your goal isn't confidentiality of the random data. If it was you would not have sent it in plain to the party that performs the encryption. If your main goal is authentication then yes, there is an issue. If you send a random to client B, then client B can simply send it to client A to have it encrypted and then client B can send it back to the server. If this is some kind of authentication protocol then it is severely broken, at least when used by itself.

---

Remember: if something is broken doesn't depend on the mode of operation alone. If there is a protocol then there is a threat model - even if you're unaware of it. If the mode of operation such as ECB is secure depends on how it is used within the protocol. If it fails to meet the requirements to thwart all attacks on the protocol then the mode of operation is not the right one.

Because ECB mode performs deterministic encryption it is usually not the right mode, especially when it comes to providing confidentiality of messages. If it is secure in your "protocol" depends on the protocol and what it tries to protect.

Answer 2

AES is designed so that it is infeasible to derive the key with only the plaintext and ciphertext. It's part of the definition of a strong cipher.

At the risk of sounding like a broken record, the real problem with ECB is that the same input blocks produce the same output blocks. This is devastating if your data is more than 128 bits. Other modes prevent this by adding in some randomness as well as having previous blocks affecting future blocks.

Another security feature added by some modes is authentication. They provide a way to prove your data came from the place you expect it did, and to prove it wasn't tampered with. Without authentication, attackers could corrupt a single block of your data without you being able to directly tell (barring non cryptographic methods, such as checking if the decrypted data makes sense, but thats a lot less strong).

If all you need is secrecy, and integrity and authentication is of absolutely no concern to your threat model, and you guarantee the same block isn't ever encrypted twice, then encrypting 16 bytes (128 bits) of random data with AES ECB is okay.