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 [EMAIL PROTECTED]

Reply via email to