Orthogonal to ticket but as the first C package we are likely to ship, we must think about reproducibly building it and redundant ways to validate this.

The first mitigation that comes to mind is to, similarly to T530, queue up all keyboard input events over a period of time (say, 30 milliseconds), and then process them all at once.

Orthogonal to ticket but as the first C package we are likely to ship, we must think about reproducibly building it and redundant ways to validate this.

According to this StackOverflow question, we should be able to get exclusive access to keyboard events (i.e. the events won't propogate past our handler) using only ioctl calls, which can be done in pure Python. Causing those events to be processed is somewhat harder, but one thing to consider is the Python X Library; if that were the case, we could do this 100% from pure python. One disadvantage to going the X Library route is that we'd need to make 100% sure that this fix is alive 100% of the time the X server is up, and 0% of the time it's not; otherwise, the system would become unresponsive to keyboard events. A possible solution to that would be to use uinput instead (Python bindings are available).

EDIT: After re-reading the issue description, I realize that netevent is probably the way to go. We could choose two ports on localhost (thus using the loopback interface), and run the same netfilter_queue script, but with a shorter delay (on the order of 15-30ms). If the delay were anything like the 150ms used for external network connections, then the whole system would feel incredibly sluggish.

According to the research:

https://github.com/vmonaco/keystroke-obfuscation

"Identification accuracy is reduced by 20% with a 25 ms random keystroke delay not noticeable to the user."

So I guess that should be the lower bound for this.

Update:

Researcher Vinnie Monaco is creating a sampling distribution library that an obfuscating input driver prototype can use or our netqueue solution.

https://github.com/vmonaco/keystroke-obfuscation/issues/1#issuecomment-243433528

For reference, kloak is being tracked here:

• try kloak anti keystroke deanonymization tool and leave feedback (done): T583
• keep an eye on kloak anti keystroke deanonymization tool: T596