>    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.

[2] Reverse-sequence hash exchange [primitive version]

 (1) A one-way hash function is needed: this will take a 64- or 128-bit
     number and munge it into a different same-sized number.  Such
     functions should preferably be 1:1 or close to it, but should not be
     practical to run backwards (i.e. it should be to find the number
     which yields a particular hash value).

 (2) The seed key is a randomly-selected number which is selected for each
     transmitter.  In addition, the transmitter needs a counter that
     should start at some suitable value (e.g. 65536) and be decremented
     every transmission.  Note that this requires that each key be used a
     maximum of (that value) times; this limitation will be addressed with
     improved versions of the hash exchange, below.

 (3) Each time the transmitter sends a request, it should hash its key
     [counter] times and transmit the result along with the [counter]
     value.  Counter should then be decremented [if it hits zero, the key
     won't work any more--see below].  To save on codes, multiple requests
     within three seconds or so should probably keep using the same code.

 (4) When the transmitter receives a new key, it should store the hash
     value received along with the counter.  To authenticate a
     transmission, it should hash the received value [new-counter minus
     old-counter] times.  If this yields the old hash value, then the
     'key hash' and counter values should be updated.  If it's possible to
     send different types of messages, the receiver should probably allow
     multiple messages received within four seconds or so to use the same
     code (to be compatible with the transmitter doing likewise).

 Problems:
   -1- Limitted lifespan of keys
   -2- Excessive computation overhead in transmitter

[3] Transmitter-computation improvements of Reverse-Sequence Hash Ex.

 Rather than having to run the hash function all [however many] times for
 each transmission, the transmitter could keep the results of running
 the hash function some smaller number of times.  Any time the number of
 hashes remaining between the current key and the previously-computed key
 got too small, the transmitter could start using idle time to rediscover
 some earlier hash values in the sequence.

 For example, suppose the current key is 49216.  The "earlier key" might
 be 49200.  When the user pushed the button, the transmitter would only
 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.