1994-07-26 - Re: Garage Door opener, etc…

Header Data

From: jimn8@netcom.com (Jim Nitchals)
To: jimn8@netcom.com
Message Hash: 68a3c4f068152781de1d6a8dc91173a7813901073a75adc9e9dd58f2dcaab7b5
Message ID: <199407261819.LAA03524@netcom13.netcom.com>
Reply To: <199407261650.LAA12122@zoom.bga.com>
UTC Datetime: 1994-07-26 18:19:22 UTC
Raw Date: Tue, 26 Jul 94 11:19:22 PDT

Raw message

From: jimn8@netcom.com (Jim Nitchals)
Date: Tue, 26 Jul 94 11:19:22 PDT
To: jimn8@netcom.com
Subject: Re: Garage Door opener, etc...
In-Reply-To: <199407261650.LAA12122@zoom.bga.com>
Message-ID: <199407261819.LAA03524@netcom13.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


I'm in favor of a one-way transmission system, even though a challenge-
response system is more fun.  The costs are much higher for a remote with
both transmitter and a receiver sensitive enough to work without a decent
antenna.
 
That said, Jim Choate writes:

> Seems to me the way to do this is to 'dock' the receiver and xmitter prior
> to leaving (could rationalize it by also doing battery charging at this
> time) and each time they share a unique one-time pad.

The remote and opener could exchange a list of OTP entry codes.  The list
could be sufficiently large that docking would be unnecessary for months.
With a public key system, the remote could transmit its OTP by radio,
eliminating the need for docking hardware.

The opener should not accept codes out of order.  If it accepts code 'n'
from the OTP list, it should ignore codes 1..n thereafter.  That helps to
reduce the risk of having your remote "borrowed" for awhile to acquire
codes.

I like the OTP because the message size can be set arbitrarily small
as a tradeoff of transmission time against security level.  With full
message encryption, the minimum message is necessarily bulky.

For example, the minimum DES block size is 64 bits.  With a OTP, though,
a 48 bit number might suffice.  Assume the OTP is 2^7 entries long, and
transmission takes a second.    A hacker can generate abouabout 2^22 tries
in a full month if he's broadcasting continuously.  The odds of succeeding
in finding a 48 bit OTP entry would be about (48-22-7), or 1 in 2^19,
in that time.  Again, transmission speed is an important issue.  The
overall responsiveness and convenience of a system can hinge on trivial
details like the number of bits in a message sent by slow radio.

If you're uncomfortable with a 1 in 500,000 chance of being hacked by
a persistent criminal who'd rather not break into your car or find another
point of entry, by all means bump up the OTP entry size to 64 bits.

I could be wrong about transmission time, but it's my impression that
it's a lot easier to shovel a few dozen bits per second through a cheap
transmitter than a few thousand.  It makes sense not to redesign the
transmitter anyway (FCC approval can be a pain sometimes!)

- Jim Nitchals





Thread