4 ms·

Deep breath. I know that I'm going to be thought a heretical fool for saying this, but overall I would consider CBC mode "more secure" than GCM. Of course encr

Deep breath. I know that I'm going to be thought a heretical fool for saying this, but overall I would consider CBC mode "more secure" than GCM. Of course encrypt-then-MAC would be preferable (which TLS now supports, though implementations are scarce) ... but even with the broken Mac-Then-Encrypt variant that we have today ... still more secure. It's a case of choose your poison. With the Mte CBC vulns, we've seen some pretty hard to implement padding oracles; I don't think that these attacks are in general practical or a big risk for real-world users and workloads. It's awful, ugly, stuff, but it's also something that the internet has been able to stay on top of with patching. On the other hand the mass-deployment of AES-GCM, we've deployed a length preserving cipher as the world's default for network traffic. An exact length-preserving mode makes realistic mass content fingerprinting attacks far cheaper and more feasible. These are very practical passive attacks that happen mostly out of band ... so I think it's a mistake to make these easier. In real terms, AES-GCM reduces by a exponential factor the amount of state that a FVEY-style attacker must maintain to mostly-successfully identify what webpages you are browsing. It's so much more feasible, in the realm of an undergrad term project, that I would be surprised if it is not occurring. Even a modestly resourced security agency with relatively sophomoric skills can do it. To my mind, making a practical passive attack much cheaper, to the point that it may be occurring (though that's a guess, I have no information) to be able to turn our nose at a cryptographic construct that offends us, but is less practical to attack ... seems to me like the wrong trade-off. At least with TLS1.3 and QUIC we can pad encrypted data and get a measure of length-hiding back; enough to at least raise costs for passive fingerprinting attacks (and raise those costs more than CBC ever could on its own).

tptacek 8y ago
Couldn't length-hiding be done more effectively (than CBC) at the HTTP layer by injecting random headers?
- colmmacc 8y ago
  Yes! I've experimented with server-side changes, but unfortunately the request length leaks information too, so the client needs to do something similar. In real terms, I think the consequence of the rapid mass-migration away from CBC made the passive attacks far easier; instead of building graphs and de-fuzzers, analysts can identify content using combined request and response length signatures. All of that happened purely at the cryptographic layer, and it's unfortunate. In general, it's hard to ask HTTP servers and applications higher up the stack to take it on; the folks writing those ton'd tend to be cryptography or SIGINT experts. It's still easy enough to find subtle CRIME-like compression attacks against servers and applications that mix compression and untrusted input, which is some sign of how effective we all are at chasing down similar kinds of issues at those layers.
  - tptacek 8y ago
    Certainly this logic doesn't suggest using CBC instead of an AEAD for a new, non-TLS system, where, if traffic analytic attacks were a concern, you'd just bake that into the protocol itself while still claiming the benefits of modern authenticated encryption.
    - colmmacc 8y ago
      That's a tough call. We've thoroughly learned that not only should developers not build their own cryptographic primitives, but that they shouldn't even trivially combine them on their own. "Use AEAD" (or better yet: use noise) is good advice for application and protocol designers who on their own probably wouldn't even think about the problems ... but it's not sufficient. We haven't seemed to learn that length hiding, traffic analysis, and shared compression dictionaries are all so firmly in the realm of what encryption is supposed to do ... make content secret ... that developers also can't be trusted to get these right on their own. So if you're in the position to telling someone to use AEAD instead of CBC, I'd make sure to also tell them that they should think hard about length hiding, message timing, and shared compression dictionaries, and whether those are important concerns in that environment. Oh and they still have to watch out for IV problems with plenty of the AEAD implementations. Personally I long for some better crypto boxes than "AEAD" and I should really get off my butt and define one; at the level of total hand-waving, I trust cryptographers more to review this stuff much better than protocol designers. Like here I am claiming that TLS, the most pervasive network encryption protocol, has actually gotten measurably less secure at encryption, by at least one important measure, in the last 5 years.
      - tptacek 8y ago
        Whatever it is this take is, it's not boring. :)
      - tedunangst 8y ago
        Measurably? I think you have a point about length hiding, although many models seem to just dismiss it, but I'm not sure the accidental padding you get from CBC is measurably better. Scenario 1: https, downloading a file. Plus or minus a few bytes is still accurate enough for identification, no? Scenario 2: ssh, where one keystroke equals one packet, regardless of length. I can still hear your password. Did you have a scenario in mind where CBC padding provides a meaningful degree of length obfuscation?
- wahern 8y ago
  Maybe? I believe with enough traffic you can determine the actual content size by calculating the average apparent padding length. (Compare JavaScript timing side channel attacks that can remove random clock jitter, or Onion Routing traffic analysis.) What you really want is padding to a fixed-length block. That requires restricting the maximum allowed length of confidential fields. (Could vary per field.) Yet such "arbitrary" limits have been frowned upon for ages as poor design. That said, there's usually nothing stopping people from imposing their own limits and padding accordingly, server- and client-side. But without enforcement across the entire software stack it's difficult to maintain the invariant.
dorkusmcgavin 8y ago
AES is a block cipher that operates on 128-bit blocks exclusively. If you look at the implementation of AES-GCM, it also operates on 128-bit blocks. AES-GCM is basically just counter mode with built in correct MAC handling. Your claim that AES-GCM is length preserving is completely false, other than the obvious multiples of the block size which is the same as CBC mode or any other mode. Your statement isn't heretical, it's just based on a false statement. If the premise of your statement were true, your extra analysis would be correct. I would read up on the details of the mode itself, this graph is a good place to start then move on to the mathematical section which talks about the 128-bit blocks: https://en.wikipedia.org/wiki/Galois/Counter_Mode https://en.wikipedia.org/wiki/Galois/Counter_Mode
- tptacek 8y ago
  First, you might want to look closer at who you're talking to. Second, you might want to read a little more about how counter mode works. Or, why not just try it yourself? "pip install cryptography", pop open a Python shell, and encrypt some stuff. There's only so much you can get from Wikipedia. Because: counter mode doesn't create ciphertexts that are multiples of the block size; not doing that is the point of counter mode. >>> from cryptography.hazmat.primitives.ciphers.aead import AESGCM >>> gcm = AESGCM("\x00" * 16) >>> len(gcm.encrypt("\x00" * 12, "YELLOW SUBMARINE", "")) 32 >>> len(gcm.encrypt("\x00" * 12, "YELLOW SUBMARINES", "")) 33
  - dorkusmcgavin 8y ago
    I opened up my book of cryptography from Jonathan Katz, and found this in regards to CTR mode: > As with OFB mode, another "stream-cipher" mode, the generated stream can be truncated to exactly the plaintext length This is contrary to what Jonathan Katz told a class taught from the University of Maryland which I took, which is odd. I've used CTR mode before and exploited CBC padding oracles, I don't recall being able to use CTR mode this way but I rarely used it since we focused on CBC exploitation and a bit too much on CPA/CCA proofs. After looking at the diagrams shown, it's clear that since the message is XOR'd on the output of the generative random of the encryption function, CTR mode can indeed be truncated since the remaining generative output can be ignored. So I had a misunderstanding in my head on CTR mode. Now on to GCM. Unfortunately my edition of Katz' book doesn't include GCM so I have to default to Wikipedia. The last XOR is more than likely where a truncation can occur, so I was wrong about GCM mode as well. As for Python tests (package already installed, no need to use PIP when it's in the various Linux repos): from cryptography.hazmat.primitives.ciphers.aead import AESGCM import os key = AESGCM.generate_key(256) gcmtest = AESGCM(key) nonce = os.urandom(16) len(gcmtest.encrypt(nonce, b"testbytes1", b"ASD")) len(gcmtest.encrypt(nonce, b"testbytes12", b"ASD")) len(gcmtest.encrypt(nonce, b"testbytes13", b"ASD")) This outputs 26, 27, 28 respectively. While this proves your point, I want to make clear that ignoring the reason and just trusting the output of an implementation isn't really a good way of learning things (although complimentary). I was using the Wikipedia and text references so I could understand why it allowed variable length, and at my first look the construction didn't appear like you could truncate. Despite all of this, the CTR-mode section of the book includes a CPA-security proof and the CBC section says it is vulnerable to CPA. I'm going to try to dig through that to see why. If they are cognizant of the fact that same length attacks are something that makes you vulnerable, there must be a reason why they believe CTR/GCM are not.
tialaramex 8y ago
> At least with TLS1.3 and QUIC we can pad encrypted data and get a measure of length-hiding back; enough to at least raise costs for passive fingerprinting attacks (and raise those costs more than CBC ever could on its own). I have to say this feels like both the more actionable and more insightful output of your... heresy. We are not going back to CBC. You say that some CBC attacks don't seem practical. The trouble with the Web is it's like some lunatic deliberately designed a system to be attacked. Oh you have a chosen plaintext attack that needs 1 million repetitions? Impractical. Wait, Javascript exists. OK, but even with Javascript who'd ever have a system that terminates HTTPS for completely unrelated parties on the same physical hardware - there's no way we'll get to exploit that? Oh, bulk hosting exists. OK. Still nobody would build a crypto system in which one party is just completely anonymous all the... oh wait, that's exactly how Tim's system was designed. Eric Rescorla has some great slides about this. Whereas "Hey, let's pad every message to hit the path MTU size for packets" totally feels like something vendors could do next week and make a huge impact with no real cost. A lot of network devices can't hit their target speeds for small packets anyway, so the impact may be not merely negligible but literally non-existent. I have to say though, I'm not actually clear on why we couldn't pad TLS 1.2's AEAD modes to the same effect? The TLS 1.3 padding is _clever_ but what does it do here that makes it more important for your passive fingerprinting attack than the older padding scheme (with an AEAD cipher)?

tptacek 8y ago

Couldn't length-hiding be done more effectively (than CBC) at the HTTP layer by injecting random headers?

colmmacc 8y ago
Yes! I've experimented with server-side changes, but unfortunately the request length leaks information too, so the client needs to do something similar. In real terms, I think the consequence of the rapid mass-migration away from CBC made the passive attacks far easier; instead of building graphs and de-fuzzers, analysts can identify content using combined request and response length signatures. All of that happened purely at the cryptographic layer, and it's unfortunate. In general, it's hard to ask HTTP servers and applications higher up the stack to take it on; the folks writing those ton'd tend to be cryptography or SIGINT experts. It's still easy enough to find subtle CRIME-like compression attacks against servers and applications that mix compression and untrusted input, which is some sign of how effective we all are at chasing down similar kinds of issues at those layers.
- tptacek 8y ago
  Certainly this logic doesn't suggest using CBC instead of an AEAD for a new, non-TLS system, where, if traffic analytic attacks were a concern, you'd just bake that into the protocol itself while still claiming the benefits of modern authenticated encryption.
  - colmmacc 8y ago
    That's a tough call. We've thoroughly learned that not only should developers not build their own cryptographic primitives, but that they shouldn't even trivially combine them on their own. "Use AEAD" (or better yet: use noise) is good advice for application and protocol designers who on their own probably wouldn't even think about the problems ... but it's not sufficient. We haven't seemed to learn that length hiding, traffic analysis, and shared compression dictionaries are all so firmly in the realm of what encryption is supposed to do ... make content secret ... that developers also can't be trusted to get these right on their own. So if you're in the position to telling someone to use AEAD instead of CBC, I'd make sure to also tell them that they should think hard about length hiding, message timing, and shared compression dictionaries, and whether those are important concerns in that environment. Oh and they still have to watch out for IV problems with plenty of the AEAD implementations. Personally I long for some better crypto boxes than "AEAD" and I should really get off my butt and define one; at the level of total hand-waving, I trust cryptographers more to review this stuff much better than protocol designers. Like here I am claiming that TLS, the most pervasive network encryption protocol, has actually gotten measurably less secure at encryption, by at least one important measure, in the last 5 years.
    - tptacek 8y ago
      Whatever it is this take is, it's not boring. :)
    - tedunangst 8y ago
      Measurably? I think you have a point about length hiding, although many models seem to just dismiss it, but I'm not sure the accidental padding you get from CBC is measurably better. Scenario 1: https, downloading a file. Plus or minus a few bytes is still accurate enough for identification, no? Scenario 2: ssh, where one keystroke equals one packet, regardless of length. I can still hear your password. Did you have a scenario in mind where CBC padding provides a meaningful degree of length obfuscation?
wahern 8y ago
Maybe? I believe with enough traffic you can determine the actual content size by calculating the average apparent padding length. (Compare JavaScript timing side channel attacks that can remove random clock jitter, or Onion Routing traffic analysis.) What you really want is padding to a fixed-length block. That requires restricting the maximum allowed length of confidential fields. (Could vary per field.) Yet such "arbitrary" limits have been frowned upon for ages as poor design. That said, there's usually nothing stopping people from imposing their own limits and padding accordingly, server- and client-side. But without enforcement across the entire software stack it's difficult to maintain the invariant.

dorkusmcgavin 8y ago

AES is a block cipher that operates on 128-bit blocks exclusively. If you look at the implementation of AES-GCM, it also operates on 128-bit blocks. AES-GCM is basically just counter mode with built in correct MAC handling. Your claim that AES-GCM is length preserving is completely false, other than the obvious multiples of the block size which is the same as CBC mode or any other mode. Your statement isn't heretical, it's just based on a false statement. If the premise of your statement were true, your extra analysis would be correct. I would read up on the details of the mode itself, this graph is a good place to start then move on to the mathematical section which talks about the 128-bit blocks: https://en.wikipedia.org/wiki/Galois/Counter_Mode https://en.wikipedia.org/wiki/Galois/Counter_Mode

tptacek 8y ago
First, you might want to look closer at who you're talking to. Second, you might want to read a little more about how counter mode works. Or, why not just try it yourself? "pip install cryptography", pop open a Python shell, and encrypt some stuff. There's only so much you can get from Wikipedia. Because: counter mode doesn't create ciphertexts that are multiples of the block size; not doing that is the point of counter mode. >>> from cryptography.hazmat.primitives.ciphers.aead import AESGCM >>> gcm = AESGCM("\x00" * 16) >>> len(gcm.encrypt("\x00" * 12, "YELLOW SUBMARINE", "")) 32 >>> len(gcm.encrypt("\x00" * 12, "YELLOW SUBMARINES", "")) 33
- dorkusmcgavin 8y ago
  I opened up my book of cryptography from Jonathan Katz, and found this in regards to CTR mode: > As with OFB mode, another "stream-cipher" mode, the generated stream can be truncated to exactly the plaintext length This is contrary to what Jonathan Katz told a class taught from the University of Maryland which I took, which is odd. I've used CTR mode before and exploited CBC padding oracles, I don't recall being able to use CTR mode this way but I rarely used it since we focused on CBC exploitation and a bit too much on CPA/CCA proofs. After looking at the diagrams shown, it's clear that since the message is XOR'd on the output of the generative random of the encryption function, CTR mode can indeed be truncated since the remaining generative output can be ignored. So I had a misunderstanding in my head on CTR mode. Now on to GCM. Unfortunately my edition of Katz' book doesn't include GCM so I have to default to Wikipedia. The last XOR is more than likely where a truncation can occur, so I was wrong about GCM mode as well. As for Python tests (package already installed, no need to use PIP when it's in the various Linux repos): from cryptography.hazmat.primitives.ciphers.aead import AESGCM import os key = AESGCM.generate_key(256) gcmtest = AESGCM(key) nonce = os.urandom(16) len(gcmtest.encrypt(nonce, b"testbytes1", b"ASD")) len(gcmtest.encrypt(nonce, b"testbytes12", b"ASD")) len(gcmtest.encrypt(nonce, b"testbytes13", b"ASD")) This outputs 26, 27, 28 respectively. While this proves your point, I want to make clear that ignoring the reason and just trusting the output of an implementation isn't really a good way of learning things (although complimentary). I was using the Wikipedia and text references so I could understand why it allowed variable length, and at my first look the construction didn't appear like you could truncate. Despite all of this, the CTR-mode section of the book includes a CPA-security proof and the CBC section says it is vulnerable to CPA. I'm going to try to dig through that to see why. If they are cognizant of the fact that same length attacks are something that makes you vulnerable, there must be a reason why they believe CTR/GCM are not.

tialaramex 8y ago

> At least with TLS1.3 and QUIC we can pad encrypted data and get a measure of length-hiding back; enough to at least raise costs for passive fingerprinting attacks (and raise those costs more than CBC ever could on its own). I have to say this feels like both the more actionable and more insightful output of your... heresy. We are not going back to CBC. You say that some CBC attacks don't seem practical. The trouble with the Web is it's like some lunatic deliberately designed a system to be attacked. Oh you have a chosen plaintext attack that needs 1 million repetitions? Impractical. Wait, Javascript exists. OK, but even with Javascript who'd ever have a system that terminates HTTPS for completely unrelated parties on the same physical hardware - there's no way we'll get to exploit that? Oh, bulk hosting exists. OK. Still nobody would build a crypto system in which one party is just completely anonymous all the... oh wait, that's exactly how Tim's system was designed. Eric Rescorla has some great slides about this. Whereas "Hey, let's pad every message to hit the path MTU size for packets" totally feels like something vendors could do next week and make a huge impact with no real cost. A lot of network devices can't hit their target speeds for small packets anyway, so the impact may be not merely negligible but literally non-existent. I have to say though, I'm not actually clear on why we couldn't pad TLS 1.2's AEAD modes to the same effect? The TLS 1.3 padding is _clever_ but what does it do here that makes it more important for your passive fingerprinting attack than the older padding scheme (with an AEAD cipher)?