Bruce Schneier (expert security) memiliki tanggapan ttg Open Source dan
security... perhatikan komentarnya ttg MS produk...
Oh iya Bruce ini yang menemukan Blowfish.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Open Source and Security
As a cryptography and computer security expert, I have never understood
the current fuss about the open source software movement. In the
cryptography world, we consider open source necessary for good security;
we have for decades. Public security is always more secure than
proprietary security. It's true for cryptographic algorithms, security
protocols, and security source code. For us, open source isn't just a
business model; it's smart engineering practice.
Open Source Cryptography
Cryptography has been espousing open source ideals for decades, although
we call it "using public algorithms and protocols." The idea is simple:
cryptography is hard to do right, and the only way to know if something
was done right is to be able to examine it.
This is vital in cryptography, because security has nothing to do with
functionality. You can have two algorithms, one secure and the other
insecure, and they both can work perfectly. They can encrypt and decrypt,
they can be efficient and have a pretty user interface, they can never
crash. The only way to tell good cryptography from bad cryptography is to
have it examined.
Even worse, it doesn't do any good to have a bunch of random people
examine the code; the only way to tell good cryptography from bad
cryptography is to have it examined by experts. Analyzing cryptography is
hard, and there are very few people in the world who can do it
competently. Before an algorithm can really be considered secure, it needs
to be examined by many experts over the course of years.
This argues very strongly for open source cryptographic algorithms. Since
the only way to have any confidence in an algorithm's security is to have
experts examine it, and the only way they will spend the time necessary to
adequately examine it is to allow them to publish research papers about
it, the algorithm has to be public. A proprietary algorithm, no matter who
designed it and who was paid under NDA to evaluate it, is much riskier
than a public algorithm.
The counter-argument you sometimes hear is that secret cryptography is
stronger because it is secret, and public algorithms are riskier because
they are public. This sounds plausible, until you think about it for a
minute. Public algorithms are designed to be secure even though they are
public; that's how they're made. So there's no risk in making them public.
If an algorithm is only secure if it remains secret, then it will only be
secure until someone reverse-engineers and publishes the algorithms. A
variety of secret digital cellular telephone algorithms have been "outed"
and promptly broken, illustrating the futility of that argument.
Instead of using public algorithms, the U.S. digital cellular companies
decided to create their own proprietary cryptography. Over the past few
years, different algorithms have been made public. (No, the cell phone
industry didn't want them made public. What generally happens is that a
cryptographer receives a confidential specification in a plain brown
wrapper.) And once they have been made public, they have been broken. Now
the U.S. cellular industry is considering public algorithms to replace
their broken proprietary ones.
On the other hand, the popular e-mail encryption program PGP has always
used public algorithms. And none of those algorithms has ever been broken.
The same is true for the various Internet cryptographic protocols: SSL,
S/MIME, IPSec, SSH, and so on.
The Best Evaluation Money Can't Buy
Right now the U.S. government is choosing an encryption algorithm to
replace DES, called AES (the Advanced Encryption Standard). There are five
contenders for the standard, and before the final one is chosen the
world's best cryptographers will spend thousands of hours evaluating them.
No company, no matter how rich, can afford that kind of evaluation. And
since AES is free for all uses, there's no reason for a company to even
bother creating its own standard. Open cryptography is not only better --
it's cheaper, too.
The same reasoning that leads smart companies to use published
cryptography also leads them to use published security protocols: anyone
who creates his own security protocol is either a genius or a fool. Since
there are more of the latter than the former, using published protocols is
just smarter.
Consider IPSec, the Internet IP security protocol. Beginning in 1992, it
was designed in the open by committee and was the subject of considerable
public scrutiny from the start. Everyone knew it was an important protocol
and people spent a lot of effort trying to get it right. Security
technologies were proposed, broken, and then modified. Versions were
codified and analyzed. The first draft of the standard was published in
1995. Different aspects of IPSec were debated on security merits and on
performance, ease of implementation, upgradability, and use.
In November 1998, the committee published a slew of RFCs -- one in a
series of steps to make IPSec an Internet standard. And it is still being
studied. Cryptographers at the Naval Research Laboratory recently
discovered a minor implementation flaw. The work continues, in public, by
anyone and everyone who is interested. The result, based on years of
public analysis, is a strong protocol that is trusted by many.
On the other hand, Microsoft developed its own Point-to-Point Tunneling
Protocol (PPTP) to do much the same thing. They invented their own
authentication protocol, their own hash functions, and their own
key-generation algorithm. Every one of these items was badly flawed. They
used a known encryption algorithm, but they used it in such a way as to
negate its security. They made implementation mistakes that weakened the
system even further. But since they did all this work internally, no one
knew that PPTP was weak.
Microsoft fielded PPTP in Windows NT and 95, and used it in their virtual
private network (VPN) products. Eventually they published their protocols,
and in the summer of 1998, the company I work for, Counterpane, published
a paper describing the flaws we found. Once again, public scrutiny paid
off. Microsoft quickly posted a series of fixes, which we evaluated this
summer and found improved, but still flawed.
Like algorithms, the only way to tell a good security protocol from a
broken one is to have experts evaluate it. So if you need to use a
security protocol, you'd be much smarter taking one that has already been
evaluated. You can create your own, but what are the odds of it being as
secure as one that has been evaluated over the past several years by
experts?
Securing Your Code
The exact same reasoning leads any smart security engineer to demand open
source code for anything related to security. Let's review: Security has
nothing to do with functionality. Therefore, no amount of beta testing can
ever uncover a security flaw. The only way to find security flaws in a
piece of code -- such as in a cryptographic algorithm or security protocol
-- is to evaluate it. This is true for all code, whether it is open source
or proprietary. And you can't just have anyone evaluate the code, you need
experts in security software evaluating the code. You need them evaluating
it multiple times and from different angles, over the course of years.
It's possible to hire this kind of expertise, but it is much cheaper and
more effective to let the community at large do this. And the best way to
make that happen is to publish the source code.
But then if you want your code to truly be secure, you'll need to do more
than just publish it under an open source license. There are two obvious
caveats you should keep in mind.
First, simply publishing the code does not automatically mean that people
will examine it for security flaws. Security researchers are fickle and
busy people. They do not have the time to examine every piece of source
code that is published. So while opening up source code is a good thing,
it is not a guarantee of security. I could name a dozen open source
security libraries that no one has ever heard of, and no one has ever
evaluated. On the other hand, the security code in Linux has been looked
at by a lot of very good security engineers.
Second, you need to be sure that security problems are fixed promptly when
found. People will find security flaws in open source security code. This
is a good thing. There's no reason to believe that open source code is, at
the time of its writing, more secure than proprietary code. The point of
making it open source is so that many, many people look at the code for
security flaws and find them. Quickly. These then have to be fixed. So a
two year-old piece of open source code is likely to have far fewer
security flaws than proprietary code, simply because so many of them have
been found and fixed over that time. Security flaws will also be
discovered in proprietary code, but at a much slower rate.
Comparing the security of Linux with that of Microsoft Windows is not very
instructive. Microsoft has done such a terrible job with security that it
is not really a fair comparison. But comparing Linux with Solaris, for
example, is more instructive. People are finding security problems with
Linux faster and they are being fixed more quickly. The result is an
operating system that, even though it has only been out a few years, is
much more robust than Solaris was at the same age.
Secure PR
One of the great benefits of the open source movement is the
positive-feedback effect of publicity. Walk into any computer superstore
these days, and you'll see an entire shelf of Linux-based products. People
buy them because Linux's appeal is no longer limited to geeks; it's a
useful tool for certain applications. The same feedback loop works in
security: public algorithms and protocols gain credibility because people
know them and use them, and then they become the current buzzword.
Marketing people call this mindshare. It's not a perfect model, but hey,
it's better than the alternative.
______________________________________________________________
>From [EMAIL PROTECTED] to UNDIP List
Milis Archive: http://messages.to/archives or http://messages.to/archives2
DIPONEGORO UNIVERSITY MailingList http://www.undip.ac.id
