Introduce randommess in keypress timings

[oshwm]

On 06/10/15 21:15, Michael Nelson wrote:
> Alternatively all keystrokes could be done with fixed timing.  The point is that no individual pattern should be discernable.  There are more subtle aspects, such as jitter from perfectly regular timing, which could identify the machine/browser being used.  With added randomness, such jitter would be harder to discern.  Also, you would ideally not want eavesdroppers to know that you are obfuscating your keystrokes, and obfuscating via randomness, as opposed to fixed timing, would help with that.

My first thoughts were to use fixed timing but quickly realised that for
fixed timing to work, EVERYONE using a keyboard/mouse would have to have
their firmware modified otherwise your fixed timing would identify you
just as surely as your genuine timing patterns.
The randomness will also make each user appear as many different users -
not just hiding existing users but giving the impression that there are
many more users out there than truly exist (increasing the size of the
haystack).

> There are quite a few companies selling keystroke dynamics products as an authentication factor.  There are also various efforts, such as one started at Stanford a few years ago, to monitor all aspects of a person's input, for continuous background authentication.  Not sure how that one's going.  Keystroke dynamics normally works on a short chosen phrase.  The latter stuff is more ambitious and extends that to arbitrarily long text, along with grammatical patterns, etc.  There is nothing new here.
>
>
> After evaluating several products for a company I worked for, I built a keystroke dynamics product myself -- it was less work than going through the pain of registering for a trial of their software!  It was never used, for the same reason that kd is not used much -- it's more trouble than it's worth. It worked as well as any of the products being sold.
>
> Though a key down or key up event from the Windows operating system has a timestamp in it (the OS will not give you more than a certain accuracy, but it's adequate), that timestamp is discarded and not available in Javascript.  My Javascript solution calls for a new Date as soon as it captures a key event.  People selling this stuff say that as there is too much potential lag between the key event and the time thus associated, Javascript is not good.  The best thing is something like an ActiveX  plugin or a native client in C that can capture the timestamp from the OS.  The next best thing was touted as Flash.  However, mine worked very well.

This is exactly why modifying the firmware would be better than running
software either within the OpSys or on top of it - by the time your
software gets a look at the keystroke timing then another 'driver' etc
could already have seen it.
It is surprising to know that Javascript is fast enough not to have an
impact on system performance when monitoring the keystroke timing!

> If anyone is interested I will describe in simple terms how one tests the keystroke vectors, and some of the challenges.

Would be interesting to read this as there are probably many things I
hadn't even considered, thanks :)

> mn


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20151006/088ed82a/attachment-0002.sig>