Vin McLellan <me> earlier wrote:
>> In BSAFE Crypto-C, the core BSAFE product, we are talking about
>> a toolkit of crypto implementation code which has been installed in
>> nearly a half *billion* machines -- in thousands of different products,
>> from some 600 different Original Equipment Manufacturers (OEMs)
>> -- over the past 17 years.
To which Eric Rescorla <[EMAIL PROTECTED]>, a former cryptographic
engineer at Spyrus -- a one-time RSA partner, now more of a competitor --
replied with some asperity.
[Spyrus <www.spyrus.com> has agreement with RSA Security which
allows it to repackage and resell RSA's BSAFE tool kit. Mr. Rescorla -- the
primary author of Spyrus' SecureWeb tool kit -- is thus one of the few
non-RSA engineers who has tried to expand the BSAFE library from the inside.]
>Hmmm. ITSM that most of these installs are in Netscape and/or
>Internet Explorer. It has long been my impression that the Netscape
>and MS engineers only used BSAFE because they were absolutely forced
>to. Moreover, it's significant that Netscape (at least) made very
>significant modifications to BSAFE in order to incorporate it into their
>products. Perhaps Tom Weinstein is around and can explain why.
I'm sure the majority of these installs are browsers. (Although
there *are* well over 600 other OEMs which install RSA's BSAFE cryptographic
code in multiple products.)
With respect, however, I think this babble about Netscape and MS
being "absolutely forced" to use BSAFE code is silly and naive. It's part
of a myth that has been manufactured by people who can not accept that
proprietary crypto libraries have been, and are (even now!), often the
preferred choice of OEMs -- for good and sensible reasons.
It has long been *my* impression that Netscape and MS engineers used
BSAFE Crypto-C because it was available, well-tested, stable, easy to use,
widely-trusted and portable -- and supported by a vendor willing to stand
behind its product, and guarrantee its future enhancements.
The idea that Microsoft was "forced" to use RSA implementation code
is utterly absurd. Microsoft, as you probably know, has both an RSA patent
license (which means they could code their own RSApkc, if they wished) and a
BSAFE license. MS *choose* to use the BSAFE ciphersuites. (In doing so,
IMNSHO, MS engineers locked in RSA crypto as the foundation of modern
E-commerce.)
If any of the engineers working on these products at Netscape or MS
had the hubris to think they were going to whip up their own crypto
primitives or drag in some freeware library -- which I frankly doubt, since
they were pros -- I presume their superiors soon put them straight!
I don't know anything about whatever Kipp Hickman of Netscape did
with the BSAFE code he used for SSL v.1 and v.2 in the fall of 1974.
In a recent discussion on another mailing list, however, (former
Netscape cryptographer) Tom Weinstein wrote that he felt the choice of
RSApkc and BSAFE, per se, for SSL was a no-brainer:
]>BSAFE was existing code that could just be used. In a startup, it's very
]>important that you not waste time reinventing wheels that you can buy off
]>the shelf.
As for Microsoft's subsequent choice to use BSAFE implementation
code in the Internet Explorer, the IIS webserver, NT, and now Windows 2000
-- it's hard to fault the choice, even in hindsight. MS has had deal with
multiple design flaws and crypto implementation problems <sigh>, but AFAIK
there has never been a problem with the BSAFE modules!
As I noted earlier:
>> The computer and communications industry abounds with CTOs who
>> freely testify that BSAFE is almost unique in their experience in that it
>> has repeatedly compiled bug-free, even in multi-platform
>> implementations. (Corrections, comments, or contrary warstories
>> welcome;-)
To which Eric responded:
>I would agree that BSAFE portability and stability is excellent.
>The code organization and coding style leaves a lot to be desired.
>I and a number of other programmers who have had to add new algorithms
>to BSAFE were less than happy.
>
>Moreover, TIPEM, for years RSA's other major product, is widely
>regarded as an abomination. I don't know anyone outside RSA who has
>a good word for it. Terisa used it in our initial S-HTTP implementation
>and we were ultimately very very sorry.
TIPEM (Toolkit for Interoperable Privacy Enhanced Mail), written in
'90 and '91, was so far ahead of the market it had dinasour fossils embedded
in its code (as well as the predictable arrows in its backside.) Surely it
is bizarre, not to say unfair, to judge a ten year-old crypto product by the
standard of contemporary cryptographic architecture in 2,000.
While modern crypto is typically offered in layered architectures
(think of CDSA), RSA's old TIPEM was, by contrast, fairly monolythic. It
tried to do everything and fell a little short of perfect -- but you might
as well curse CPM or DOS for not having Windows95 plug 'n play features.
(Couldn't we at least start with S/MIME? ;-)
BSAFE Crypto-C, by constrast, is still the dominant commercial
crypto toolkit in the US (and if the new BXA export regs ratify the draft
text available, perhaps soon a major factor in the international market as
well!) BSAFE is obviously a valid target for any critique or comparisons,
for all of its legacy.
BSAFE is object-oriented code written in a non-object-oriented
language: C. This make for something of a sylistic mess, but C++ wasn't an
option for an OEM product even a decade ago. BSAFE is also an evolved
product. It would surely look very different if it were to be designed or
re-engineered today. (Since the BSAFE API has been published, I presume we
will soon see BSAFE-compatable toolkits, which *will* incorporate modern
cryptographic architectures.)
[Rumor has it that RSA's programmers have also been <ahem> less than
generous in commenting on the BSAFE source. I suspect, Eric, that few
envied you the job of pushing another ciphersuite into the BSAFE matrix for
Spyrus. I surely would not;-]
I'm not trying to put down other crypto libraries; they have their
strengths, BSAFE has its own. If my initial message was pitched a little
high, it was only because I was responding to a slur on the professionalism
of RSA's crypto engineers, and a baseless allegation that BSAFE code was
putting its users at risk.
I readily conceed that there are many other fine crypto libraries,
several of them open source and free. There may even be some which legally
offer RSApkc as well as Rivest's symmetric algorithms (RC2, RC4, RC5, and
RC6). [RSADSI raided one to license Eric Young's DES implementation code
for BSAFE years ago -- long before it recruited Young (the eay of SSLeay) as
CTO for RSA-Australia.]
I was, of course, wrong to drop SET into a list of RSA
achievements, as Mr. Rescorla pointed out. I apologize. RSADSI coded one
of several SET implementations. Unfortunately, SET seems to have been
another vast and expensive undertaking that went -- at least in hindsight --
slightly astray. The elegance and simplicity of Netscape's SSL won the day.
Suerte,
_Vin
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
