At 04:23 AM 6/20/2002 -0700, you wrote: >--- Dustin Puryear <[EMAIL PROTECTED]> wrote: > > At 04:53 PM 6/19/2002 -0500, you wrote: > > what are the component primes of 1,034,325?) So.. I > > guess that's my point. > > One computation is *relatively* easy, while the > > other is just plain hard. > >Wait a sec. You are basing your observation on the >time it takes _your_ brain to factor component primes? >:) I know, I know, this was merely an anology.
As mathematics stands now, it is not only more difficult for my brain to perform this calculation, but for large numbers, it is more challenging for a computer to perform this calculation. >But I don't follow your argument. > >First, you say that there is no _necessary_ reason >that encryption/decryption should require lots of CPU >overhead. Then you give an example where computing the >prime factors of a small number takes less computing >power than a large number. Doesn't that example give >more weight to Edward's assumption that better >encryption needs more CPU power? No. I had hoped to imply just the opposite of what you are saying here. There is no requirement that encryption be difficult, but there is every requirement that decryption be difficult. Ie, finding b given: f(z) = b should be easy (the encryption process), where z is the plaintext and b is the ciphertext. Conversely, finding z given b (the decryption) should be difficult, unless you already know some special value that allows you to short-cut the process (eg., the key). Perhaps I wasn't being clear on this. There is no requirement whatsoever that the computation of f(z) be difficult. It can be, but there is no requirement, or desire, for that to be the case. In fact, the more difficult that process is, the more limited the application of the encryption algorithm. You want less difficulty, not more. (Eg., you want your Palm pilot to be able to compute f(z) within a reasonable amount of time.) >Let me make sure I understand what you are saying, >when you say: > >f(z) = b > >I assume b is the message that is secret, and z is the >private encryption key, and f(z) is a PKI kinda >encryption algorithm. Is this true? z is the plaintext: "This is a secret message to John." b is the ciphertext: "DFJK0dsf00dff00ddff++dfff" f() is some generic encryption process. >Please make your argument very plain, for I am quite >dense. As am I. Does my explanation above help? Just consider this: are you trying to make it difficult to encrypt or decrypt something? The goal is to make decryption expensive. Therefore, most cryptography uses the concept of f(z) = b, where computing f(z) is easy, but computing z given b is difficult. f(z) can be hard, but if you can get away without making that so, why not? Therefore, my remark about it not being desirable. Regards, Dustin "The Fumbling Explainer Guy" Puryear --- Dustin Puryear <[EMAIL PROTECTED]> UNIX and Network Consultant http://members.telocity.com/~dpuryear PGP Key available at http://www.us.pgp.net In the beginning the Universe was created. This has been widely regarded as a bad move. - Douglas Adams
