4 ms·
> 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 cycle
by 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 agoNice 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 agoCurious, 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 agoYou think "more processing power and memory" "negates" the difference between hardware and software encryption?
- nickpsecurity 11y agoMy 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 agoI 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 agoRe-reading the comment, I see now. I think I just read it too fast before. Good catch to both of you. My bad.
- pbsd 11y agoVista did increase hardware requirements across the board. But the change we are discussing here was made in Windows 8 and later, which is exactly when Microsoft started caring about getting Windows into tablets and, in particular, ARM chips.