logoalt Hacker News

dathinabyesterday at 7:51 PM5 repliesview on HN

> Keystroke obfuscation can be disabled client-side.

please never do that (in production)

if anyone half way serious tries they _will_ be able to break you encryption end find what you typed

this isn't a hypothetical niche case obfuscation mechanism, it's a people broke SSH then a fix was found case. I don't even know why you can disable it tbh.


Replies

advisedwangyesterday at 8:25 PM

That doesn't sound right to me. This obfuscation isn't about a side-channel on a crypto implementation, this is about literally when your keystrokes happen. In the right circumstances, keystroke timing can reduce the search space for bruteforcing a password [1] but it's overstating to describe that as broken encryption.

[1] https://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf

show 1 reply
lazypenguinyesterday at 7:58 PM

They literally explain the mechanism in the post and then explain why the security tradeoff made sense for their ssh game………

eikenberryyesterday at 8:31 PM

It is to prevent timing attacks but there are many ssh use cases where it is 100% computer to computer communications where there is no key based timing attack possible.

show 2 replies
simplicioyesterday at 8:54 PM

The fix seems kind of crazy though, adding so much traffic overhead to every ssh session. I assume there's a reason they didn't go that route, but on a first pass seems weird they didn't just buffer password strokes to be sent in one packet, or just add some artificial timing jitter to each keystroke.

show 2 replies
shadowgovtyesterday at 8:06 PM

But they'd have to be on the same network as me to do that attack, right?

show 1 reply