At 08:02 PM 6/8/97 +0000, you wrote:
>>    Can anyone verify that Microchip's Keeloq system is as secure
>> as they (Microchip) claim it to be?  It seems to me that since
>> the receiver can "learn" a new transmitter on command, then
>> whoever programmed the receivers sholud know how to crack the
>> transmitter codes without knowing the serial numbers in the
>> transmitter.
>>    Or did I miss something?  Any comments?
>
>I don't have the datasheets for the Keeloq products handy.  However, here
>is some general information about different authentication methods that
>may be useful:
>
>Some secure methods that allow a receiver to key itself off a normal
>transmission:
>
>[1] Public key cryptosystem: the transmitter sends the receiver its public
>key, and then encrypts authentication requests with its private key.  This
>method is quite secure and works very well.  Its biggest weakness is the
>level of computing overhead required on the part of both the transmitter
>and receiver.

<CLIP>

> have to run the hash function 16 times (to get from 49200 to 49216).  It
> could then start using idle time to compute, e.g., hash(49184); the time
> required for that large hash could be quite long without any ill effects
> for the user: unless the user needed 16 different codes in the time it
> took to compute hash(49184) the system would never have to compute more
> than 16 hashes for a button push.
>
>If there's sufficient interest, I can write more on the subject--it really
>is quite fascinating.
>
>
Could you send me some more information about this, I'm doing some internet
programming related to this and could help.

Matthew Taylor