5 ms·

Removal of the diffuser is very suspicious, given its importance. Machines were weaker when Vista shipped, so that's an odd claim, about security. And since AES

Removal of the diffuser is very suspicious, given its importance. Machines were weaker when Vista shipped, so that's an odd claim, about security. And since AES-NI is more widespread I'd bet overall the system is even faster! They should back up such a claim with solid benchmarks (I never had a problem with it.) Plus they could make it optional, and/or disable it on low power machines. MS should have pushed to get the diffuser into whatever "standards" (I'm guessing OPAL/eDrive) they are worried about. And IIRC, the diffuser is quite fast, but nothing stops them from implementing an even faster one.

pbsd 11y ago
> And IIRC, the diffuser is quite fast Kinda. When Elephant was designed AES-NI did not exist, and so AES was expected to work at somewhere between 10-20 cycles per byte. Elephant worked somewhere between 5-10 cpb, so it was not a lot of overhead. Post-AES-NI, however, the majority of CPU time is now spent on the diffuser. Furthermore, SSDs were not popular at the time this was designed. So the relative low speed of software AES + diffuser was not that big a deal. Now, with 500 MB/s and higher drives, cipher speed matters. For reference, 10 cpb translates to ~200 MB/s in your average 2 GHz processor. This is not to say that removing Elephant was a good idea, but the performance argument is not entirely unreasonable. It is of course possible to design a new diffuser that can take better advantage of modern chips; maybe they should do that.
- MichaelGG 11y ago
  Nice numbers, thanks. Is Elephant even available, though? Even if someone has a low end chip but needs a high IO rate and thus must turn off Elephant, why kill off the feature? That's what's so odd. They admit it's critical, then go on to completely delete it, no mention of why (until this one line explanation now). For many users, the perf impact is irrelevant. I rarely do high rate IO (boot and copying movies); even large compiles I doubt are hitting the 100MB/sec level. At 5cbp, even a low end Atom will get 100-200+MB/sec, right? What low end devices are pushing that on any frequent enough basis to hurt the user? And, given their weight, they could have forced these requirements into eDrive, and offload it all to the SSD controller.
- nickpsecurity 11y ago
  Curious, wasn't Vista shipping on computers that had to have more processing power and memory? Do you think that would negate the performance argument a bit or not be sufficient? It's hard for me to reconcile Microsoft's argument about security for lower-performance machines when they were forcing upgrades on customers at same time. Not to mention Vista's efficiency tradeoffs. (shudders)
  - tptacek 11y ago
    You think "more processing power and memory" "negates" the difference between hardware and software encryption?
    - nickpsecurity 11y ago
      My post was about software encryption. Maybe I should've clarified that better. The beefier machines Microsoft pushed for Vista might negate the performance hit that older hardware might experience with the Elephant option. I'm sure others have more expertise (eg performance comparisons of old machines) in that area so I asked them. Regarding your tangent, hardware encryption will almost always beat software encryption in same process node technology. The next best thing are processors highly-optimized for cryptography (eg GD's AIM), vector processing with crypto-focused operators (SIMD/MIMD), or massively parallel processing with tiny cores (eg FPPA, GPU's) using the right ciphers/cryptosystems. We saw less-mainstream work focusing on these three in late 90's and early 2000's because they would accelerate arbitrary crypto while making upgrades easy. Flexibility & cost-reduction trumped raw performance in many use-cases. Certain defense contractors still sell products like those with more R&D work ongoing. Also support my polymorphic cipher designs unlike hard blocks.
      - tptacek 11y ago
        I think you may have missed the gist of this subthread. The CBC diffuser in Bitlocker was removed in part because it doesn't benefit from the hardware crypto now shipped with Intel machines.
      - nickpsecurity 11y ago
tptacek 11y ago
What makes you think the diffuser is all that important? Even the "state of the art" in full disk encryption doesn't reliably protect the integrity of disk sectors (this was part of Rogaway's critique of XTS during its standardization).
- nickpsecurity 11y ago
  The comment is calling into question the intent of Microsoft in removing the diffuser. They thought it was important in benefiting security. So, did they remove it for performance or yet another concession to U.S. government? It's a valid question in assessing Microsoft's trustworthiness for security/crypto. Of course, we already have plenty on that subject. A good answer won't change anything. A bad one is extra nails in the coffin.
  - tptacek 11y ago
    I'm not interested in debating Microsoft's motives, because the engineering issues here are straightforward. The Bitlocker "diffuser" code attempts to make it harder to make targeted changes to plaintext, without making it Hard to do so, because making it Hard is prohibitively expensive. No mainstream full-disk encryption scheme makes it Hard to tamper with on-disk plaintext. The best anyone does is allowing attackers to randomize a wide-ish block at an attacker-chosen offset. It is hard to use that primitive to pop calc.exe on boot, but it remains a powerful primitive: attackers can replace integers in trusted code or data files with very very large integers, and then exploit the resulting memory corruption. The commenter below explains the performance implications, which are real.
    - nickpsecurity 11y ago
      Now that is a legitimate critique. It's why I prefer Inline Media Encryptors with trusted path. Those plus an encryption scheme addressing such known issues. The IME knocks the host TCB out of the equation, at least.
    - MichaelGG 11y ago
      It's been a while since I read the Bitlocker paper, but I remember having the distinct impression the author found it critical to have. And Ferguson knows more about this stuff than I ever will, so I trust his assessment. If this has changed, wouldn't it elicit a bit of an explanation? "Windows 8 takes advantage of better crypto knowledge to remove improve Bitlocker speed." I'd also note that the trend in Bitlocker seems to be to just delegate to the SSD, completely relying on the SSD vendor to get it right. That has zero performance overhead and is more suitable for low end devices.

