The exploit is very efficient and fits in a tweet:
1. Take C = E(K, IV) \xor P from GCM encryption
2. Make a guess of P, send (IV \ xor PADDING) || (C \xor P_guess) to the CBC oracle where PADDING is a fixed constant. If the oracle returns that the padding is correct, P_guess is correct. Otherwise make another guess.
The root cause of the issue runs pretty deep. It's a class of crypto vulnerabilities we called "in-band protocol negotiation". That is, the ciphertext contains protocol-related parameters that determine how it should be decrypted. The JWT standard has this issue, which has led to countless "alg": "none" vulnerabilities. JWT is not alone, this mistake is presented in many other libraries or standards.
I wrote about how we avoid this issue in Tink [2] [3]:
>2/ A key in Tink contains not only the raw key material, but also all necessary parameters. It is equivalent to the result of a handshake. Before any data encryption can take place, both sides have to reach an agreement not only on a raw key, but also how to use that key to encrypt data. Since a key in Tink contains all parameters, Tink does not require in-band ciphersuite negotiation. That is no ciphertext in Tink contains any other metadata aside from a key ID.
>This design sounds so simple but I've seen people get this wrong all the time. For example, the root cause of many embarrassing vulnerabilities in JWT [1] is in-band ciphersuite negotiation. That is, a JWT contains an alg field that dictates how the receiver should process it. This alg field should rather be included as part of the key.
>JWT is not the only standard making this mistake. Many crypto libraries only ask users for the raw key material. This means the parameters are either implicitly assumed or under specified. Aside from the aforementioned vulnerabilities, this can also lead to key confusion, cross-protocol key reuse and make it hard to rotate keys or change algorithms.
>To the best of my knowledge, Tink is the only high-level library that gets this right.
[1] https://github.com/google/security-research/security/advisor...
