6 ms·

Why do we never get proactive defense against this sort of thing? As with speculative execution, caching, out-of-order execution, dispatching instructions to mu

Why do we never get proactive defense against this sort of thing? As with speculative execution, caching, out-of-order execution, dispatching instructions to multiple ALUs depending on availability, etc, it was clear from the get-go that in principle the timing can depend on the payload so in principle it can be a problem for crypto. The need for constant time should have first class support on the language/compiler level, the OS level, the ISA level, and the hardware level. E.g. the processor could guarantee that the instructions of a certain section of code are executed at a constant rate, the OS could guarantee that the thread remains pinned to one core and the frequency fixed, and the compiler could guarantee that only branchless assembly gets emitted.

p0ckets 4y ago
Until consumers demand this as a requirement, it won't happen. Almost everyone would rather have a compiler/language/OS/ISA/CPU that's finishes faster some of the time, rather than one that finishes at the same time all the time. It would just appear (especially in benchmarks) to be slower for no apparent benefit. Maybe we can introduce a new set of instructions that are guaranteed to be constant time, but good luck convincing the compiler/language/OS to use these slower instructions even if just for the code that is important for security.
- p0ckets 4y ago
  And for this particular attack, constant time isn't even enough! You would need either constant power, or limit the frequency when running secure code (which again reduces performance).
  - Atheros 4y ago
    Constant time comparisons take practically no time at all. I hardly see how it would noticeably reduce performance if software could command a CPU to lock to a low frequency for a certain period of time or when the sensitive code finishes, whichever happens first. The OS could track how often this happens and give a simple UI so that we can blame those applications that abuse it.
mlyle 4y ago
> Why do we never get proactive defense ... The need for constant time should have... We got proactive constant time on a lot of cryptographic operations. The problem is, it's not constant power.. and DFS provides a window by which you can make remote power measurements.
- throwawaylinux 4y ago
  That wasn't proactive it was in response to earlier timing analysis attacks.
sounds 4y ago
Simplest solution here is to implement the algorithm in hardware, with a new instruction that has all the security attributes. (Including resistance to power differential and timing differential attacks.) Downthread: https://news.ycombinator.com/item?id=31745105 https://news.ycombinator.com/item?id=31745105
- mike_hock 4y ago
  But this is inflexible.
  - sounds 4y ago
    True. But did you want a microcode vulnerability? That'd make for another one of these awesome HN discussions...
  - mordae 4y ago
    Then start adding FPGAs! Seriously, this has been talked about for ages now. If every platform had a good enough FPGA, it could be used for cryptography and/or to accelerate some specific computations. Abd without having a set of algorithms baked into the silicon, it would not make the device eventually obsolete as the world moves to better algorithms.
    - littlecranky67 4y ago
      Not only has it been talked about for ages, Intel bought Altera and AMD bought Xilinx. One has to wonder and ask - why? Edit: > it would not make the device eventually obsolete as the world moves to better algorithms Ah there I found it. Makes sense to buy the FPGA manufacturers, so they devices still become obsolete and people buy their newer processors.
SilverBirch 4y ago
This is engineering, there's a lot of things that could happen but don't, we don't all run ECC RAM either. The problem is that speculative execution is really good and if Intel didn't have it they would've been selling worse CPUs. And to be clear, it was about 20 years from the point where people were seriously publishing theories about speculative execution attacks to the point where it was a practical attack. Think about how much benefit we gained during that time. And even then, anyone running in a trusted environment would rather have the optimization consequences be damned. Do you think HFTs patched their boxes to criple their perfomance? No. Sure, now we know it's a problem we'll offer solutions for people who really need it. But it'll be a long while before the average person needs to think about this and in the meantime billions of people benefitted from better CPUs.
- goodpoint 4y ago
  > we don't all run ECC RAM either ...because Intel placed profit above user's needs and choose not to allow ECC on desktops. Similarly, many other things have been made insecure by plain greed.
  - gambiting 4y ago
    The other way of looking at it is that a huge portion of the market is running non-ECC ram and it hasn't resulted in any measurable reduction of security or stability of operating systems worldwide. So maybe it really isn't necessary for your average user, and manufacturing ECC ram for users who ultimately don't need it would be just a waste(both financial and environmental).
    - goodpoint 4y ago
      > hasn't resulted in any measurable reduction of security or stability of operating systems worldwide Except it did.
      - hunterb123 4y ago
        By how much?
