Intercepting Microsoft wireless keyboard communications

[James A. Donald]

Steven M. Bellovin wrote:
 > Believe it or not, I thought of CFB...
 >
 > Sending keep-alives will do nasties to battery
 > lifetime, I suspect; most of the time, you're not
 > typing.  As for CFB -- with a 64-bit block cipher (you
 > want them to use DES? they're not going to think of
 > anything different), it will take 9 keypresses to
 > flush the buffer.  With AES (apparently your
 > assumption), it will take 17 keypresses.  This isn't
 > exactly muggle-friendly.  Just think of the text in
 > the instructions... Redundancy?  I wonder how much is
 > needed to avoid problems.  It has to be a divisor of
 > the cipher block size, which more or less means 8
 > extra bits.  How much will that cost in battery life?

Keypress signals, or change of keyboard state signals,
do not need to be a divisor of the cipher block size.

At every block boundary, keyboard transmits a special
signal in the clear that signifies block boundary.  Any
time that no key has been pressed for a while, then when
a key is finally pressed, keyboard transmits a bunch of
no-ops sufficient to ensure that the recipient has
recently received an entire block, followed by a
complete description of current keyboard state, so that
recipient knows what change of keyboard state signals
are changes from.  Conversely, when the receiver has not
received any signal for a while, it expects such a
signal, and distrusts anything else. Muggle
unfriendliness only occurs if user is typing through a
boot up, which is unlikely to terribly surprise the
user, who is probably banging away at the same keys over
and over again waiting for a reaction, or if the user
wanders out of range while typing, then wanders back in
range again while still typing, in which case again the
user is unlikely to be very surprised.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com