On Wed, 12 Jan 2000, Jeff Younker wrote:
[Sheesh, I wanna play too!]
> This implies that speed is a poor criterion for determining the quality of
> cryptographic code.
Indeed it is. Unfortunately, with patent encumbered code where the
patent holder won't allow you to code independent products without
pricing you out of the market, there's not much to be done in the way of
determining the quality of said code. Now you can assume that the code
is perfect, or you can assume it's evil, in a security context, key
security code that has no means of independent verification automatically
gets villified in my book.
> hardware platform the code is running on. I suspect that this expertise is
> what you are paying for when you buy the BSAFE libraries. ]
You suspect it's that, Bennett suspects that it isn't. The point still
stands that BSAFE doesn't compete on technical merit, it "competes" on
the legal merit of an enforced monopoly. Now, it's been quite a number
of years since I even loaded BSAFE (but yes, I purchased a copy specificly to
try to get around the legal hurdles - it wasn't worth it - there was still a
*massive* per-server license fee for anything I developed internally
for internal use.) so I don't recall if the toolkit is staticly or dynamicly
linked, but if it's static, and if the source isn't available, how can anyone
verify such suspicions?
In this thread I've seen some pretty rash things bandied about, and I'd
like to try to address a couple more of them.
1. If more open toolkits were available, the world would be a better
place, because privacy protection would be easily affordable, and not
some $300/server alternative for using code I wrote myself (when the
server costs $800, $300 to use an algorithm from a toolkit I'm forced to
use because of legality isn't that great in my view of things.) SSLeay
was a good independent implementation, it had the benifit of peer review,
but it wasn't possible to use it for a home-grown company-internal Web
server without spending more than a competing commercial closed-source
product.
2. Competing implementations raise the bar. Let's suppose for a minute
(and I'm not suggesting this is anything other than pure fiction) that
NSA got RSA to agree to trapdoor a BSAFE algorithm such as DES (and I've
read papers that seem to say it's possible to trapdoor DES without
breaking it, but my mathematical background isn't good enough to assert
or deny such supposition). Anyone producing sofware using DES that used
the particular implementation in question would be immediately trojaned.
Without any means of verifying that the code is indeed safe. Now,
fortunately the DES algorithm isn't patent encumbered, so it's rather
easy to compare the source of several implementations and even code new
ones freely (ignoring the distribution issues some governements impose.)
The same won't be true of RSA until later this year. But if we take the
supposition that this happened, and we looked at the fact that (in our
theoretical world) everyone writing DES software had to use BSAFE, we'd
have a pretty large house of cards upon which all our privacy was built.
I won't get into the intellectual property arguments because I don't
think they're as directly germain to INFOSEC, but from a security
standpoint, the fact that such encumberances are exclusionary to *differing
implementations* bothers me *significantly*.
I really wish someone could explain to me the economic or business arguments
that make RSA's pricing scheme make sense: If I buy their code, or
the code of a vendor in bed with them, it's cheaper than if I write my own
and just pay to use their algorithm! Surely there's nothing other than
railroading the use of a single implementation that makes that play out well,
and surely we *all* agree that in security having a single implementation is a
potential vulnerability.
It doesn't matter to me if RSA hires all the best crypto rocket
scientists on the planet, and I can't code my way out of a wet paper
bag. Stopping me from being able to use an implementation where I've
written the code, checked the libraries, verified the compiler, and
everything else that falls under due dilligence is bad. If my platform
of choise isn't supported by BSAFE or a commercial product, I'm forced to
pay more than replacing the entire platform is worth to code up my own
implmentation.
As a corporate user, I'm perfectly prepared to pay a _reasonable_
ammount of money to a patent holder to roll my own software that uses a
patented algorithm. RSA's position on their intellectual property has
however been what I consider unreasonable. Because of that stance, I'll
be fielding things that use Blowfish and D-H wherever possible. In
September when RSA's patent runs out, I'll be moving to a free library
for anything that uses RSA.
At this point, I don't care if BSAFE _is_ well-written and secure. I
care that a security company puts its own interests before those of its
customers in a predatory and exploitative way that is detrimental to
security. I wouldn't choose a firewall vendor that forced me to rely on a
proprietary authentication protocol and charged me $200/client to write my own
clients, and I won't choose a crypto provider that attempts the same. Nor will
I be getting another copy of BSAFE, or even certificates from their progeny if
I can at all help it.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
