Matt Blaze describes a couple of possible attacks against the simple one-way authenticating garage door opener. The attacks are basically the ones that are often suggested against one-way login authentication protocols. However, I think the garage door opener scenario is just different enough that the attacks he describes can be ignored or eliminated without overly complicating the devices. (The following idea is a combination of ideas stolen from earlier posts. plus a couple of new ones. Anyone following this thread should recognize the earlier ideas and hopefully mentally credit the original posters.) The transmission is one-way, from hand unit to base. There is no encryption involved, no hash functions, no counter values to transmit, no loosely synchronized clocks. The hand unit consists a transmitter, a memory chip, a simple cpu chip, and some kind of jack or plug used to initialize the unit. Initialize the hand unit and base with identical sets of large random numbers using a wall mounted panel. The random numbers will be arranged in groups of, say, ten. I'll call each group a "family". Since memory is cheap, load hundreds of families of random numbers. Both the hand unit and the base will maintain an internal counter of the "current family number". As numbers from a family are used, the "current family number" is incremented. If the two "current family numbers" get off, then the hand unit and base will have to be re-initialized. To open the door, push the button on the hand unit (duh) to send the first random number from the "current family". The base unit opens the door if the received number is in the "current family" of random numbers. If the door opens, the "current family number" counter in the base unit is incremented and the remaining numbers in the previous "current family" become invalid for opening. The "current family number" in the hand unit automatically increments after about a minute from the time of the button push. If the first button push/transmission didn't get received, a second button push (within a minute) will send another number from the same family, activating the door. If the first transmission is successful, but the driver continues to push the button, the subsequent transmissions are useless to an interceptor/man-in-middle because the numbers transmitted are from a family that has just become invalid for opening. To close the door (within a minute of opening): pushing the button sends another random number from the original family (i.e. the same family used to open the door, now invalid for opening). Since the door is in the open position, the base unit interprets the transmission as a request to close the door. NOTE: the base unit ignores all button pushes while the door is in the process of opening. WRINKLE: If you wait more than a minute before trying to close the door, the hand unit increments to the next family number. Therefore, when the door is in the open position, the base unit will actually check the received random number against both the previous "current family" and the current "current family". The major flaw I see in this scheme is that the "current family number" in the hand unit may become off frequently due to accidental button pushes. ... Now that I've gotten to the end of the description, I'm not so sure this scheme is practical. I get the feeling that the delayed auto-increment of the hand unit will create situations that violate the principle of "Least Surprise". In other words, the hand unit may not always do what you expect it to do. Oh well, I'll post my description anyways in case it induces some better ideas in others. Jim_Miller@suite.com