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?
>> 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.
> 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.
> 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.
This is usually the case, because public-key encryption is computationally
expensive. That's why you encrypt a (cryptographically-"strong") randomly
chosen session key with RSA, and send that along. On the other hand, if
the message is only a few bytes long, then there's no point in using
symmetric encryption algorithm, like DES, because the message is approximately
the same length as the key.
> 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.
This is bogus drivel.
First, Zimmerman's difficulties were due to the belief of the government that
he had exported crytography implementations without approval. This is
entirely different than just wanting to use cryptography.
Second, if you have evidence that anyone has broken DES using some "key",
please give us a reference to it, rather than unsubstantiated rumor. DES
is "weak" enough that a determined attacker can amount a brute-force
attack on it. This is completely different than using some hidden weakness
in the algorithm.
Third, ZImmerman's "problems" were export-regulation based, and not due
to the fact that RSA public key cryptography and IDEA (a symmetric
cipher) are believed to be cryptographically strong.
None of this is any big secret; there are numerous web pages that
chronicle these developments which make it unnecessary to speculate or
just plain make things up.
> Of course, I often had dreams of cracking the RSA using hundreds of
> thousands of PICs in parallel. So, anyone else want to try?
I dunno, given the lack of hardware multiply and divide, I don't think
they'd be very suited at all, given the types of computations required.
>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?
Lehigh University did this last year. All the PC's on campus (during
summer) figured it out in a few days. But you probably won't read about it
in your local newspaper.
Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
Hardware & Software for Industry & R/C Hobbies
"Go fast, turn right, and keep the wet side down!"
==================================================================
> >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?
>
> Lehigh University did this last year. All the PC's on campus (during
> summer) figured it out in a few days. But you probably won't read about it
> in your local newspaper.
"THE MAGIC WORDS ARE SQUEAMISH OSSIFRAGE" if I recall, was encoded as a
really big number (taking digits pairs for letters, hence
200805001301070903002215180419...
T H E M A G I C W O R D S
and this number was then encrypted using a fairly short key (something like
400 bits). It took quite awhile, but that particular key was broken. On
the other hand, the difficulty of breaking an RSA key increases exponentially
with the key's length. Keys under 512 keys are considered "toys", but even
if every electron in the known universe could be harnessed to perform a
billion computations per second, it would still take millions of years to
break 2048-bit keys (btw, producing a new 2048 key takes about 256 times as
long as producing a new 512 bit key; public-key operations on the longer key
will take about 16 times as long as with a 512-bit key, and private-key oper-
ations will take about 64 times as long. Note that while the longer keys are
a computational pain to use they are hardly impossible, especially on faster
machines.)
