March 15, 2000
by Bruce Schneier
President
Counterpane Systems
schneier@counterpane.com
http://www.counterpane.com
A free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security.
Copyright (c) 1998 by Bruce Schneier
In this issue:
Kerberos is a symmetric-key authentication scheme. It was developed at MIT as part of their Project Athena in the 1980s -- the protocol was published in October 1988 -- and has been implemented on various flavors of UNIX. The current version is Kerberos Version 5, which corrected some security vulnerabilities in Version 4. It's never taken over the authentication world, but it is used in many networks. These days, the Internet Engineering Task Force (IETF) controls the specification for Kerberos.
Kerberos is a client-server authentication protocol. (_Applied Cryptography_ goes into the protocol in detail.) For the point of this article, remember that there is a secure Kerberos server on a network. Clients log into the Kerberos server and get secure "tickets." The clients can use these tickets to log onto other servers on the network: file servers, databases, etc.
Kerberos is now part of Microsoft Windows 2000, sort of. The issue is that Microsoft has made changes to the protocol to make it noninteroperable with the Kerberos standard, and with any products that implement Kerberos correctly.
Specifically, the incompatibility has to do with something called the "data authorization field" in the Kerberos messages. All major Kerberos implementations leave the field blank. The new Microsoft implementation does not; it uses the field to exchange access privileges between the Kerberos server and the client.
There are two ways to look at this:
Since the field has no specific uses in the protocol (and no one else uses it), the fact that Microsoft is using the protocol is harmless.
Because Microsoft is refusing to publish details about its proprietary use of the field, they are harming interoperability and standardization. Other Kerberos vendors cannot directly support Windows 2000 clients.
Even worse, Microsoft bypassed the IETF in this process (there's a procedure you're supposed follow if you want to enhance, deviate from, or modify an IETF standard).
On the surface, this is just nasty business practices. If you're a company that has invested in a UNIX-based Kerberos authentication system and you want to support Windows 2000 desktops, your only real option is to buy a Windows 2000 Kerberos server and pay for the integration. I'm sure this is what Microsoft wants.
My worry is more about the security. Protocols are very fragile; we've learned that time and time again. You can't just make changes to a security protocol and assume the changed protocol will be secure. Microsoft has taken the Kerberos protocol -- a published protocol that has gone through over a decade of peer review -- and has made changes in it that affect security. Even worse, they have made those changes in secret and have not released the details to the world.
Don't be fooled. The Kerberos in Windows 2000 is not Kerberos. It does not conform to the Kerberos standard. It is Kerberos-like, but we don't know how secure it is.
Kerberos Web page:
http://www.isi.edu/gost/gost-group/products/kerberos/
IETF Specification:
ftp://ftp.isi.edu/in-notes/rfc1510.txt
ftp://athena-dist.mit.edu/pub/kerberos/doc/techplan.txt
Microsoft Kerberos information:
Windows 2000 Kerberos Authentication white paper --
http://www.microsoft.com/windows2000/library/howitworks/security/kerberos.asp
Introduction to Windows 2000 Security Services --
http://www.microsoft.com/WINDOWS2000/guide/server/features/secintro.asp
Guide to Kerberos Interoperability --
http://www.microsoft.com/windows2000/library/planning/security/kerbsteps.asp
Article by David Chappell about Kerberos and Windows 2000 --
http://www.microsoft.com/msj/defaulttop.asp?page=/msj/0899/kerberos/kerberostop.htm
"A Performance Comparison of the Five AES Finalists"
B. Schneier and D. Whiting, Third AES Candidate Conference, 2000, to appear.
In 1997, NIST announced a program to develop and choose an Advanced Encryption Standard (AES) to replace the aging Data Encryption Standard (DES). NIST chose five finalists in 1999. We compare the performance of the five AES finalists on a variety of common software platforms: current 32-bit CPUs (both large microprocessors and smaller, smart card and embedded microprocessors) and high-end 64-bit CPUs. Our intent is to show roughly how the algorithms' speeds compare across a variety of CPUs. Then, we give the maximum rounds cryptanalyzed for each of the algorithms, and re-examine all the performance numbers for these variants. We then compare the algorithms again, using the minimal secure variants as a way to more fairly align the security of the five algorithms.
http://www.counterpane.com/aes-comparison.html
More commentary on the ethics of publicizing vulnerabilities:
http://boardwatch.internet.com/mag/99/oct/bwm62.html
http://cgi.zdnet.com/slink?22157:8469234
An opinion on DDS attacks and the CD Universe fiasco:
http://www.osopinion.com/Opinions/GaryMurphy/GaryMurphy7.html
There's a new DSS standard:
Text --
http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=2000_register&docid=00-3450-filed
PDF --
http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=2000_register&docid=00-3450-filed.pdf
BAIT, DIRT, and other law-enforcement hacker tools. Some of the PR fluff
sounds too good to be true.
http://www.codexdatasystems.com/
H&R Block insecurity:
http://news.cnet.com/news/0-1005-200-1550948.html?tag=st.ne.1002.tgif?st.nefd.gif.d
The worst security product is the one that isn't used. Here are the
results of a PGP usability study. Most people can't figure out how to use
it. Some sent e-mail out unencrypted, believing it was secure.
http://www.wired.com/news/news/business/story/21484.html
http://www.cs.cmu.edu/~alma/johnny.pdf
Novell published a "security flaw in MS Active Directory Services" the day
before the MS launch of Windows 2000. Microsoft published a response
shortly thereafter. Both documents are full of marketing spin. Russ
Cooper has written an objective description of the non-issue:
http://ntbugtraq.ntadvice.com/NDSvsADS-01.asp
Good security software: a command-line tool for statically scanning C and
C++ source code for security vulnerabilities. It's called ITS4.
http://www.rstcorp.com/its4/
Mixter's paper on cracking:
http://mixter.void.ru/crack.txt
Excellent essay on the difference between hackers and vandals:
http://www.villagevoice.com/issues/0007/thieme.shtml
Commentaries on distributed denial-of-service attacks:
http://www.pbs.org/cringely/pulpit/pulpit20000217.html
http://www.thenation.com/issue/000313/0313klein.shtml
Usernames and passwords for sale:
http://www.wired.com/news/politics/0,1283,34515,00.html?tw=wn20000224
Sony PlayStation 2 is being held up for export (from Japan) due to crypto
in the system:
http://www.theregister.co.uk/000302-000026.html
Navajo code-talking GI Joe doll:
http://www.gijoe.com/lnavajo_code_talker.html
More speculation about Echelon:
http://www.zdnet.com/enterprise/stories/security/news/0,7922,2455560,00.html
http://www.gired.com/news/politics/0,1283,34932,00.html
Interesting use of a honey pot by the San Diego Supercomputer Center (or,
SDSC Hacks the Hackers):
http://security.sdsc.edu/incidents/worm.2000.01.18.shtml
The big AES news is the week of 10-14 April, 2000, in New York. Monday, Tuesday, and Wednesday are the 7th Fast Software Encryption workshop (FSE 2000). Thursday and Friday are the 3rd AES Candidate Conference (AES3). Both are in the New York Hilton and Towers. FSE 2000 will have several excellent papers on the AES candidates (new attacks on MARS, RC6, Rijndael, and Serpent), and AES3 will have nothing but. The papers for FSE 2000 have been selected, and are listed on the Web site. The papers for AES3 have not been announced yet. (The submission deadline for both conferences is long past.)
Come, be a part of cryptography history. It'll be fun.
FSE 2000:
http://www.counterpane.com/fse.html
AES3:
http://csrc.nist.gov/encryption/aes/round2/conf3/aes3conf.htm
Bruce Schneier was interviewed in Business Week:
http://www.businessweek.com/2000/00_10/b3671089.htm
This is a weird one. Two people in Minneapolis who allegedly stole information from their employers were charged with the possession of a "burglary tool" -- L0phtcrack, the program that automatically breaks Windows passwords.
The ramifications of this are unclear. There are some burglary tools that you can't carry unless you are a licensed professional (certain lockpicking tooks, for example); just having them is illegal. But screwdrivers and bolt cutters can also be burglary tools if they are used with the intent to commit a crime.
What it means to me is that the law is getting serious about this.
http://www.channel4000.com/news/stories/news-20000217-164727.html?&_ref=10005006010
They recently passed the Uniform Computer Information Transactions Act (UCITA). It's deeply disturbing. It could be subtitled "The Software Industry Wish List" for the amount of control (and absence of accountability) it gives UNDER LAW to software distributors.
Under the UCITA, Microsoft not only doesn't have to fix any of the 63,000 Windows 2000 bugs, it wouldn't even have to tell you any of them existed. It could also disable the OS of anyone it wants for essentially any reason it wanted (e.g., failing to abide by the license terms which restrict you from any public mention of apparent bugs in the software).
The governor has not signed the bill into law yet, but he is expected to.
http://www.lawnewsnetwork.com/practice/techlaw/news/A16380-2000Feb16.html
http://www4.zdnet.com:80/intweek/stories/news/0,4164,2436874,00.html
http://www.computerworld.com/home/print.nsf/CWFlash/000215ECDA
http://www.cnn.com/2000/TECH/computing/03/07/ucita.idg/index.html
The future of digital systems is complexity, and complexity is the worst enemy of security.
Digital technology has been an unending series of innovations, unintended consequences, and surprises, and there's no reason to believe that will stop anytime soon. But there is one thing that has held constant through it all, and it's that digital systems have gotten more complicated.
We've seen it over the past several years. Microprocessors have gotten more complex. Operating systems have gotten more complex. Computers have gotten more complex. Networks have gotten more complex. Individual networks have combined, further increasing the complexity. I've said it before, but it's worth repeating: The Internet is probably the most complex machine mankind has ever built. And it's not getting any simpler anytime soon.
As a consumer, I think this complexity is great. There are more choices, more options, more things I can do. As a security professional, I think it's terrifying. Complexity is the worst enemy of security. This has been true since the beginning of computers, and is likely to be true for the foreseeable future. And as cyberspace continues to get more complex, it will continue to get less secure. There are several reasons why this is true.
The first reason is the number of security bugs. All software contains bugs. And as the complexity of the software goes up, the number of bugs goes up. And a percentage of these bugs will affect security.
The second reason is the modularity of complex systems. Complex systems are necessarily modular; there's no other way to handle the complexity than by breaking it up into manageable pieces. We could never have made the Internet as complex and interesting as it is today without modularity. But increased modularity means increased security flaws, because security often fails where two modules interact.
We've already seen examples of this as everything becomes Internet-aware. For years we knew that Internet applications like sendmail and rlogin had to be secure, but the recent epidemic of macro viruses shows that Microsoft Word and Excel need to be secure. Java applets not only need to be secure for the uses they are intended, they also need to be secure for any other use an attacker might think of. Photocopiers, maintenance ports on routers, mass storage units: these can all be made Internet-aware, with the associated security risks. Rogue printer drivers can compromise Windows NT. Malicious e-mail attachments can tunnel through firewalls. Convenience features in Microsoft Outlook can compromise security.
The third reason is the increased testing requirements for complex systems. I've talked elsewhere about security and failure testing. The only reasonable way to test the security of a system is to perform security evaluations on it. However, the more complex the system is, the harder a security evaluation becomes. A more complex system will have more security-related errors in the specification, design, and implementation. And unfortunately, the number of errors and the difficulty of evaluation does not grow in step with the complexity, but in fact grows much faster.
For the sake of simplicity, let's assume the system has ten different settings, each with two possible choices. Then there are 45 different pairs of choices that could interact in unexpected ways, and 1024 different configurations altogether. Each possible interaction can lead to a security weakness, and must be explicitly tested. Now, assume that the system has twenty different settings. This means 190 different pairs of choices, and about a million different configurations. Thirty different settings means 435 different pairs and a billion different configurations. Even slight increases in the complexity of systems mean an explosion in the number of different configurations . . . any one of which could hide a security weakness.
The increased number of possible interactions creates more work during the security evaluation. For a system with a moderate number of options, checking all the two-option interactions becomes a huge amount of work. Checking every possible configuration is effectively impossible. Thus the difficulty of performing security evaluations also grows very rapidly with increasing complexity. The combination of additional (potential) weaknesses and a more difficult security analysis unavoidably results in insecure systems.
The fourth reason is that the more complex a system is, the harder it is to understand. There are all sorts of vulnerability points -- human-computer interface, system interactions -- that become much larger when you can't keep the entire system in your head.
The fifth (and final) reason is the difficulty of analysis. The more complex a system is, the harder it is to do this kind of analysis. Everything is more complicated: the specification, the design, the implementation, the use. And as we've seen again and again, everything is relevant to security analysis.
A more complex system loses on all fronts. It contains more weaknesses to start with, its modularity exacerbates those weaknesses, it's harder to test, it's harder to understand, and it's harder to analyze.
It gets worse: This increase in the number of security weaknesses interacts destructively with the weakest-link property of security: the security of the overall system is limited by the security of its weakest link. Any single weakness can destroy the security of the entire system.
Real systems show no signs of becoming less complex. In fact, they are becoming more complex faster and faster. Microsoft Windows is a poster child for this trend to complexity. Windows 3.1, released in 1992, had 3 million lines of code; Windows 95 has 15 million and Windows 98 has 18 million. The original Windows NT (also 1992) had 4 million lines of code; NT 4.0 (1996) has 16.5 million. In 1998, Windows NT 5.0 was estimated to have 20 million lines of code; by the time it was renamed Windows 2000 (in 1999) it had between 35 million and 60 million lines of code, depending on who you believe. (As points of comparison, Solaris has held pretty stable at about 7 to 8 million lines of code for the last few releases, and Linux, even with the addition of X Windows and Apache, is still under 5 million lines of code.)
The size of Windows 2000 is absolutely amazing, and it will have more security bugs than Windows NT 4.0 and Windows 98 combined. In its defense, Microsoft has claimed that it spent 500 people-years to make Windows 2000 reliable. I only reprint this number because it will serve to illustrate how inadequate 500 people-years is.
The networks of the future, necessarily more complex, will be less secure. The technology industry is driven by demand for features, for options, for speed. There are no standards for quality or security, and there is no liability for insecure software. Hence, there is no economic incentive to create high quality. Instead, there is an economic incentive to create the lowest quality the market will bear. And unless customers demand higher quality and better security, this will never change.
I see two alternatives. The first is to recognize that the digital world will be one of ever-expanding features and options, of ever-faster product releases, of ever-increasing complexity, and of ever-decreasing security. This is the world we have today, and we can decide to embrace it knowingly.
The other choice is to slow down, to simplify, and to try to add security. Customers won't demand this -- the issues are too complex for them to understand -- so a consumer advocacy group is required. I can easily imagine an FDA-like organization for the Internet, but it can take a decade to approve a new prescription drug for sale, so this solution might not be economically viable.
I repeat: complexity is the worst enemy of security. Secure systems should be cut to the bone and made as simple as possible. There is no substitute for simplicity.
Unfortunately, simplicity goes against everything our digital future stands for.
From: Shawn Hernan svh@cert.org
Subject: Full Disclosure
I was intrigued by your recent series of editorials in Crypto-Gram regarding full-disclosure, and especially, CERT. I am writing to respond to the article.
Some of your criticisms of CERT are valid, and I agree with them; but I wanted to point out a couple of things that you may not realize about our current practices.
When deciding what to publish and when, we use a variety of different criteria.
First, whatever we publish has to be *true* -- we go to great lengths to validate and verify everything we say in an advisory, and you can imagine some of the arguments that ensue over what is "true."
Second, as a rule of thumb, our advisories are generally about very serious problems. We have a formal metric that we use to attempt to put vulnerabilities on a linear scale of "severity" and we use that as a first-order estimate of the gravity of the problem, and use our experience as the final judge. Generally, the problems issued in advisories are in the 90th percentile of this scale (internally called the "threat metric").
Third, although it may have been true in the past, it has never been the case in my time here (about 4 years now) that our publication schedule was dependent on all (or even any) of the fixes being available. We certainly prefer to have fixes available at publication time, but if we discover that a vulnerability is being exploited we will publish regardless of the availability of any fixes or patches. My team (the vulnerability handling team) works very closely on a daily basis with the incident response team to understand if a vulnerability is being exploited.
Given all that, I am trying to find responsible, practical ways to publish more information about vulnerabilities in a variety of forms. We are a relatively small organization, and I'm not willing to sacrifice truth for expediency.
From: Ryan Russell ryan@securityfocus.com
Subject: Distributing Exploits
You're still not totally consistent in what you say:
>Third, I believe that it is irresponsible, and possibly >criminal, to distribute exploits.
You've already acknowledged that that's what it takes to get action.
>Reverse-engineering security systems, discovering >vulnerabilities, and writing research papers about them >benefits research; it makes us smarter at designing secure >systems. Distributing exploits just make us more vulnerable.
You acknowledge your behavior being inconsistent with your words, which is neither here nor there. It not only often takes an exploit, but it takes a press release sometimes. Thievco released an "exploit" to decode Netscape passwords a year and a half ago. Netscape did nothing. RST Corp. did the same, with a press release. That got Netscape's attention.
>For example, Mixter is a German hacker who wrote the >Tribal Flood Network tool used in some of the distributed >denial-of-service attacks. I believe he has a lot to answer >for. His attack tool served no good.
Not true. Were it not for him, we'd probably be looking at mystery tools that were being used that we didn't have the source for, and couldn't as easily analyze. Mixter has combated much FUD by showing us exactly the type of thing that can be used, so that the reporters couldn't run off and tell the public that the evil hackers have superweapons the security experts know nothing about.
>It enabled criminals and cost a lot of companies a lot of >money. Its existence makes networks less secure.
As you say, like any tool, it enables both good and bad guys. As you've pointed out, the security problem was already there, the tools just highlight it.
Let me speak to the subtext of your rant against Mixter. Some people think Mixter may deserve some punishment. I don't, but I can see some of the logic. Really, I think if anyone deserves punishment, it's the guys who used the tool.
Did Mixter and even the attackers actually do anything in the spirit of full disclosure? Yes.
We've been complaining for years about the spoofing problem, and expecting ISPs to do filtering. Nothing has happened. Mixter put out his tool. Some meetings to discuss DDoS happened. No actual change to behavior, but there was some amount of advanced planning, which was good preparation. Finally, some person (yes, criminal) put their neck on the line and actually used them. They didn't take down the security sites to make them look bad. They didn't go after the government. They went after e-commerce, which I have to assume was designed for maximum reaction.
I think we'll get some action now.
From: Brian Bartholomew bb@wv.com
Subject: Publishing exploits
> Second, I believe in giving the vendor advance notice. CERT took > this to an extreme, sometimes giving the vendor years to fix the > problem. I'd like to see the researcher tell the vendor that he > will publish the vulnerability in a month, or three weeks (no fair > giving the vendor just seven days to fix the problem). Hopefully > the vulnerability announcement can occur at the same time as the > patch announcement. This benefits everybody.
Whatever CERT's motivations were, they had the effect of increasing user trust (because a new sheriff is in town) while decreasing trustability (because they sat on vulnerabilities users handed off to them). This is backwards, in two places.
I prefer the following approach: announce existence of vulnerability and promise a kiddy script in a month; wait a month for vendor to react; publish kiddy script.
> Publishing vulnerabilities in critical systems that cannot be easily > fixed and whose exploitation will cause serious harm (e.g., the air > traffic control system) is bad.
Publishing is *very important* in these cases so the stakeholders know to reduce their trust in these systems. If air traffic control is vulnerable, tell me so I can stop taking airplanes!
A non-life-safety version of this problem was the publishing of a script that gave an existing process root privileges using the memory debugger abilities of the console monitor ("L1-A") of a Sun. This debugger could be disabled, but nobody did because it disabled the software reset button. This reported vulnerability allowed users to adjust their trust of the security of root sharply downward, corresponding more closely to the actual security of it in practice.
> Third, I believe that it is irresponsible, and possibly criminal, to > distribute exploits.
This is gun control: "Don't punish murder, ban the gun instead! Exploits are an evil instrumentality! Exploits help a good boy go bad!" The right answer is: Humans are held responsible for their behavior. Guns, bricks, and exploits are just tools.
From: Greg Guerin glguerin@amug.org
Subject: publicity attack loops?
I have to admit that I was chuckling all the way through the
Fernandes/Cryptonym letter in the Feb 2000 Crypto-Gram. Especially when at
the end he wraps himself in the mantle of professional integrity. I've
already written two essays on the Fernandes discovery and his downloadable
"repair" ZIP:
http://amug.org/~glguerin/opinion/win-nsa-key.html
http://amug.org/~glguerin/opinion/crypto-repair-kit.html
Though neither one is about Fernandes's professional integrity, per se, they do make a number of points about specific practices. To summarize the points (see the essays for the full explanation):
Point 6 is only a little important because it means the EXE's must be trusted as given. But there was only one source file anyway, so you're already trusting the other EXE completely. And both DLL's must be trusted completely. Risk-wise, 75% blind trust is virtually identical to 100% blind trust, so it's not all that useful a distinction. It's like choosing whether to kill something 3 times over or 4 times -- correctly killing it once suffices.
Note that at no point does "professional integrity" come into this, only "professional practice". I'm not disputing INTENT (integrity), I'm only describing OUTCOME (practice). Spotless integrity and intent cannot long survive avoidable errors in practice. By observing practices an observer might infer skill, integrity, or both, or neither. Those judgements, and the trustworthiness criteria underlying them, are left completely to the particular observer. All I can say is what I would infer from my observations, and why. You should draw your own conclusions, since my criteria for trustworthiness may differ from yours. But you should also invest in understanding why you came to those conclusions -- flaws in the process can lead you astray.
From: "Rolf Oppliger" rolf.oppliger@esecurity.ch
Subject: Distributed Denial-of-Service Attacks
First of all, I'd like to congratulate you for your description and analysis of distributed denial-of-service (DDoS) attacks in the February issue of your Crypto-Gram newsletter. I fully agree with most of your statements, including your pessimistic view that all existing approaches to address the problem are unsatisfactory in one way or another.
In your article, however, you also argue that "in the long term, out-of-band signaling is the only way to deal with many of the vulnerabilities of the Internet, DDS attacks among them." I don't agree with this statement. Any out-of-band signaling channel can also be subjected to DoS and DDoS attacks. I believe that the reason why telephone networks are not subjected to large-scale DoS and DDoS attacks is due to the fact that they address charging and billing, rather than their use of out-of-band signaling (out-of-band signaling has many advantages in other areas). Trying to establish a huge quantity of connections in a telephone network is simply too expensive ... I think that the lesson learnt from telephone networks is that packet-based charging and billing -- combined with adequate security mechanisms -- may be a viable solution to protect against large-scale DoS and DDoS attacks on the Internet (rather than out-of-band signaling). However, packet-based charging and billing also has many disadvantages, including, for example, a huge administration overhead. Consequently, I guess that packet-based charging and billing will not be applied on the Internet, and that "intelligent" packet-filtering performed by ISPs will be the major weapon to protect against large-scale DoS and DDoS attacks in the future.
From: Ethan Benatan benatan@duq.edu
Subject: Defending Against DOS Attacks: Draining the Swamp
If you'll pardon the musings of a biologist, I'd like to comment on your swamp analogy. I know you never stated so but it bears pointing out that swamps are not "bad" in any defensible sense, nor is draining them "good," even though doing so may have one immediate desirable consequence. I am sure that in your own field you can think of many examples where a cure, though effective, may have been worse than the disease. The RISK here is forgetting that in any complex system change comes at some cost; the more complex (or less well understood) the system, the harder it is to predict the cost. I think this applies to the Internet. It certainly applies to the natural world, in spades. I will not bore you with examples.
From: pclites@cdsfulfillment.com
Subject: deCCS
In the February 2000 Crypto-Gram, you wrote: "An important point is that DVDs can be copied and pirated without using deCSS or any other decryption, which certainly makes the original claim of 'prevents piracy' look either astoundingly ignorant or brazenly deceptive."
There is a sense in which the "prevents piracy" claim makes sense. deCSS makes it easy to copy the data on a DVD not just onto another DVD, but into another format, one which is easier to copy & transmit. In that sense, one could characterize it as making piracy easier. Kind of like the rationale behind the distinction between printed & electronic versions of source code in the original crypto export restrictions; but for a consumer data product, I think it's a more meaningful distinction. I would have to characterize the court's ruling as a correct application of a bad law, in what may turn out to be a watershed case.
From: "Bryan Alexander" xande1@bellsouth.net
Subject: Secure Linux
> The NSA has contracted with Secure Computing Corp. for > a secure version of Linux. Personally, I don't know if > the Linux license allows the NSA to make a secure version > of the operating system if they are not going to freely > distribute the results.
Actually the GPL (Gnu Public License, which covers almost all parts of Linux) does allow this. There is no language in the license that requires that you redistribute anything based on the GPL, only what you are required to do *if* you redistribute a work based on the GPL. In addition, the GNU Project has said specifically that the license is not intended to prevent people from creating (without being forced to distribute) their own modified versions of GPLed software for their own use. The text of the GPL is located at: http://www.gnu.org/copyleft/gpl.html.
A statement about being forced to distribute modified versions of software being an "unacceptable restriction" can be found at http://www.gnu.org/philosophy/apsl.html under the heading "Disrespect for Privacy." This is part of a discussion of the "fatal flaws" in the Apple APSL license. (I can't find the original source for the comment about this as it relates to the GPL right now, sorry.)
CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security.
To subscribe, visit http://www.counterpane.com/crypto-gram.html or send a blank message to crypto-gram-subscribe@chaparraltree.com. To unsubscribe, visit http://www.counterpane.com/unsubform.html. Back issues are available on http://www.counterpane.com.
Please feel free to forward CRYPTO-GRAM to colleagues and friends who will find it valuable. Permission is granted to reprint CRYPTO-GRAM, as long as it is reprinted in its entirety.
CRYPTO-GRAM is written by Bruce Schneier. Schneier is president of Counterpane Systems, the author of "Applied Cryptography," and an inventor of the Blowfish, Twofish, and Yarrow algorithms. He served on the board of the International Association for Cryptologic Research, EPIC, and VTW. He is a frequent writer and lecturer on cryptography.
Counterpane Systems is a six-person consulting firm specializing in cryptography and computer security. Counterpane provides expert consulting in: design and analysis, implementation and testing, threat modeling, product research and forecasting, classes and training, intellectual property, and export consulting. Contracts range from short-term design evaluations and expert opinions to multi-year development efforts.
Copyright (©) 2000 by Counterpane Internet Security, Inc.
