At 04:53 PM 6/19/2002 -0500, you wrote: > > At 02:09 PM 6/18/2002 -0500, you wrote: > > >Just offhand I'd say that didn't sound too bad ... if the > > security is to > > >be any good it *ought* to require a bit of cpu time. > > Basically it's a > > > > Why do you think that? > > > > Regards, Dustin > >Just a gut feeling Dustin, if it's very easy (i.e. quick) to encrypt >then it will probably be relativly easy to decrypt by a brute force >attack.
I disagree, and here is why. Most encryption algorithms are based on a function, or set of functions, where it is easy to determine b given: f(z) = b However, the idea is that it should be extremely difficult to determine z given b. I'm not saying that some encryption algorithms don't have a relatively high computational requirement for computing b, but there is no reason why that would be necessary or, more to the point, desirable. A good example of this type of function, and something heavily used in cryptography, is the use of the product of primes. One of the fundamental laws of mathematics (anyone remember which one? I know it has "Fundamental" in it somewhere) is that all whole numbers are the product of a unique set of primes. The trick is that even though everyone knows a really large whole number is the product of primes, it is computationally expensive to determine those prime numbers for numbers larger than some currently defined limit. Basically, it boils down to this. It takes me half a second to perform the following multiplication: 3 x 3 x 11 = 99 But it takes me two or three seconds to figure out that the component primes of 99 are 3, 3, and 11. The difference between the computational time required to compute the product of primes and the time required to determine the component primes of a number diverges rather quickly. (Quick, 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. (This is just one variation of the many uses of primes in this field. I am by no means an expert. I'm sure the fellows that Shannon works with could go on for days.) Is the VPN encrypting the packet contents or the complete packet? I >would expect that the latter would be slower but has the advantage of >hiding the traffic information. A VPN will typically encapsulate an entire encrypted IP packet within another IP packet. One side-effect of applying this technique on a per-packet basis, and something that stung SSH in the not so distant past, is that transmitting each packet as it is ready (after encryption) still offers information to an attacker. The solution apparently is to buffer packets until a clump of them are ready to be transmitted. >I'm just an interested observer here - not a VPN expert at all... >although I'm tempted to give WalMart a call and see if I can order a VPN ><grin> Certainly. I was just curious about your thoughts. Feel free to disagree back at me. Regards, Dustin --- 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
