Re: NSA _likes_ strong crypto?

Date: Thu, 15 May 1997 15:07:35 -0400 To: cypherpunks@cyberpass.net From: Thomas Porter <txporter@mindspring.com> Subject: Re: NSA _likes_ strong crypto? Reply-to: Thomas Porter <txporter@mindspring.com>
At 09:32 AM 5/15/97 -0700, Bill Frantz thoughtfully expounded thus:
During a hall discussion at CFP, I heard that people at NSA are changing their opinions about the use of strong crypto in the general community. The reason is the threat of InfoWar and the need for strong crypto in general use to secure the US information infrastructure.
I realize I may catch it for my numerical ignorance here, but a more paranoid type might think that any acquiescence on the part of NSA might be due to more relative ease of breaking important traffic than they might have possessed in the past.
Does any one on the list have any ideas on what the Intel mega-pentium parallel processor (touted for nuclear explosion and weather simulations a few months back, and noticeably missing any mention of NSA application) does to the time estimates for cracking "strong" crypto keys? I am being purposefully vague in my definitions of strong crypto, but I would present as my test cases PGP ascii-armor traffic of 2048 key length or plain files encrypted with pgp -c option; ie. typical crypto-criminal/narco-terrorist fodder.
How does this strength of encryption compare to whatever might be used to "secure the nation's info infrastructure" [Netscape 40 bit!!??] regarding cracking time? Clearly less, but how much less on this type of specialized parallel processor? To put it another way, any swags on how long it would take this pentium parallel processor to crack the current DES56 challenge?
Inquiring (and ignorant) minds want to know,
Tom Porter txporter@mindspring.com
1. You must assume that any well-heeled opponent will have built a Wiener engine, so the time to brute a DES key can be measured in hours, rather than days. A ciphertext-only attack is only a little harder than a known-plaintext attack. But that doesn't stop us from doing the calculation anyway. The fastest DES cracker I'm aware of (Bryddes) currently claims 615,000 keys/sec on a Pentium 120. The sandia machine is acheiving 1.06 Tflops with 7264 processors. The processors are 200 MHz Pentium Pros. (The Mflop rate is lower than the MHz rate). They plan to have 9200 of them when it's finished. 615k * 200/120 = 1.025Mkps (it'll actually be a bit higher on a Pro) 1.025M * 9200 = 9.430Gkps (2^56 = 7.2E16)/9.43E9 = 7.6 Msec = 88.44 days Thats a conservative, upper limit, not a SWAG. Speeds would be much higher on a 64 bit machine. I'm very curious to see how bitslice DES would run on an MMX Pentium, which has some 64 bit registers. 40 bit encryption is a bad joke = it would take about 2 min on this machine for 40 bit DES Peter Trei trei@Process.com Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei@process.com

On May 15, 6:05pm, Peter Trei wrote:
40 bit encryption is a bad joke = it would take about 2 min on this machine for 40 bit DES
Yes, 40 bit encryption is a joke, but one shouldn't extrapolate exponontially between 56 bit DES and 40 bit encryption. The work factor will not be less by a factor of 1/65536, but rather in the same ballpark. DES is generally faster to search than other ciphers (5-10 times faster than RC5), so if the 40 bit encryption is not with DES, 10 minutes would be a more accurate estimate. As for 40 bit DES, nobody uses DES as is with 16 bits of the key zeroed out. What is more likely is something like CDMF. A brute force attack on CDMF has about four times the work the factor of (56 bit DES / 65536). Again 10 minutes appear more accurate. Which is not to say that we are not discussing a joke. And talking about Wiener machines, they are much faster on DES than most other symmetric ciphers, especially something like RC5, which had reducing the efficiency of hardware crackers as a design goal. So, one should be careful about extrapolating from DES key search rates. -- Anil Das
participants (2)
-
das@razor.engr.sgi.com
-
Peter Trei