pbsd 11y ago

> And IIRC, the diffuser is quite fast Kinda. When Elephant was designed AES-NI did not exist, and so AES was expected to work at somewhere between 10-20 cycles per byte. Elephant worked somewhere between 5-10 cpb, so it was not a lot of overhead. Post-AES-NI, however, the majority of CPU time is now spent on the diffuser. Furthermore, SSDs were not popular at the time this was designed. So the relative low speed of software AES + diffuser was not that big a deal. Now, with 500 MB/s and higher drives, cipher speed matters. For reference, 10 cpb translates to ~200 MB/s in your average 2 GHz processor. This is not to say that removing Elephant was a good idea, but the performance argument is not entirely unreasonable. It is of course possible to design a new diffuser that can take better advantage of modern chips; maybe they should do that.

MichaelGG 11y ago
Nice numbers, thanks. Is Elephant even available, though? Even if someone has a low end chip but needs a high IO rate and thus must turn off Elephant, why kill off the feature? That's what's so odd. They admit it's critical, then go on to completely delete it, no mention of why (until this one line explanation now). For many users, the perf impact is irrelevant. I rarely do high rate IO (boot and copying movies); even large compiles I doubt are hitting the 100MB/sec level. At 5cbp, even a low end Atom will get 100-200+MB/sec, right? What low end devices are pushing that on any frequent enough basis to hurt the user? And, given their weight, they could have forced these requirements into eDrive, and offload it all to the SSD controller.
nickpsecurity 11y ago
Curious, wasn't Vista shipping on computers that had to have more processing power and memory? Do you think that would negate the performance argument a bit or not be sufficient? It's hard for me to reconcile Microsoft's argument about security for lower-performance machines when they were forcing upgrades on customers at same time. Not to mention Vista's efficiency tradeoffs. (shudders)
- tptacek 11y ago
  You think "more processing power and memory" "negates" the difference between hardware and software encryption?
  - nickpsecurity 11y ago
    My post was about software encryption. Maybe I should've clarified that better. The beefier machines Microsoft pushed for Vista might negate the performance hit that older hardware might experience with the Elephant option. I'm sure others have more expertise (eg performance comparisons of old machines) in that area so I asked them. Regarding your tangent, hardware encryption will almost always beat software encryption in same process node technology. The next best thing are processors highly-optimized for cryptography (eg GD's AIM), vector processing with crypto-focused operators (SIMD/MIMD), or massively parallel processing with tiny cores (eg FPPA, GPU's) using the right ciphers/cryptosystems. We saw less-mainstream work focusing on these three in late 90's and early 2000's because they would accelerate arbitrary crypto while making upgrades easy. Flexibility & cost-reduction trumped raw performance in many use-cases. Certain defense contractors still sell products like those with more R&D work ongoing. Also support my polymorphic cipher designs unlike hard blocks.
    - tptacek 11y ago
      I think you may have missed the gist of this subthread. The CBC diffuser in Bitlocker was removed in part because it doesn't benefit from the hardware crypto now shipped with Intel machines.
    - nickpsecurity 11y ago

tptacek 11y ago

What makes you think the diffuser is all that important? Even the "state of the art" in full disk encryption doesn't reliably protect the integrity of disk sectors (this was part of Rogaway's critique of XTS during its standardization).

nickpsecurity 11y ago
The comment is calling into question the intent of Microsoft in removing the diffuser. They thought it was important in benefiting security. So, did they remove it for performance or yet another concession to U.S. government? It's a valid question in assessing Microsoft's trustworthiness for security/crypto. Of course, we already have plenty on that subject. A good answer won't change anything. A bad one is extra nails in the coffin.
- tptacek 11y ago
  I'm not interested in debating Microsoft's motives, because the engineering issues here are straightforward. The Bitlocker "diffuser" code attempts to make it harder to make targeted changes to plaintext, without making it Hard to do so, because making it Hard is prohibitively expensive. No mainstream full-disk encryption scheme makes it Hard to tamper with on-disk plaintext. The best anyone does is allowing attackers to randomize a wide-ish block at an attacker-chosen offset. It is hard to use that primitive to pop calc.exe on boot, but it remains a powerful primitive: attackers can replace integers in trusted code or data files with very very large integers, and then exploit the resulting memory corruption. The commenter below explains the performance implications, which are real.
  - nickpsecurity 11y ago
    Now that is a legitimate critique. It's why I prefer Inline Media Encryptors with trusted path. Those plus an encryption scheme addressing such known issues. The IME knocks the host TCB out of the equation, at least.
  - MichaelGG 11y ago
    It's been a while since I read the Bitlocker paper, but I remember having the distinct impression the author found it critical to have. And Ferguson knows more about this stuff than I ever will, so I trust his assessment. If this has changed, wouldn't it elicit a bit of an explanation? "Windows 8 takes advantage of better crypto knowledge to remove improve Bitlocker speed." I'd also note that the trend in Bitlocker seems to be to just delegate to the SSD, completely relying on the SSD vendor to get it right. That has zero performance overhead and is more suitable for low end devices.