// COMPLETE THREAD

Re: CYPHERPUNKS TO THE RESCUE

5 expanded posts ยท every known parent and child

NODE 00639e4cRe: CYPHERPUNKS TO THE RESCUE
At 14:43 1994/07/25 -0700, Sandy Sandfort wrote:
>The questions are:  Could standard auto and garage door openers
>easily be retrofitted?  Could a "crypto remote" with its own CPU
>be made small enough to fit into a hand-held unit?  Could such a
>system be made for a reasonable cost?
...
Sounds like an application for a "challenge-response" system. But that
would require transmission from garage unit to car unit.

If there were syncnronized clocks then the signal could be a function of
time so that the above replay would fail. That requires only a PRNG.

Both units could compute the next password from the same PRNG but this
would require a "backspace" button on the car unit for those occasions
where the garage unit failed to hear a broadcast signal. A "reset to new
known state" for both units would be required for when the state became
hoplessly confused.
NODE bd5888c0Radio-activated locks...and protecting them
(I've changed the thread title from "CYPHERPUNKS TO THE
RESCUE"...after all, doesn't that describe _most_ of our threads?)

Norm Hardy wrote:

> At 14:43 1994/07/25 -0700, Sandy Sandfort wrote:
> >The questions are:  Could standard auto and garage door openers
> >easily be retrofitted?  Could a "crypto remote" with its own CPU
> >be made small enough to fit into a hand-held unit?  Could such a
> >system be made for a reasonable cost?
> ...
> Sounds like an application for a "challenge-response" system. But that
> would require transmission from garage unit to car unit.
> 

This is also the motivating idea behind "zero-knowledge interactive
proof systems." Systems in which interception of the sent information
is useless to the attacker.

As Norm mentions, the "lock" (which can be many things besides garage
door openers, e.g., proximity-based door locks, or auto locks
themselves, or gun locks, etc.) needs to "do something" that
essentially creates a problem that only the key can solve. A simple
example is public key-private key: the lock demands that a message be
decrypted, or signed, or whatever, by the key.

A good project for Cypherpunks as a group to work on, which I took to
be Sandy's meaning? Well, we don't have any real group projects, and
this is unlikely to be one.

A good project for some particular Cypherpunk? Maybe. I understand the
electronic lock folks (card locks, hotels, etc.) have crypto expertise
of varying extents (and bluntly, probably more than most of us have)
and they certainly have the expertise in other areas.

Maybe an existing chip could be added to "Genie"-type openers.

But let's not forget that such a project, if it succeeded, would
result in legislation requiring Garage Door Opener Escrow.

--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
"National borders are just speed bumps on the information superhighway."
NODE 65675419Re: CYPHERPUNKS TO THE RESCUE
Date: Tue, 26 Jul 1994 00:11:34 -0700
   From: norm@netcom.com (Norman Hardy)

   At 14:43 1994/07/25 -0700, Sandy Sandfort wrote:
   >The questions are:  Could standard auto and garage door openers
   >easily be retrofitted?  Could a "crypto remote" with its own CPU
   >be made small enough to fit into a hand-held unit?  Could such a
   >system be made for a reasonable cost?

   Sounds like an application for a "challenge-response" system. But that
   would require transmission from garage unit to car unit.

   If there were syncnronized clocks then the signal could be a function of
   time so that the above replay would fail. That requires only a PRNG.

Why not generate a random number, checksum it, and sign it using a
public key?  Or is that overkill?

-russ <nelson@crynwr.com>    http://www.crynwr.com/crynwr/nelson.html
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | What is thee doing about it?
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.
NODE 46e6a26eCYPHERPUNKS TO THE RESCUE
Why not generate a random number, checksum it, and sign it using a
   public key?  Or is that overkill?

That's overkill.  For an affordable microprocessor for the price point
of an electronic lock, you can't do a modular exponentiation in a
reasonable amount of time.  A two-second delay is likely too long for
_mass_ market, even if certain markets would bear it.  Sandy also
suggest public key.

A shared secret key for a symmetric cipher is sufficient, since the
binding between a single garage and a single opener is usually not
broken.  If your opener had to work with multiple doors, and if the
usual case pertained where two people share the permission to open
some doors but not others, then public key woudl be needed.

So you can do challenge/response, but there's no need to use public
key.  DES would be sufficient.

Eric
NODE 6aa07f91Re: CYPHERPUNKS TO THE RESCUE
> Sounds like an application for a "challenge-response" system. But that
> would require transmission from garage unit to car unit.

> If there were syncnronized clocks then the signal could be a function of
> time so that the above replay would fail. That requires only a PRNG.

> Both units could compute the next password from the same PRNG but this
> would require a "backspace" button on the car unit for those occasions
> where the garage unit failed to hear a broadcast signal. A "reset to new
> known state" for both units would be required for when the state became
> hoplessly confused.

I think a simple key seeded MD5 work work fine for garage doors:

The remote can transmit: (n, M(n^k))

Where n is random (and so doesn't repeat often), k is a shared key
known only to the remote and the door opener, and M is a reasonably
strong hash function.  k could be set by a bank dip switches, but
to get a large enough key space would require alot of switches.


brad