A service or library provides a function decrypt( user_id, cypher_text) and gives back plain text. Internally to the function it loads an AES key from a secure vault, decrypts the cypher_text, and returns the plain text. If an attacker gets access to this function alone, but doesn’t know any valid cyphertext, can they perform an attack to recover the AES key for a particular user_id?

To be clear when I say “the attacker doesn’t know any valid cyphertext” I mean it not only doesn’t have access to a matching encryption function but also that the attacker doesn’t have access to any cypher text that has been encrypted with the key. So the attacker can only feed in some specially crafted series of attacking cyphertext and inspect the decryption results to try to deduce the key.

I have looked for the name of such an attack and haven’t been able to find it. In this case the attacker cannot use a “known plaintext” attack as they don’t have access to a function that encrypts with the AES key. I would describe the scenario above as a “crafted cyphertext attack on a decrypt function”. So my question is whether AES is secure against anything but a brute force attack in such a scenario.

Note: As per the accepted answer this is a Chosen Ciphertext Attack (CCA) and certain versions of AES are okay and others are not. “Table 1: Algorithm Summary Table” at Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API describes in the right column which are “ not CCA secure”.

  • If the attacker has no access to any ciphertext actually encrypted with the key, and the key in question is used only within this system, then recovering the key provides no benefit for the attacker, nor cost to the user_id. I can't see that this is a question about security; perhaps it's of academic interest to the crypto community. – mlp May 8 '20 at 13:50
  • its a distributed system with backups and multiple users. so the concern we have is that (a) someone who cannot legitimately query the encrypted cyphertext can actually access the function in question to learn about the key, then (b) they can get access to the data via backups and not going via the main api. we have multiple defences that would have to fail but thats how breaches often happen. usually, it is academics, not practitioners, who make the mistake of saying ”a model says that can’t happen”. when I ask questions on the cryptography forums I often see such answers. – simbo1905 May 8 '20 at 15:13

This sounds to me like a chosen ciphertext attack. The raw AES block cipher itself is secure against it. Any cipher you would see used in a modern setting is secure against it.

Some AES implementations you would actually see in the wild are not secure against sidechannel attacks, meaning information about the computation which is not part of the function signature (not the cleartext of a submitted ciphertext). The length of time it took to compute is the most famous, and might be available to a remote network attacker. Contention over caches and execution ports is visible to code running on the same hardware but in another process or VM, and is an attack on shared hardware, possibly in a cloud environment. Measuring accustic noise from electric components might be an attack on hardware in the same room. Actually measuring electromagnetic emanations from the hardware is an attack on smart cards and the like.

The problem is that you never just use the raw AES block cipher. You need to encrypt messages longer than a single block, and you need to protect against malleability. MAC-then-Encrypt AES-CBC turned out to be so hard to implement correctly that fixing all TLS implementations deployed in the wild is now considered impossible, TLS 1.3 dropped those cipher suites and the plan for TLS use in the wild is to just age out all those bad implementations. Anybody not using AEAD in any modern design is rightfully ridiculed.

So, for example, unauthenticated AES-CBC with a padding oracle is trivially breakable, it's an exercise given to non-cryptography people to teach them that cryptography is subtle.

More in-depth information about block cipher security is on cryptography.SE. On security.SE, we'll just tell you how to avoid problems without becoming a cryptographer.

Use a modern AEAD like EAX or GCM, or at least use HMAC with Encrypt-then-MAC and corresponding MAC-then-Decrypt (and make sure the MAC covers the IV if you use CBC, though you should use CTR because it's faster). This way, you never expose crafted ciphertext to an AES circuit that has your key, and don't need to worry about it. Or use ChaCha20Poly1305, and then you don't need to worry about an insecure AES implementation (only hardware AES and bitslicing are secure, all table driven AES implementations are not secure. bitslicing is slow, so almost all AES on hardware that does not contain dedicated AES circuits is insecure. That's why ChaCha was invented).

The really correct thing to do is to not roll your own crypto and use a high level library that has a misuse resistant API like Google Tink or libsodium, etc.

  • thanks. we are using the JVMs built-in crypto libraries and picked the actual AES scheme after carefully reading the latest advice. the concern in this question is based on careful review of some code where if we had multiple future misconfigurations the scenario in the question could arise. on balance I consider that we will be okay. – simbo1905 May 8 '20 at 15:39
  • AES is primitive and AES itself is believed to be a pseudo-random permutation. One can achieve CCA security with AEAD like AES-GCM, AES-GCM-SIV, but not with CBC or CTR. they are only CPA secure. Table implementations can be made secure against the cache attacks that requires reading the all cache lines. – kelalaka May 10 '20 at 1:16

Your Answer

