3 ms·

Constant-time operations feel like such a hack. I mean, sure, if we could ensure that all operations were always constant-time, that'd be a rather simple, stre

by _Nat_ 7y ago

Constant-time operations feel like such a hack. I mean, sure, if we could ensure that all operations were always constant-time, that'd be a rather simple, stress-free way to get time-invariance. But the low-level implementation assumptions feel flimsy. Instead, if we want time-invariance, seems like we should just have dispatchers handle it -- this is, if we want the system to hide timing information, we should explicitly specify this behavior rather than trying to get it as a side-effect. --- Note: We don't actually need strict time-invariance so much as for any time-variance to not leak information about secrets. For example, if a dispatcher takes an hour to resume a process, then sure an attacker might very easily pick up on that time-variance introduced by the dispatcher, but so long as it doesn't reflect on any secret information, who cares?

mikeash 7y ago
One problem I see is in determining the amount of time before resuming. You have to be sure that all possible inputs will take less time than what you request, but you don’t want to wait forever. You also have to be robust against disturbances due to things like system load. If you specify a maximum time based on the no-load scenario, then an attacker discovers that they can bog down your system by flooding it with packets while it does the computation, you’re back to leaking info.
- _Nat_ 7y ago
  Yeah, a dispatcher would have to be designed to guard its secrets. For example, it'd have to ensure that it can do tasks in whatever window it needs to, have a logic for simulating CPU-load if an attacker might be able to watch the CPU's process load, potentially force the CPU to burn more power if we're trying to protect against power-analysis, etc.. Logically, it'd seem like a more complex task since we'd have to keep track of what secrets we're guarding and planning an execution strategy to meet those criteria. But, it feels cleaner to acknowledge these criteria and ensure that they're being addressed.

by _Nat_ 7y ago

mikeash 7y ago

One problem I see is in determining the amount of time before resuming. You have to be sure that all possible inputs will take less time than what you request, but you don’t want to wait forever. You also have to be robust against disturbances due to things like system load. If you specify a maximum time based on the no-load scenario, then an attacker discovers that they can bog down your system by flooding it with packets while it does the computation, you’re back to leaking info.

_Nat_ 7y ago
Yeah, a dispatcher would have to be designed to guard its secrets. For example, it'd have to ensure that it can do tasks in whatever window it needs to, have a logic for simulating CPU-load if an attacker might be able to watch the CPU's process load, potentially force the CPU to burn more power if we're trying to protect against power-analysis, etc.. Logically, it'd seem like a more complex task since we'd have to keep track of what secrets we're guarding and planning an execution strategy to meet those criteria. But, it feels cleaner to acknowledge these criteria and ensure that they're being addressed.