[110462] in cryptography@c2.net mail archive
Re: Intercepting Microsoft wireless keyboard communications
daemon@ATHENA.MIT.EDU (James A. Donald)
Tue Dec 11 13:34:22 2007
Date: Tue, 11 Dec 2007 13:49:19 +1000
From: "James A. Donald" <jamesd@echeque.com>
To: "Steven M. Bellovin" <smb@cs.columbia.edu>
CC: "Ian Farquhar (ifarquha)" <ifarquha@cisco.com>,
"Leichter, Jerry" <leichter_jerrold@emc.com>,
cryptography@metzdowd.com
In-Reply-To: <20071210015136.105c0045@cs.columbia.edu>
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@metzdowd.com
