terminal handling: collecting inter-keystroke timings

["Travis H." <solinym@gmail.com>]

Hey,

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?

Would I have to hack up the terminal code, add some data structures,
some ioctls to query and reset them, etc. or is there some more elegant way
of going about it?  Perhaps I could write something that sits between
the terminal driver and the process which normally receives user input
first, and pipes it to that process instead of letting it inherit a fd
to the tty?

I'd like to be able to do it with (ttys attached to?) network sockets
as well, so that I could test out the applicability of it to remote
users.

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.

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
kernel.

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?

Any thoughts on the matter would be much appreciated.  I apologize in
advance if these questions convey an ignorance of terminal handling,
or if the right answer is "do it in userspace"; I couldn't immediately
think of a transparent way of doing so (and scheduling delays could
impact the timings in very significant ways).
--
http://www.lightconsulting.com/~travis/  -><-
"We already have enough fast, insecure systems." -- Schneier & Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B