Default AES-256-CBC mode vulnerabilities
good-lly opened this issue · comments
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???
@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.
-
The malleability attack described on your link can happen because CBC mode provides good data confidentiality, but not data integrity by itself. This allows an attacker to modify the content of the message in possibly harmful ways.
=> in the context of StatiCrypt, the ciphertext and unencrypted decryption logic are stored in the same place. If an attacker can modify the ciphertext they can also modify the decryption logic which gives them full control of the whole process - so I'd say that this CBC attack doesn't really open a new attack surface?
-
CBC mode is vulnerable to Oracle Padding attacks (here's a description of the implementation of the attack). I understand this attack to be: the attacker sends a ciphertext with IV to someplace that attempts to decrypt it and that place returns whether the result of decryption has correct padding or not. By sending many slightly altered ciphertext + iv, the plaintext cna be recovered.
=> in the context of StatiCrypt, there is no automated decryption by the server that the attacker can exploit by sending an arbitrary high number of modified ciphertexts. The Remember-Me feature of someone logged in will attempt to auto-decrypt their page, but if an attacker can somehow make changes to the ciphertext the legitimate browser tries to decrypt they might as well change the decryption logic and just grab the password / decrypted content.
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