-
-
Notifications
You must be signed in to change notification settings - Fork 429
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
Default AES-256-CBC mode vulnerabilities #19
Comments
@austin-rausch Do you want to explain why you put a thumbs-down ? Any expetise on the subject that you could share to help people understand the subject ? |
Thank you for opening the issue - and sorry for taking so so long to write back. CBC being the default on a popular crypto library it felt safe enough to wait for a good time for me to dive deeper into it but yeah, 5 years is a while... This is my current understanding of the CBC mode and its possible vulnerabilities related to StatiCrypt - please feel free to correct or add to it.
So it seems to me that CBC doesn't really open new vulnerabilities in the context of StatiCrypt. All the scenarios I can imagine where that is a concern are really contrived ("an attacker wants to leave the html part of the decryption page untouched so it looks the same to someone checking for malware but is ok modifying the jumbled encrypted string which is harder to check"). I'd be really happy to hear any other thoughts on the topic though - anyone, please feel free to chime in. Context: cryptoJS doesn't support GCM, its default is CBC. StatiCrypt v3 will use WebCrypto as a crypto engine by default, which does support GCM, and v3 will probably also offer cryptoJS as a fallback for non https contexts. I want to understand if 1) the current implementation of staticrypt is vulnerable to certain attacks, 2) can WebCrypto in v3 safely use CBC mode as well or do we want to support both GCM from webcrypto + CBC from cryptoJS, which might lead to interoperability complexity. |
Added thoughts on the malleability attack: we do sign the ciphertext with an HMAC, so this should guarantee data integrity. An attacker could remove that check happening client side but then again, if they can change the decryption logic they can do whatever they want. |
fair points |
If I am right, you are not setting any specific encryption mode thanks to that is used default CBC mode which can escalate into output vulnerabilities and certain attacks ... did you consider to use some more proper modes? For example Galois-Counter Mode???
The text was updated successfully, but these errors were encountered: