36 ms·

>As far as I am aware CBC has been discouraged for a long time precisely because of the padding oracle attacks My understanding of these padding oracle attacks

by lol768 8y ago

>As far as I am aware CBC has been discouraged for a long time precisely because of the padding oracle attacks My understanding of these padding oracle attacks was that they were the result of an implementation vulnerability that leaked information through error messages about the padding being the cause. Not that the problem was an inherent flaw in CBC itself. If the server simply used generic error messages when the padding was invalid, there would be no 'oracle' AIUI. Edit: https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

bcaa7f3a8bbc 8y ago
> Not that there was an inherent flaw in CBC itself. But if history shows it's difficult to implement something without creating vulnerabilities, and there are alternatives which are less prone to mistakes, it should be retired and discouraged to be implemented. Also, CBC itself is not an actual problem, but CBC in TLS is authenticate-then-encrypt, which is how the vast majority of problems are created.
- lol768 8y ago
  >But if history shows it's difficult to implement something without creating vulnerabilities, and there are alternatives which are less prone to mistakes, it should be retired and discouraged to be implemented. >Also, CBC itself is not an actual problem, but CBC in TLS is authenticate-then-encrypt, which is how the vast majority of problems are created. Oh definitely, GCM (or another AEAD cipher) is a much better choice - I wouldn't argue in favour of CBC in production TLS cipher suites. I just wanted to comment on the technical details of where padding oracle vulnerabilities actually arise.
  - blattimwind 8y ago
    > Oh definitely, GCM (or another AEAD cipher) is a much better choice GCM is only a better choice if you have hardware support for it. I'd recommend Chacha20-Poly1305 for anything that might have to cope without hardware support.
- olliej 8y ago
  CBC has a fundamental weakness in that you can toggle one bit at a time and get a predictable change. Encrypt-then-authenticate would obviously resolve that, but that's trivially broken by breaking SHA1/2 ;) Of course a problem with encrypt then authenticate is that you can verify the identity of the sender without decrypting the content, which is of course why A then E happened in the first place - the threat model turned out to be incorrect. For messaging platforms I would still lean towards authenticate then encrypt as I think the attack model is different.
  - tptacek 8y ago
    No, this isn't a fundamental weakness of CBC. In fact, CTR is even more susceptible to this problem (a CBC bitflip totally corrupts the block to which it's applied, and creates a predictable change in the subsequent block; a CTR bitflip simply flips the matching decrypted plaintext bit; in that sense CTR is totally and perfectly malleable). Also: nobody uses SHA1 anymore, SHA1 and SHA2 aren't MACs (you're thinking of HMAC), and even MD5 is still unbroken in HMAC.
olliej 8y ago
One issue (the openssl one I think) wasn't a different error message, but rather the different delay in time to closing the connection. The end result is obviously the same, but it's important to remember that it's not just a matter of returning the same error code, but rather having identical termination characteristics.

by lol768 8y ago

bcaa7f3a8bbc 8y ago

> Not that there was an inherent flaw in CBC itself. But if history shows it's difficult to implement something without creating vulnerabilities, and there are alternatives which are less prone to mistakes, it should be retired and discouraged to be implemented. Also, CBC itself is not an actual problem, but CBC in TLS is authenticate-then-encrypt, which is how the vast majority of problems are created.

lol768 8y ago
>But if history shows it's difficult to implement something without creating vulnerabilities, and there are alternatives which are less prone to mistakes, it should be retired and discouraged to be implemented. >Also, CBC itself is not an actual problem, but CBC in TLS is authenticate-then-encrypt, which is how the vast majority of problems are created. Oh definitely, GCM (or another AEAD cipher) is a much better choice - I wouldn't argue in favour of CBC in production TLS cipher suites. I just wanted to comment on the technical details of where padding oracle vulnerabilities actually arise.
- blattimwind 8y ago
  > Oh definitely, GCM (or another AEAD cipher) is a much better choice GCM is only a better choice if you have hardware support for it. I'd recommend Chacha20-Poly1305 for anything that might have to cope without hardware support.
olliej 8y ago
CBC has a fundamental weakness in that you can toggle one bit at a time and get a predictable change. Encrypt-then-authenticate would obviously resolve that, but that's trivially broken by breaking SHA1/2 ;) Of course a problem with encrypt then authenticate is that you can verify the identity of the sender without decrypting the content, which is of course why A then E happened in the first place - the threat model turned out to be incorrect. For messaging platforms I would still lean towards authenticate then encrypt as I think the attack model is different.
- tptacek 8y ago
  No, this isn't a fundamental weakness of CBC. In fact, CTR is even more susceptible to this problem (a CBC bitflip totally corrupts the block to which it's applied, and creates a predictable change in the subsequent block; a CTR bitflip simply flips the matching decrypted plaintext bit; in that sense CTR is totally and perfectly malleable). Also: nobody uses SHA1 anymore, SHA1 and SHA2 aren't MACs (you're thinking of HMAC), and even MD5 is still unbroken in HMAC.

olliej 8y ago

One issue (the openssl one I think) wasn't a different error message, but rather the different delay in time to closing the connection. The end result is obviously the same, but it's important to remember that it's not just a matter of returning the same error code, but rather having identical termination characteristics.