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