staticassertion 4y ago
Discovering and reporting these flaws is proactive defense.

p0ckets 4y ago

Until consumers demand this as a requirement, it won't happen. Almost everyone would rather have a compiler/language/OS/ISA/CPU that's finishes faster some of the time, rather than one that finishes at the same time all the time. It would just appear (especially in benchmarks) to be slower for no apparent benefit. Maybe we can introduce a new set of instructions that are guaranteed to be constant time, but good luck convincing the compiler/language/OS to use these slower instructions even if just for the code that is important for security.

p0ckets 4y ago
And for this particular attack, constant time isn't even enough! You would need either constant power, or limit the frequency when running secure code (which again reduces performance).
- Atheros 4y ago
  Constant time comparisons take practically no time at all. I hardly see how it would noticeably reduce performance if software could command a CPU to lock to a low frequency for a certain period of time or when the sensitive code finishes, whichever happens first. The OS could track how often this happens and give a simple UI so that we can blame those applications that abuse it.

mlyle 4y ago

> Why do we never get proactive defense ... The need for constant time should have... We got proactive constant time on a lot of cryptographic operations. The problem is, it's not constant power.. and DFS provides a window by which you can make remote power measurements.

throwawaylinux 4y ago
That wasn't proactive it was in response to earlier timing analysis attacks.

sounds 4y ago

Simplest solution here is to implement the algorithm in hardware, with a new instruction that has all the security attributes. (Including resistance to power differential and timing differential attacks.) Downthread: https://news.ycombinator.com/item?id=31745105 https://news.ycombinator.com/item?id=31745105

mike_hock 4y ago
But this is inflexible.
- sounds 4y ago
  True. But did you want a microcode vulnerability? That'd make for another one of these awesome HN discussions...
- mordae 4y ago
  Then start adding FPGAs! Seriously, this has been talked about for ages now. If every platform had a good enough FPGA, it could be used for cryptography and/or to accelerate some specific computations. Abd without having a set of algorithms baked into the silicon, it would not make the device eventually obsolete as the world moves to better algorithms.
  - littlecranky67 4y ago
    Not only has it been talked about for ages, Intel bought Altera and AMD bought Xilinx. One has to wonder and ask - why? Edit: > it would not make the device eventually obsolete as the world moves to better algorithms Ah there I found it. Makes sense to buy the FPGA manufacturers, so they devices still become obsolete and people buy their newer processors.

SilverBirch 4y ago

This is engineering, there's a lot of things that could happen but don't, we don't all run ECC RAM either. The problem is that speculative execution is really good and if Intel didn't have it they would've been selling worse CPUs. And to be clear, it was about 20 years from the point where people were seriously publishing theories about speculative execution attacks to the point where it was a practical attack. Think about how much benefit we gained during that time. And even then, anyone running in a trusted environment would rather have the optimization consequences be damned. Do you think HFTs patched their boxes to criple their perfomance? No. Sure, now we know it's a problem we'll offer solutions for people who really need it. But it'll be a long while before the average person needs to think about this and in the meantime billions of people benefitted from better CPUs.

goodpoint 4y ago
> we don't all run ECC RAM either ...because Intel placed profit above user's needs and choose not to allow ECC on desktops. Similarly, many other things have been made insecure by plain greed.
- gambiting 4y ago
  The other way of looking at it is that a huge portion of the market is running non-ECC ram and it hasn't resulted in any measurable reduction of security or stability of operating systems worldwide. So maybe it really isn't necessary for your average user, and manufacturing ECC ram for users who ultimately don't need it would be just a waste(both financial and environmental).
  - goodpoint 4y ago
    > hasn't resulted in any measurable reduction of security or stability of operating systems worldwide Except it did.
    - hunterb123 4y ago
      By how much?

staticassertion 4y ago

Discovering and reporting these flaws is proactive defense.