-
Notifications
You must be signed in to change notification settings - Fork 14.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Encrypting Confidential Data at Rest task implies recommendation against AES CBC is due to padding oracle risk #44169
Comments
/language en |
/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. |
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. |
/remove-kind support |
/retitle Encrypting Confidential Data at Rest task implies recommendation against AES CBC is due to padding oracle risk |
Relevant but different to this issue's focus: we should add more of a concept guide to API encryption at rest. Then, the task page can focus on the “how”, with hyperlinks into the concept page for the “why” aspects. |
I have some PRs including #43176 that aim to help around the topic of API encryption at rest, but either:
Help is welcome |
What we actually recommend is KMS with a v2 plugin and a KEK that's never revealed to the Kubernetes API server. This is a security model I personally like, too. |
Yes, clearly not having the KEK in kubernetes is better, but I don't think
the doc is accurate as is
…On Fri, Dec 1, 2023, 08:58 Tim Bannister ***@***.***> wrote:
What we *actually* recommend is KMS with a v2 plugin and a KEK that's
never revealed to the Kubernetes API server. This is a security model I
personally like, too.
—
Reply to this email directly, view it on GitHub
<#44169 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA2JKYHH425GQVBU4PMF6DYHHPBVAVCNFSM6AAAAABACEXQ62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZWGE3DGNRXGA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I'm inferring that in the absence of a formal proof around the lack of a padding oracle, precaution is good. The docs don't state this. |
In order for a padding Oracle to exist the attacker must be able to submit
multiple versions of the cipher text for attempted decryption and also the
stored value must have been done as MAC before encrypt.
I am pretty sure those conditions don't exist. What kind of proof is needed?
…On Fri, Dec 1, 2023, 09:50 Tim Bannister ***@***.***> wrote:
I'm inferring that in the absence of a formal proof around the lack of a
padding oracle, precaution is good. The docs don't state this.
—
Reply to this email directly, view it on GitHub
<#44169 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA2JK52PQ22AY4S56AACW3YHHVD3AVCNFSM6AAAAABACEXQ62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZWGI2DINBSHE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
/triage accepted |
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/
The text was updated successfully, but these errors were encountered: