Correct me if I'm wrong, but I think the common practice in internet is to
use the public key for initial private key exchange. And then, rest of the
communication takes place with the DES (data encryption standard) or other
non-PKC (public key cryptography) method.

Since the PKC would ensure secure key transmission, and DES would ensure
fast computation, this scheme would work quite well. I'm not sure if anyone
tried it, but there is a freeware called "PGP Phone" (pretty good privacy
phone) that sent encrypted real time (sort of) voice through the internet.
This was before all the hoopla about internet phone and such.

Predecessor to PGP phone was PGP, which was only for e-mail. It was pretty
nice software since it could embed binary files. I used to use it for
sending "secret" love e-mails to my girlfriend and plans to take over the
world to my comrades in mars (hahaha!!!)

Following fable was told to me a long time ago, supposedly being used by
RSA (click on netscape's help -> about netscape)...
1. Send public key (home PC to DigiKey)
2. Encrypt the DES key using the public key (DigiKey to home PC)
3. Send the credit card number using the DES key (home PC to DigiKey)
4. Send two weeks of paycheck to the credit card company through snail
mail.

If you want to do cryptography, be careful. Do a search on Phil Zimmerman
and see all the crock the government put him through. By the way, DES is
very easily cracked by the (USA) government. In fact, they have the golden
key that would allow them to see any DES encryption. I heard Phil Zimmerman
got into such trouble, because they (the government) couldn't crack his
code which was based on RSA.

Of course, I often had dreams of cracking the RSA using hundreds of
thousands of PICs in parallel. So, anyone else want to try?



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.