From: sidney@taurus.apple.com (Sidney Markowitz)
Date: Tue, 26 Jul 94 13:42:09 PDT
To: cypherpunks@toad.com
Subject: Re: CYPHERPUNKS TO THE RESCUE
Message-ID: <9407261836.AA07639@federal-excess.apple.com>
MIME-Version: 1.0
Content-Type: text/plain


Sandy Sandfort <sandfort@crl.com> wrote:

>Am I missing something here?  Why would you need a clock?

I recently used a smart card system for secure remote access to a network.
It looked like both the card and the remote system had clocks that were in
synch and both ran the same PRNG to produce a new number every minute. Part
of the login procedure was to enter the number currently being displayed on
the card.

A garage door opener built on this principle would not need the ability for
the base to transmit any codes, for the remote to receive any, nor to
encrypt or decrypt anything. Just a continuously running, clocked PRNG, the
ability for the base to receive signals sent by the remote and compare the
numbers, and some provision for synching up the clock and state of the PRNG
with that of the remote, probably using a physical connection. The remote
would transmit a code to the opener. The code would be available to someone
listening in, but it would only be valid for the current clock period. The
length of the clock period would be a trade off: Too long, and someone
could listen in and enter the garage after you have left but before the
current code has expired. Too short, and you will have to synch up the
remote and the receiver too often to be convenient. (I.e., if the clocks
drift by four seconds per year, you can go quite a while with one number
per minute, but less than a month at one number per second, before the
system becomes unuseable without resynching.) There also has to be some
provision for a retry if you happen to signal close to the transition time,
within the period where they are out of synch.

 -- sidney <sidney@apple.com>