| > Exactly what makes this problem so difficult eludes me, although one
| > suspects that the savage profit margins on consumables like
| > keyboards and mice might have something to do with it.
| >
| 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.
Somewhere - perhaps in the Computerworld article - someone mentions that
some devices use Bluetooth, "and are therefore much more secure".
In practice, most Bluetooth devices don't even agree on a non-zero
key when pairing, so just using Bluetooth is no promise of anything.
Does anyone know how good Bluetooth security can potentially be -
and is it practically attainable in the low power/lost message
context that would be needed here? How are some of the emerging
low-power protocols (e.g., ZigBee) dealing with this?
-- Jerry
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
