Intercepting Microsoft wireless keyboard communications

[James A. Donald]

Steven M. Bellovin wrote:
> It's moderately complex if you're trying to conserve bandwidth (which
> translates to power) and preserve a datagram model.  The latter
> constraint generally rules out stream ciphers; the former rules out
> things like encrypting the keystroke plus seven random bytes with a
> 64-bit block cipher.  Power is also an issue if your cipher uses very
> much CPU time or custom hardware.
> 
> I"m sure most readers of this list can propose *some* solution.  It's
> instructive, though, to consider everything that needs to go into a
> full system solution, including the ability to resynchronize cipher
> states and the need to avoid confusing naive users if the cat happened
> to fall asleep on the space bar while the CPU was turned off.

Use CFB mode.  That takes care of all the above problems.  You can 
transmit any small bunch of bits, don't need to transmit a complete 
block, and if the keyboard and the receiver get out sync, the keyboard's 
signal will be decrypted as garbage for the first 128 bits.  If one has 
the keyboard regularly transmit "no key's pressed" from time to time, 
and if valid key press representations have a couple of check bits 
redundancy, with several keypresses being ignored after any invalid key 
signal, keyboard and receiver will synchronize with no fuss.


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