RE: Critics blast Windows 2000's quiet use of DES instead of 3DES
At 10:03 AM 5/18/00 -0400, Paul Kierstead wrote:
>OK, so I want to prevent some regular, every-day hackers from picking up my
>traffic. Or I just want reasonable protection for my passwords in Telnet or
>FTP. You are saying that some guy in his basement can break DES?
There's a lot of spare cycles *not* being used to comb RF for aliens...
If you're only worried about the bored sysop with grep and five minutes to
spare, use rot13 -and you can do this at OC192+ no prob :-)
>I'm inclined to use 3-DES since
>the performance hit doesn't make much diff to my DSL-lite line
DES was designed for hardware. Its slow in software. 3 DES is thrice
as bad. Modern ciphers are faster, and well supported by modern CPUs
(IDEA was designed for CPUs with 16-bit multipliers; Blowfish for CPUs with
4 kby cache).
The *only* reason for using DES (or 3DES) is legacy systems, ie, backwards
interop. IPSec stacks (like *all* crypto things) should come with, and
negotiate to use, better crypto when they can. Which should be most of the
time, given how new both sides of most links will be. (Most of the
computers ever built are alive today..)
I suppose it doesn't really matter what alg you use, as long as you're not
using your CPU for much else, and you're only driving a slow line. That
situation, especially the latter, won't last.
Steam engines are fine for railroads, not so great for cars, and
useless for airplanes. DES is a steam engine.
>I am not excusing MS; their flaw was misleading the user.
Bingo.
Problem is, this is a very serious fraud; its not just a typical
MS lie ("WinNT server is *much* different from NT workstation")
but something that has real implications for the people who need
it most... MS has a real strong reputation for designing in convenience
over security...
If software were buildings, the first woodpecker to come along would
knock down civilization.
If MS-software were locks, the first lockpicker to come along
would pass through like a ghost.
Re: Critics blast Windows 2000's quiet use of DES instead of 3DES
"L. Sassaman" <[EMAIL PROTECTED]> writes: > > > Frankly, I can't understand why the IPsec protocol still allows DES. > > > > We are waiting for AES. > > So am I correct in assuming you are saying that DES will be disallowed as > part of the IPsec protocol when AES is finalized? > > This would be good. I still think that DES should be dropped immediately, > however. I'm guessing that they have to have a MUST cipher, and they don't want to change twice, so it makes sense to wait until September and then make AES (or AES primary) the only MUST cipher. -- __ \/ o\ [EMAIL PROTECTED] *NOTE NEW EMAIL ADDRESS* \ / /\__/ Paul Crowley http://www.cluefactory.org.uk/paul/ /~\
Re: Critics blast Windows 2000's quiet use of DES instead of 3DES
-BEGIN PGP SIGNED MESSAGE-
At 08:58 AM 5/18/00 -0400, Russell Nelson wrote:
>L. Sassaman writes:
> > PGP's source code has always been available for public review.
> > This has not changed. There are no "back doors" for the NSA in
> > PGP,
>
>Unless they are particularly subtle ones, based on a
>mathematical understanding that is not yet publicly known. Remember
>that the NSA knew about differential cryptanalysis well before
>anyone else. Times have changed, but maybe less than we
>think.
If there are weaknesses that the NSA didn't put there, they're holes,
not back doors. If the NSA knows how to break some of the algorithms
(IDEA, CAST-128, 3DES, RSA, SHA1, El Gamal, etc.), that's still not a
back door, it's a successful cryptanalysis. It seems very unlikely
to me, but maybe an F-16 would have seemed pretty damned unlikely to
Orville Wright, too.
On the up side, if NSA knows how to break (say) CAST-128 with few
enough resources to be useful (e.g., 2^{80} work, 2^{40} memory, a
few thousand known plaintexts), that fact will be kept secret. Which
means that they will have to be *very* careful making any use of
information recovered from that break, to avoid leaking the fact that
they can break it.
>-russ nelson <[EMAIL PROTECTED]> http://russnelson.com
- --John Kelsey, [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.1 Int. for non-commercial use
Comment: foo
iQCVAwUBOSTXcSZv+/Ry/LrBAQENeAP/VL1RU+d6ClOD+hvoeY20r1XmyJ5eLvms
isjHq0NuK05Rs3kJ0Hnpx1qv0kB9h2DiMOGLO/Z+lWjCt93F4z6t7aRDQGVKhNPK
LM+Pv9bTyywLpPPAYDYUIvJQjSUcF63OiSpCDpWmVMO6BY2Vdp/9Mh5qvWZ+8Td5
3BpMyMpKBgY=
=WBJe
-END PGP SIGNATURE-
Re: Critics blast Windows 2000's quiet use of DES instead of 3DES
Paul Kierstead wrote: > > > Frankly, I can't understand why the IPsec protocol still > > allows DES. It > > should require strong encryption. Having DES in a product > > these days makes > > about as much sense as mandating the usage of ROT13. > > OK, so I want to prevent some regular, every-day hackers from picking up my > traffic. Or I just want reasonable protection for my passwords in Telnet or > FTP. You are saying that some guy in his basement can break DES? Yes! My document explaining why Linux FreeS/WAN does not implement DES, and why we think no-one should use it http://www.freeswan.org/freeswan_trees/freeswan-1.3/doc/DES.html has a section about that. " What about someone working alone, without the resources of a large " organisation? For them, cracking DES will not be easy, but it may be " possible. A few thousand dollars buys a lot of surplus workstations, " and will buy even more as Year 2000 concerns drive more old machines " into the surplus market. A pile of such machines will certainly heat " your garage nicely and might break DES in a few months or years. Or " enroll at a university and use their machines. Or use an employer's " machines. Or crack security somewhere and steal the resources to crack " a DES key. Or write a virus that steals small amounts of " resources on many machines. Or . . . " None of these approaches are really easy or break DES really quickly, " but an attacker only needs to find one that is feasible and breaks DES " quickly enough to be dangerous. How much would you care to bet that " this will be impossible if the attacker is determined and/or clever? " How valuable is your data? Are you authorised to risk it on a dubious " bet? > For that matter, lets say I am protecting data from somewhat more > sophisticated attackers. DES still requires significant resources to crack > and I may have some level of assurance that it isn't worth their while. Or > maybe I just want to waste their resources. > > OK, DES isn't great, but it is still sufficient for some (maybe even many) > purposes. If your threat model isn't severe and you need the bandwidth more, > then DES is fine. No. The notion that there is a trade-off here is a myth promulgated by people interested in encouraging the use of weak ciphers. Ciphers with adequate keylength need no more computation than those without. Use CAST-128 or Blowfish or IDEA, or your favorite AES candidate. Those ciphers are all significantly faster than DES, and none have the obvious, known weakness of inadequate key size. > If you really need to protect your data, particularly from > government agencies, use something better. I'm inclined to use 3-DES since > the performance hit doesn't make much diff to my DSL-lite line and the other > end has more then sufficient horsepower to handle many 3-DES connections; > others may be in a more difficult position w.r.t. bandwidth vrs. security. > > I am not excusing MS; their flaw was misleading the user. Their real mistake > is that the item should have been labeled '3-DES or DES (export friendly)'. > > Paul Kierstead > TimeStep Corporation > mailto:[EMAIL PROTECTED] http:\\www.timestep.com
Re: IP: FBI insists it can tap e-mail without a warrant
In message <[EMAIL PROTECTED]>, "Perry E. Metzger" writes: >> >>As interpreted by the FCC, the act also would require telecommunications >>providers to turn over "packet-mode communications" - such as those that >>carry Internet traffic - without the warrant required for a phone wiretap. I think that the probability that the FBI will be allowed access to packet content without a warrant is about zero. There's too much precedent against them. First, look at the origin of the current Federal wiretap law (18 USC 2511). Circa 1967 (I'm on a plane and don't have my references handy), the U.S. Supreme Court ruled that warrantless wiretaps were violations of the Constitution. The principle of stare decisis (which I can type but not pronounce...) makes it quite improbable that they would overturn that ruling, this soon. The legislative response was Title III of the Ombnibus Crime Control Act of 1968, which set out the current wiretap requirements. These were amended by the ECPA to cover other forms of communications. The CALEA requirements are for headers -- for better or worse, the equivalent data in the voice world, the caller and called numbers, are not protected as strongly. One can argue that those are, legally speaking, more easily obtainable. The argument was made to the FCC that it's very hard to separate headers from content (and rightly so, I think -- consider all the myriad forms of tunneling). So the FBI said, in effect, "give us all the data and we'll do the hard stuff". It's very hard to see how that will fly. It certainly won't in New York, where the courts have ruled that even pen registers require a wiretap warrant, since the same technology is involved. Using not just the same technology, but actually turning over the content on a promise of good behavior, with no warrant -- that's not one I'm worried about. (Of course, if it passes muster, I'll be *very* upset, but I very much doubt that that will be the case.) --Steve Bellovin
htaccess help
[This isn't cryptography related, but helping John keep his web site of useful crypto information working well helps the community, so I'm allowing it. If you aren't a web server type who knows how to help, you probably want to delete this now. --Perry] We need help on analyzing the adverse effect of using .htaccess to block misbehaving IP addresses. We first installed the file in September 1999 to block a single looping machine at kisa.or.kr. Then added a few more as such loopings occurred from other addresses. Recently we discovered that nearly all our logfiles have been inaccurate and asked our provider, Verio, to tell us why. Turns out the culprit was .htaccess, according to Verio. We were blamed for listing hostnames to block rather than numeric IP addresses, which led reverse lookup to go haywire (see message below). Removal of .htaccess immediately stopped the inaccuracies, and reinstallation with only numeric addresses seems to work just fine, so that seems to have been the problem. We are attempting to analyze the inaccurate logs for a particular brief period and cannot find a pattern which would produce accuracy. (Yes, we regularly delete logfiles to protect privacy) Verio claims that the inaccurate logs were generated automatically and there is no way to regenerate them accurately. Help would be appreciated on means to figure out how to translate the inaccuracies into accuracies. This involves only about two dozen logfile entries we need to accurately identify (more on that when the details can be substantiated -- it's about suspected gov improprieties). A related odd discovery: Last December, visitors from ncsc.mil, including what we call the "NSA bot," disappeared from the logfiles. We assumed the site was no longer of interest or that cover addresses were now being used. Well, maybe wholly coincidental, when we removed .htaccess a few days ago the ncsc.mil addresses, including the NSA bot, began reappearing in the logfiles. Reinstallation of .htaccess with only numeric addresses has had no affect on the ncsc accesses. Would anyone know what to make of this? -- From: David Klein <[EMAIL PROTECTED]> Subject: Re: [IDS-946244] CRYPTOME.ORG and JYA.COM To: [EMAIL PROTECTED] Date: Fri, 12 May 2000 07:41:55 -0400 (EDT) Dear John, Thank you for contacting technical support. In response to your questions: Our Apache implementation has HostnameLookups turned off - the access_log.custom file should NOT have hostnames in it. The lookups are done by logparse/logip when the servers' master log file is parsed. However, you had a bunch of 'deny from' directives in his .htaccess that used hostnames: [addresses xxx'd here for privacy] order allow,deny deny from 165.xx.xx deny from xxx.virtualwebsites.com deny from xxx.att.com deny from xxx.att.com deny from xxx.att.com deny from xxx.nj.dial-access.att.net deny from 208.xxx.xxx.xxx.flyswat.com allow from all This forces Apache to look up the hostnames, so it knows where to deny from. Since they are already looked up, they are put into the log. So, when logparse runs, it takes the hostname, thinks it's an IP address, and tries to reverse it - with unpredictable results. You will need to put only IP addresses in your .htaccess file. We tried commenting out the entries with hostnames and then only IPs were logged - which would be correctly parsed by logip. I hope this clarifies things a bit more for you. If you wish to find some more information about Apache configurations, please take a look at http://home.verio.net/support/hosting/htaccess.cfm. There are also some links there for more detailed information about Apache modifications. If you have any other questions, please feel free to contact us. Have a good day. Sincerely, David K. Tech Support
Re: Critics blast Windows 2000's quiet use of DES instead of 3DES
Actually, the SAAG voted to drop DES from IPsec back in, oh, the Minneapolis IETF in March '99 (IIRC). I think the problem is that nobody has revved the IPsec docs. -derek Paul Crowley <[EMAIL PROTECTED]> writes: > "L. Sassaman" <[EMAIL PROTECTED]> writes: > > > > Frankly, I can't understand why the IPsec protocol still allows DES. > > > > > > We are waiting for AES. > > > > So am I correct in assuming you are saying that DES will be disallowed as > > part of the IPsec protocol when AES is finalized? > > > > This would be good. I still think that DES should be dropped immediately, > > however. > > I'm guessing that they have to have a MUST cipher, and they don't want > to change twice, so it makes sense to wait until September and then > make AES (or AES primary) the only MUST cipher. > -- > __ > \/ o\ [EMAIL PROTECTED] *NOTE NEW EMAIL ADDRESS* \ / > /\__/ Paul Crowley http://www.cluefactory.org.uk/paul/ /~\ > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH [EMAIL PROTECTED]PGP key available
Re: Critics blast Windows 2000's quiet use of DES instead of 3DES
At 12:56 AM 5/19/00 -0500, John Kelsey wrote: >few thousand known plaintexts), that fact will be kept secret. Which >means that they will have to be *very* careful making any use of >information recovered from that break, to avoid leaking the fact that >they can break it. >- --John Kelsey, [EMAIL PROTECTED] Surely you know this is the first thing taught to pro (vs academic) analysts? People have died to conceal analysis (see Kahn on WWII); the US can't convince anyone about the five-million-dollar-man (bin Laden; or link Libya to Lockerbie, etc.) because the spooks don't want to reveal their sources. This is even stated fairly frequently by the mouthpieces in D.C. these days. So not tipping your hand is standard procedure; ergo history favors paranoia. [Covert agents also appreciate it when you don't act immediately on things they've leaked to you.. makes them too easy to sniff/snuff out..] Vulnerability analysts are like blackhat crackers: they don't send memos to the design team...
Re: GPS integrity
> This makes it quite possible to detect this kind of simple > spoofing by using two or more GPS antennas located a known distance from > each other and checking to see that the positions computed from the > signal out of each one differ by the known distances. Sounds like some interested parties should take some GPS gear and some radio receiving and test gear to one of the spots where the millatree is warning airmen that "for the next two weeks, GPS doesn't work here", and see just what sort of jamming they are using... John
Re: Critics blast Windows 2000's quiet use of DES instead of 3DES
In message <[EMAIL PROTECTED]>, Paul C rowley writes: >I'm guessing that they have to have a MUST cipher, and they don't want >to change twice, so it makes sense to wait until September and then >make AES (or AES primary) the only MUST cipher. Correct. --Steve Bellovin
RE: Critics blast Windows 2000's quiet use of DES instead of 3DES
Someone made the comment in this thread (I can't seem to find it again) that a bug in MS security that counts as a hole, not a backdoor. But a cooperative relationship between Microsoft and NSA (or any vendor and their local signals security agency) can be more subtle. What if Microsoft agreed not to fix that bug? What if Microsoft gives NSA early access to source to look for bugs? The NSA may not need much more than an agreement that certain portions of, say, the RNG object code will never change (or only change infrequently, with lots of notice). That might be enough to insure that NSAs viruses and Trojan horses can always find the right spot to insert a patch that weakens random number generation. It may be time to question whether we should ever expect that mass market operating systems from commercial vendors will protect users against a targeted attack from a high resource operation such as the major signals intelligence agencies. Users may have to rely on open source OS's and security tools that are light weight, easy to audit and isolated from the OS. Perhaps the best we can expect from a commercial OS is enough protection to make it hard to scan data in transit for users who super encrypt with stronger tools. Arnold Reinhold
Re: Critics blast Windows 2000's quiet use of DES instead of 3DES
-BEGIN PGP SIGNED MESSAGE- "L. Sassaman" wrote: > On Wed, 17 May 2000, Dennis Glatting wrote: > > > > Frankly, I can't understand why the IPsec protocol still allows DES. It > > > should require strong encryption. Having DES in a product these days > > > makes about as much sense as mandating the usage of ROT13. > > > > > > > We are waiting for AES. > > So am I correct in assuming you are saying that DES will be disallowed as > part of the IPsec protocol when AES is finalized? > > This would be good. I still think that DES should be dropped immediately, > however. > "Steven M. Bellovin" wrote: > > In message <[EMAIL PROTECTED]>, Paul > C rowley writes: > > >I'm guessing that they have to have a MUST cipher, and they don't want > >to change twice, so it makes sense to wait until September and then > >make AES (or AES primary) the only MUST cipher. > > Correct. > Not historically. This has been an issue since long before AES was viable. When Perry and Phil and I wrote the first IPSec DES RFC in 1995, we recommended: It is suggested that DES is not a good encryption algorithm for the protection of even moderate value information in the face of such equipment. Triple DES is probably a better choice for such purposes. But the IPSec WG refused to make 3DES an official option. We had to publish as "Experimental". Since immediately after Deep Crack, Scott Bradner and I have had an Applicability Statement draft out for years! An Applicability Statement is a "Best Current Practice" that tells everyone in the Internet what is recommended. The Steering Group (IESG) officially REJECTED Last Call for the IETF, saying: The Security ADs do not agree with the conclusion "Currently deployed equipment using DES should be eliminated, or upgraded to a more robust algorithm and key length." Instead they believe that new applications should use stronger technology and that efforts should be made to gracefully phase out the use of DES. The IESG therefore considers summary elimination proposed by your document inappropriate We are also not prepared to move RFC-2419, RFC-2405, RFC-1829 to Historic status at this time. If the relevant Working Group makes a request to the IESG to move its RFCs to Historic Status, the IESG will consider it. FYI, the PPP WG _DID_ ask! Here's the current history section from the latest (unposted) draft: History On July 20, 1998, William Allen Simpson, with the concurrance of Perry Metzger and Phil Karn, asked that their DES encryption Proposed Standard [RFC-1829], and the related PPP DES encryption Proposed Standard [RFC-1619], be declared Historic (removed from the Standards Track), and recommended DESX [SB97] and Triple-DES [SMKD97] as interim Proposed Standards until the selection of AES. With the assistance of Scott Bradner, this Applicability Statement was written to reflect the recommendation. Instead, the IESG approved RFC-2405 (November 1998) and RFC-2419 (September 1998) for publication as Proposed Standards. On March 18, 1999, the Security Area Advisory Group overwhelmingly approved removal of DES from the Standards Track, and recommended Triple-DES as mandatory to implement. This Applicability Statement was updated to reflect the recommendation. Instead, the IESG approved RFC-2574 (April 1999) for publication as + Proposed Standard.+ On November 8, 1999, the Point-to-Point Protocol Extentions Working + Group overwhelmingly approved removal of DES [RFC-2419] from the + Standards Track, and recommended Triple-DES [RFC-2420] as mandatory + to implement. On November 10, 1999, this recommendation was + forwarded to the IESG Internet Area Directors by the Working Group+ Chair.+ Unfortunately, in a communication dated December 3, 1999, the IESG+ officially refused to publish this document as an Applicability + Statement, stating they are "not prepared to move RFC-2419, RFC-2405, + RFC-1829 to Historic status at this time." -BEGIN PGP SIGNATURE- Version: PGP 6.5.1 iQCVAwUBOSWLedm/qMj6R+sxAQEALgQAo+JYQjKU5H5W8QcPUjNzCmf7tRpGWv1w v5lRXkzYs0Vlgfe/im/dm2fdA9T0YUmwcM0CqCY9FlC66iHeyKbeW69DhjvYk//i QF3TqovutleLPawCzJil58dF8UQNVT2Ph2XET7SuA167haL33LSNTARqZWkcg1gZ B0gd935BFeU= =VaLi -END PGP SIGNATURE-
Re: Critics blast Windows 2000's quiet use of DES instead of3DES
David Honig wrote: > The *only* reason for using DES (or 3DES) is legacy systems, ie, backwards > interop. IPSec stacks (like *all* crypto things) should come with, and > negotiate to use, better crypto when they can. Which should be most of the > time, given how new both sides of most links will be. (Most of the > computers ever built are alive today..) This is not true. DES is the most intensely scrutinized block cipher available to us. I would think most security professionals would trust 3DES more than any of the AES candidates, for instance, which have received much less analysis. For now, many people accept the lesser performance of 3DES in exchange for the reduced risk. Relatively inexpensive 3DES IPSEC hardware is readily available which makes performance less of a concern. andrew
RE: Critics blast Windows 2000's quiet use of DES instead of 3DES
At 02:25 PM 05/19/2000 -0400, Arnold G. Reinhold wrote: > . But a cooperative relationship between Microsoft and NSA >(or any vendor and their local signals security agency) can be more >subtle. What if Microsoft agreed not to fix that bug? What if >Microsoft gives NSA early access to source to look for bugs? The NSA >may not need much more than an agreement that certain portions of, >say, the RNG object code will never change (or only change >infrequently, with lots of notice). That might be enough to insure >that NSAs viruses and Trojan horses can always find the right spot to >insert a patch that weakens random number generation. This is one of the more believable scenarios I've heard for back-doors supported by organizations outside of Microsoft. I remain skeptical that NSA, Microsoft, or anyone else can build a truly foolproof back-door (i.e. one that doesn't spring open by mistake when Matthew Broderick happens to call). I doubt NSA would want to entrust national security on the problematic behavior of a software flaw as opposed to a throughly designed and analyzed back door mechanism. But I like the idea of diddling with the RNG. People are unlikely to look for such an attack, but it gets them what they want, especially when they use best crypto practices and change keys often. >It may be time to question whether we should ever expect that mass >market operating systems from commercial vendors will protect users >against a targeted attack from a high resource operation such as the >major signals intelligence agencies. . I think there's a much more profound risk of such a back-door being installed by a hostile overseas organization or by organized crime. If the NSA approaches Microsoft to acquire their support of NSA's surveillance mission, then the information will have to be shared with a bunch of people inside Microsoft, and they're not all going to keep it secret. On the other hand, any well-heeled organization could approach a single disgruntled employee with a hefty bribe (say, a recent employee with newer, less valuable stock options). If the employee is involved in bugfixing, the organization could probably purchase a back-door. The employee will have a strong motivation to not tell anyone about it since it would get him fired, it might be in violation of various laws, and the folks who paid him might come after him if word gets out. Those same motivations for silence aren't as much at work if someone is told to do something on NSA's behalf as part of their regular work duties. I suppose if the mafia or the KGB-du-jour can do this, then so can the NSA, if there's a bureaucrat there who's enough of a risk taker and has enough motivation. I remain skeptical that there's anyone there with enough budget and guts to take that approach to data collection, regardless of the perceived benefits. Too much risk to the career if word gets out. Rick. [EMAIL PROTECTED]
