Subject: Re: terminal handling: collecting inter-keystroke timings
To: Travis H. <firstname.lastname@example.org>
From: Daniel Carosone <email@example.com>
Date: 10/24/2005 17:54:19
Content-Type: text/plain; charset=us-ascii
On Mon, Oct 24, 2005 at 01:56:11AM -0500, Travis H. wrote:
> Supposing I was interested in collecting inter-keystroke timings on
> Unix for the purposes of biometric authentication, what would be a
> clean way of doing so?
Probably a kqueue on the tty with timing data in the events returned.
> Ideally any mechanism would be flexible enough that I could have it
> deliver me timings between key-down, key-up-to-key-down, or up/down to
> up/down timings. And it should be efficient enough that it can
> deliver most of them unprocessed to some userland collector daemon
> which does the filtering of outliers and whatnot.
tty won't get you that, you'd need to do that in the device-specific
keyboard driver, or perhaps wskbd at best. also won't work over the
network, except for X events, and then with timing artifacts that
likely make it useless anyway.
> A secondary use of this would be to characterize/quantify the amount
> of entropy available from keystroke timings, given that they are
> quantized and enqueued (in hardware) several times on their way to the
There's some of this in rnd already, though the estimator is not
really useful or valid. Contributions and improvements welcome.=20
> Since I'm on the subject, a related project I had in mind would be
> hacking the keyboard to do its raster-scan in a pseudo-random order
> that was synchronized with the terminal driver such that the signal on
> the wire was, if not encrypted, at least scrambled enough to be
> difficult to convert back into plaintext. What would this involve on
> the kernel side?
Cute idea, but I doubt it's possible, or if it is that it's useful.
I'm pretty sure this is all within the keypad itself, and not visible
to the driver; the line to the pckbd controller on the long cable is
just serial events. You probably need a new keyboard chip, both to do
the randomised scanning and to do encryption on the serial line - and
even then it might not help you much.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)
-----END PGP SIGNATURE-----