Encrypting Confidential Data at Rest task implies recommendation against AES CBC is due to padding oracle risk

[pwolanin]

Maybe I'm missing something, but the comment that "CBC's vulnerability to padding oracle attacks. " is why aescbc is not recommended seems to be misguided or wrong.

Padding oracle attacks can only occur if the attacker can send many different versions of the encrypted data and have the server respond in a way that the attacker can determine that there was an invalid padding. e.g. see https://blog.cloudflare.com/padding-oracles-and-the-decline-of-cbc-mode-ciphersuites/

That article notes that AES-CBC is secure for encrypting static content. I think that matches how it's used for the secrets API I'd also hope that kubernetes stores the encrypted secrets using a MAC after encryption, which removes the padding oracle attack vector.

How does a padding oracle attack become relevant in this context?

re: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

[utkarsh-singh1]

/language en

[sftim]

/kind support

This does feel mostly like a support query. These docs were reviewed for technical accuracy; if they are wrong, we'd like evidence, rather than a question.

If you want to use the AES CBC mode, despite the project's recommendations, you can.

[pwolanin]

It is not a support query. I think this is a technical inaccuracy in the docs - I do not think there is any padding oracle that exists in kubernetes. Indicating that aescbc is weak for that reason is inaccurate.

Obviously I can still use it, and we do use AES-CBC for similar purposes in code internal to our projects where we want to encrypt multiple secrets at rest using the same encryption key.

[sftim]

/remove-kind support
/priority awaiting-more-evidence
/sig security auth

[sftim]

/retitle Encrypting Confidential Data at Rest task implies recommendation against AES CBC is due to padding oracle risk