3 ms·

is AES256-CBC insecure? unfortunately i encrypt backups with it.

ZeroCool2u 5y ago
I've been out of the security game for a while, but a couple years ago the rule of thumb was to avoid CBC and use GCM. Edit: There's a good explanation here https://crypto.stackexchange.com/questions/2310/what-is-the-difference-between-cbc-and-gcm-mode https://crypto.stackexchange.com/questions/2310/what-is-the-...
tomudding 5y ago
While theoretically secure, CBC ciphers are considered weak because of their implementation. They are more often than not vulnerable to padding oracle attacks. These issues have been around for more than a decade, but they keep popping up. The last 3-ish years a larger push has been made to disable CBC ciphers (in SSL/TLS, SSH, etc.). See [0, 1, 2, 3, and 4] for more information. GCM/CTR is considered to be a more secure alternative. [0]: https://en.wikipedia.org/wiki/Padding_oracle_attack#Padding_oracle_attack_on_CBC_encryption https://en.wikipedia.org/wiki/Padding_oracle_attack#Padding_... [1]: https://www.openssh.com/txt/cbc.adv https://www.openssh.com/txt/cbc.adv [2]: https://ieeexplore.ieee.org/document/5207634 https://ieeexplore.ieee.org/document/5207634 (is CPNI-957037) [3]: https://alicegg.tech/2019/06/23/aes-cbc.html https://alicegg.tech/2019/06/23/aes-cbc.html [4]: https://docs.microsoft.com/en-us/dotnet/standard/security/vulnerabilities-cbc-mode https://docs.microsoft.com/en-us/dotnet/standard/security/vu... [n]: You can find more information with a quick search, this also includes security advisories from HPE, RedHat, IBM, and F5.
- bawolff 5y ago
  That said, i don't think padding oracles are usually available in the context of an encrypted backup, so that particular concern is probably not a big concern in OP's usecase.
hannob 5y ago
"It's complicated". CBC does not provide authentication, thus it does not protect your encrypted content from manipulation (which can enable all kinds of followup attacks). Generally you should avoid using unauthenticated ciphers almost always and use an AEAD. SSH uses CBC in combination with a MAC, so it has authentication, but it combines them in an insecure way. It turns out it's practically impossible to avoid these attacks (there had been countermeasures, but it's been shown that they can be circumvented). The attacks only let an attacker decrypt a single byte in certain situations, so the practical impact is limited. Here's the original attack: https://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf https://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf Here's an updated paper that shows that the countermeasures against the original attack don't work. https://www.isg.rhul.ac.uk/~kp/surfeit.pdf https://www.isg.rhul.ac.uk/~kp/surfeit.pdf

I've been out of the security game for a while, but a couple years ago the rule of thumb was to avoid CBC and use GCM. Edit: There's a good explanation here https://crypto.stackexchange.com/questions/2310/what-is-the-difference-between-cbc-and-gcm-mode https://crypto.stackexchange.com/questions/2310/what-is-the-...

tomudding 5y ago

While theoretically secure, CBC ciphers are considered weak because of their implementation. They are more often than not vulnerable to padding oracle attacks. These issues have been around for more than a decade, but they keep popping up. The last 3-ish years a larger push has been made to disable CBC ciphers (in SSL/TLS, SSH, etc.). See [0, 1, 2, 3, and 4] for more information. GCM/CTR is considered to be a more secure alternative. [0]: https://en.wikipedia.org/wiki/Padding_oracle_attack#Padding_oracle_attack_on_CBC_encryption https://en.wikipedia.org/wiki/Padding_oracle_attack#Padding_... [1]: https://www.openssh.com/txt/cbc.adv https://www.openssh.com/txt/cbc.adv [2]: https://ieeexplore.ieee.org/document/5207634 https://ieeexplore.ieee.org/document/5207634 (is CPNI-957037) [3]: https://alicegg.tech/2019/06/23/aes-cbc.html https://alicegg.tech/2019/06/23/aes-cbc.html [4]: https://docs.microsoft.com/en-us/dotnet/standard/security/vulnerabilities-cbc-mode https://docs.microsoft.com/en-us/dotnet/standard/security/vu... [n]: You can find more information with a quick search, this also includes security advisories from HPE, RedHat, IBM, and F5.

bawolff 5y ago
That said, i don't think padding oracles are usually available in the context of an encrypted backup, so that particular concern is probably not a big concern in OP's usecase.

hannob 5y ago

"It's complicated". CBC does not provide authentication, thus it does not protect your encrypted content from manipulation (which can enable all kinds of followup attacks). Generally you should avoid using unauthenticated ciphers almost always and use an AEAD. SSH uses CBC in combination with a MAC, so it has authentication, but it combines them in an insecure way. It turns out it's practically impossible to avoid these attacks (there had been countermeasures, but it's been shown that they can be circumvented). The attacks only let an attacker decrypt a single byte in certain situations, so the practical impact is limited. Here's the original attack: https://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf https://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf Here's an updated paper that shows that the countermeasures against the original attack don't work. https://www.isg.rhul.ac.uk/~kp/surfeit.pdf https://www.isg.rhul.ac.uk/~kp/surfeit.pdf