3 ms·

So I saw that their planned "fix" was to introduce random latency to the key presses to hide the true timings, but does that really help anything? When it come

So I saw that their planned "fix" was to introduce random latency to the key presses to hide the true timings, but does that really help anything? When it comes to timing attacks in things like decryption or password comparisons, I thought random latency was a pointless addition as it only requires a bit more sampling before you can pull the underlying differences out. Does it work in this instance just because the numbers involved are a few magnitude less would be with something like network requests?

relate 10y ago
I would have thought the same. However instead of adding random latency, one could have a buffer, that only allows a couple of fixed output rates (eg, 150,160,...,300 CPM), when typing. This would probably be quite annoying to type on though :-)
- amelius 10y ago
  The best solution would probably be to have the HTML input field not fire events for key down.
  - imagist 10y ago
    It's fairly easy to create a div which behaves the same way as a HTML input field, and there are other ways. Ultimately I think you'd have to not fire key events, period.
    - mjevans 10y ago
      Agreed, you'd have to fire string input rates, and defer the underlying update until either enough buffer has entered to warrant a mid-point sync, or input has paused for a decent length of time. (say 10s) For 'hardened' browsers I'd recommend a visual indication of this timeout (a pie chart which completes like a clock at a fixed rate while paused is the first concept that I think of).
- p4bl0 10y ago
  Yes, making it appear constant is the only real solution, if the attacker has access to multiple traces and is able to use some statistical tools. But this still suppose that the attack is carried over the network. If the attacker can, e.g., monitor the electrical activity of the physical keyboard, then it's another thing entirely.
gaius 10y ago
Ironically tho' delays between keypresses is an excellent source of entropy! So there is a circular dependency here which could be unravelled. http://www.securiteam.com/securitynews/5UP0D2AAUK.html http://www.securiteam.com/securitynews/5UP0D2AAUK.html Because of this, it is possible to measure keypress AND key release timings _very precisely_, for any console user of a machine we have an unprivileged account on.

relate 10y ago

I would have thought the same. However instead of adding random latency, one could have a buffer, that only allows a couple of fixed output rates (eg, 150,160,...,300 CPM), when typing. This would probably be quite annoying to type on though :-)

amelius 10y ago
The best solution would probably be to have the HTML input field not fire events for key down.
- imagist 10y ago
  It's fairly easy to create a div which behaves the same way as a HTML input field, and there are other ways. Ultimately I think you'd have to not fire key events, period.
  - mjevans 10y ago
    Agreed, you'd have to fire string input rates, and defer the underlying update until either enough buffer has entered to warrant a mid-point sync, or input has paused for a decent length of time. (say 10s) For 'hardened' browsers I'd recommend a visual indication of this timeout (a pie chart which completes like a clock at a fixed rate while paused is the first concept that I think of).
p4bl0 10y ago
Yes, making it appear constant is the only real solution, if the attacker has access to multiple traces and is able to use some statistical tools. But this still suppose that the attack is carried over the network. If the attacker can, e.g., monitor the electrical activity of the physical keyboard, then it's another thing entirely.

gaius 10y ago

Ironically tho' delays between keypresses is an excellent source of entropy! So there is a circular dependency here which could be unravelled. http://www.securiteam.com/securitynews/5UP0D2AAUK.html http://www.securiteam.com/securitynews/5UP0D2AAUK.html Because of this, it is possible to measure keypress AND key release timings _very precisely_, for any console user of a machine we have an unprivileged account on.