> Remo Inverardi <[EMAIL PROTECTED]> queried the List:
> >
> > After reading about the rsaref library, several questions came to
> > mind:
> >
> > a) Is the rsaref library the same as Bsafe? Or is it a part of
> > Bsafe?
No and No. RSAref has never even shared a common code base with
BSAFE SSL-C, nor with BSAFE Crypto-C -- nor with any of the seven other RSA
BSAFE crypto toolkits.
Michael Sierchio <[EMAIL PROTECTED]> replied:
>The RSAREF library, which is no longer supported or made available
>by RSA Security (nee RSA Data Security), was released under a
>non-commercial license with instructions to contact RSA for
>a commercial RSAREF license if you had that sort of application
>in mind. No such license agreement ever actually existed, and
>if you contacted RSA requesting such a license agreement, they
>would try to get you to purchase a BSAFE (now Crypto-C) license --
>at about $100,000 + 4% of royalties.
(I think something like a $60k royalty prepayment, on a 2 percent
royalty, is far more common for Crypto-C -- but BSAFE OEM licenses vary
considerably in price and payment schemes.)
RSA uses what I call a "piece of the pie" pricing strategy. The
price of an OEM license for BSAFE code varies according to how important
their RSApkc crypto is to the service or product that it is to be
implemented and sold in: i.e., how much of the final product *is* RSApkc.
RSA uses several categories in this analysis -- and within each
category, the cost and payment scheme options varies according to a
proportional inverse scale: the relative size of the upfront cash, the
"pre-payment," raises or lowers the percentage used to set the per-product
royalty claim. Big prepayment; tiny royalties.
(There are also special deals, like those for OEM startups, in
which royalty prepayments are not demanded. Enterprise-oriented BSAFE
licenses -- what a corporation which is integrating crypto into its
homebrew apps needs -- are also priced differently.)
This forum isn't the most objective source of information on RSA's
pricing or services -- and neither Mr. Sierchio nor I is a particularly
unbiased source -- so direct contact with RSA is probably advisable if you
are seriously exploring using RSA's crypto in a commercial environment. It
usually isn't as difficult as Mr. Inverardi reports; RSA is not adverse to
taking your money.
(For some, it may not even be as traumatic as readers might expect
from the out-of-context price-quotes that regularly float across this List
on a tide of venomous comment. While I hesitate to suggest it here, there
may be *some* reason RSA continues to sell BSAFE licenses, in the US and
abroad, at the rate of something like a deal a day;-)
RSAref itself is something of a relic. It may give you a sense of
its antiquity to point out that RSA hoped that RSAref would introduce
academic and corporate researchers to the concept of Message
Digests (Rivest's MD4 and MD5), digital sigs, and prep them for cert-based
Privacy Enhanced Mail (PEM).
RSAref was originally developed in the early 1990s as a
non-commercial reference implementation for public key crypto. It was
something of a brilliant hack. As I noted, RSAref was not allowed to draw
upon the more trusted and robust BSAFE (Crypto-C) codebase that RSADSI had
been refining since the mid-'80s -- but then, RSAref was never expected to
carry the weight of a production environment, either.
RSAref was distributed under pretty onerous license restrictions,
notably a requirement that the user could only access RSAref's underlying
crypto through the specific and limited APIs that RSAref made
available. (Since SSL had not yet been developed, it is perhaps not
surprising that those APIs were not designed to permit SSL support.)
Needless to say, RSAref quickly escaped the market niche RSA hoped
and expected to confine it to. Perhaps, in hindsight, that was a good
thing, since RSAref was unexpectedly used to justify, within the US, the
widespread use of -- PGP, SSH, and SSLeay (predecessor to OpenSSL), and
several other RSApkc-based freeware apps.
Perhaps inadvertently, RSA's mass-market oriented marketing
strategy brushed aside many of the hands-on crypto developers and garage
shops in its concentration on persuading OEMs to crypto-enable their
products or services with BSAFE code. Meanwhile, RSAref gave a generation
or two of American developers a free RSA crypto suite to play with and study.
(For current context: There are over a half-billion BSAFE
implementations in the field; somewhere between a third and a half of them
now in SSL-enabled browsers. BSAFE is licensed to about 1,000 OEMs, and is
integrated into thousands of distinct products. RSA's OEM focus was not,
sadly, a strategy designed to wins the hearts and minds of this List, but
it did result in -- among other things -- hundred dollar SSL-enabled
webservers, and an astonishingly broad dissemination of the core RSApkc
technology.)
Despite Mr. Sierchio's insistence that it is not true, there
actually were (and are today, paid up to date) commercial RSAref licenses.
RSA chartered Consensus to sell and manage commercial RSAref licenses
because it was afraid of getting buried in the paperwork. C2, among others,
had one when it initially offered brought its SSLeay-enabled Stronghold to
market. Like the RSAref toolkit in the real world, however, those
commercial BSAFE licenses quickly escaped the restrictions (e.g.,
connection count limitations) written into them.
For good or ill, ingenuity and technical creativity made mincemeat
of the limitations expected to channel "commercial" RSAref products and
keep them from challenging the BSAFE-licensed OEMs, where RSA made its real
money and hoped to change the world. After C2 managed to challenge RSA's
big OEM customers with its clever use of a (commercial) RSAref-enabled
SSLeay, RSADSI seemed to decide that RSAref v.2 was not something it could
effectively manage or control given its current license. RSA and Consensus
also had a falling out. (RSA was not satisfied with the depth of Consensus'
due diligence inquiry on prospective RSAref customers and feared poor
implementations, enabled by RSAref, would stain its reputation and
prospects in the OEM market.) The result was predictable: RSA cancelled
the Concensus deal and turned its back on RSAref.
If RSA couldn't withdraw RSAref from circulation, they didn't have
to support it, or upgrade it, or maintain it, or futher distribute it, or
extend it with commercial licenses. RSADSI dropped RSAref, and began to
highlight the malleable language in the RSAref license which forbade
commercial use without a further license, and let time take its toll.
Subsequently, RSADSI made side deals which "legitimized" large
rogue RSAref user communities (PGP, SSH) in which freeware developers had
become the dominant suppliers, even in the US -- but those agreements were
never extended to cover the RSAref/SSL (SSLeay) niche, where BSAFE-enabled
Netscape and MS clients still define the Web.
Instead, RSA approached the SSLeay market another way.
A couple of years ago, RSA recruited Eric A. Young (eay, the
primary author of SSLeay) and Tim Hudson (SSLapps) to be senior executives
at RSA Australia. Skirting the US export control laws, RSA Australia then
brought out BSAFE SSL-C -- a commercialized, fully-supported, and enhanced
version of SSLeay -- to challenge the non-American commercial SSL vendors
(Baltimore, Entrust, etc.) outside the States... and to offer a
commercially-supported option to US corporate developers (many of whom
still come of age with SSLeay and OpenSSL;-)
> > b) Why is it impossible to order the Bsafe library from Switzerland?
> > I tried several times (also on the Australian RSA Site which seems
> > to redirect to the US Site) but didn't even get an answer.
It is downright easy to get free BSAFE SSL-C, S/MIME, and Crypto-J
toolkits from RSA for evaluation purposes -- and the process plugs you into
the RSA sales database because it (lightly) qualifies the person who makes
the request as a legit industry professional. The URL for this is:
http://support.rsa.com/corp/rtm/
Direct contact shouldn't be a problem either. (Although I can see
why an address like <your.toilet.ch> might not be immediately pulled to the
top of the call ist;-) OEM or developers can request a call from RSA's
sales staff at: http://support.rsa.com/corp/survey/ .
Mr. Sierchio commented:
>Uh, sounds like the RSA I know and love. In any case, RSAREF is
>available in the Conferatio Helvetica. Note also that recently discovered
>security flaws have been fixed via patches (I use FreeBSD).
>
>rsaref20.1996.tar.Z is available at any of these sites:
>
> ftp://ftp.deva.net/pub/sources/crypto/
> ftp://ftp.kddlabs.co.jp/.7/inet/caida/bmwt/
> ftp://ftp.zedz.net/pub/crypto/crypto/LIBS/rsa/
> ftp://ftp.hacktic.nl/pub/crypto/crypto/LIBS/rsa/
> ftp://ftp.demon.net/pub/mirrors/crypto/replay/crypto/LIBS/rsa/
> ftp://ftp.funet.fi/pub/mirrors/utopia.hacktic.nl/crypto/LIBS/rsa/
> ftp://ftp.fu-berlin.de/unix/security/replay-mirror/crypto/LIBS/rsa/
>
>and the patches are available here:
>
> http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/security/rsaref/patches/
(The 1999 patch to block a potential buffer overrun in RSAref is
actually the first time RSA has authorized any update or change in the
freeware v.2 RSAref code in many years. Security concerns won out over
marketing policy.)
> > c) What is the advantage of using the Bsafe library? Are any of the
> > algorithms better than those of OpenSSL? Is there anything more
> > in it?
Mr. Sierchio:
>None, AFAIK. If you have USD 100,000 burning a hole in your pocket,
>let's talk -- we could put it to better use. Use OpenSSL.
Opinions might vary here;-) It seems to me that a honest request
from a newbie deserves a more complete answer, with both sides cited.
OpenSSL is the product of several very talented people. Much of
the OpenSSL codebase (135,617 lines of code as of SSLeay 0.9, and probably
most of the 32,000 lines of additional code introduced in '89 in
OpenSSL-0.9.1c) is the workproduct of Eric Young -- now the lead developer
for RSA's BSAFE SSL-C.
Even Mr. Sierchio would probably concede that eay's BSAFE SSL-C is
unlikely to be much inferior to OpenSSL;-) Some like it better. YMMV.
Over the past 23 months, Eric, Tim, and their 20-man FT
engineering and QA team at RSA Australia have done a lot additional work to
optimize the SSL-C code for various embedded systems (where SSLeay was
never expected to go;-) and to tune it for stability and performance on the
major OS and hardware platforms.
Lines of code is not a particularly good measure of functionality,
but it is perhaps worth noting that BSAFE SSL-C was launched with some 20
percent more code than OpenSSL (9.1c) -- enhancements the architect of
SSLeay thought useful and necessary. Subsequent development work at
RSA's Brisbane lab has continued to expand the size of SSL-C by about 10
percent per year, in a drive toward what Eric and Tim call <roll of drums>
"the complete product."
I'll let the marketing guys -- and/or those on the List more
technical than I -- argue about the value of those enhancements in general,
and in specific environments, and how they stack up against the
evolutionary growth of OpenSSL in its creative open source
community. Given the code added on each side since the '98 fork in the
code base, however, it seems presumptuous and naive for anyone to declare
that there is no difference between OpenSSL and BSAFE SSL-C today.
Even if Mr. S is right -- even if the technical merit of OpenSSL
and BSAFE SSL-C should be considered roughly equal -- there is also be a
potent "business case" that may convince many corporate customers to buy
BSAFE.
RSA is the dominant supplier in two of its three markets (crypto
toolkits and two-factor authentication tokens) and third or fourth in the
other (PKI software.) Unlike virtually any other large commercial infosec
vendor, at least in the US, RSA both makes money and supports a huge R&D
and development effort. In both basic and applied crypto, MIT prof Ron
Rivest and RSA Labs have paced the state of the art for twenty years.
For some -- say, the CEO, CIO, or CTO of a public corporation or a
dot.com startup -- the cost of buying BSAFE SSL-C code from RSA, with
either an OEM or an Enterprise license, might be considered money well
spent. The purchase of a crypto implementation suite is often a bet-the-
company proposition, but this code is typically only used to enhance other
products or services: e.g., the OEMs core product line. Squeezing pennies
doesn't really make sense to many CEOs who just want to minimize their
risks in handling a complex and evolving technology they neither understand
nor effectively control.
Buying BSAFE assures a stable, well-financed, and very profitable
supplier for the company's mission-critical technology; crypto code with a
"brand" identity customers and investors recognize and respect; 24x7
worldwide support, with RSA Consulting on call; up to date docs (which just
won an award); and a RSA contractual commitment to indemnify and defend
BSAFE customers against any unexpected charge of patent infringement.
In *this* market -- even after the RSApkc patent expires in
September -- BSAFE SSL-C's competition will not be the estimable OpenSSL
freeware, but rather crypto toolkits from other large commercial vendors
which can offer (and can charge for) similar assurances and support... and
which can be sued if they screw up;-)
This, IMNSHO, is why the imminent end of the RSApkc patent term in
the US has not slowed the steady growth of BSAFE sales. This is why the
non-US market for BSAFE code -- where there is no patent to justify the RSA
premium -- has been so profitable for RSA. I think this is also why the
efforts of AT&T, Certicom, and Spyrus, among others, to undercut RSA's
prices over the past year with similar crypto toolkits (exploiting other
early RSA license agreements) have failed to meaningfully cut into BSAFE sales.
There will be a lot of parties come September 20th, to be sure. It
is also likely that many new vendors, both commercial and non-profit, of
RSApkc-enabled products will soon pop up in the US. I know some regulars
on this List are pawing at the ground, like stallions impatient at the gate
to the breeding grounds. I wish them all well.
Some market analysts -- while you wouldn't know it from reading
this List or most of the Net's crypto forums -- also expect a big surge of
new interest in RSA's BSAFE products next year, as the various standards
orgs begin to realign their standards (e.g., S/MIME, SSL/TLS, PKIX) to
conform to market realities, and switch from D-H/DSS to the unencumbered
RSApkc as their required PKC crypto suite. Time (and the market) will tell.
I beg the indulgence of the List for my burden on the
bandwidth. I hope what I write is not considered offensive, but Mr.
Inverardi. asked questions that seemed to deserve at least two answers. As
I presume is obvious, my interpretation of industry history is my own and
should not be blamed on anyone else. OTOH, I have been a consultant to RSA
for many years, and that has doubtless corrupted my objectivity.
Suerte,
_Vin
Vin McLellan
The Privacy Guild
Chelsea, MA, USA
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
