Re: RSAREF bug issues

[Vin McLellan <vin () shore net>]

        According to a well-informed government source,  R. DuFresne wrote:

> > Has there been a patch released by the RSA folks to deal with it's recent
> > failing?  <snip>

        Bennett Todd <bet () mordor net> replied to the firewall-wizards List:

> First off, yes, there has been a patch posted, the OpenBSD folks at least have
> released a patch, and maybe other folks have too I don't know, and the 
> RSADSI folks have officially given permission to use this patch. RSADSI 
> didn't release a patch themselves; they aren't programmers, they're just 
> lawyers doing their day job of trying to prevent people from using good 
> encryption.

        Sheeeesh!  I think this note deserves a few comments.  I don't
normally  respond to such jibes at RSA Security (for which I've been a
consultant for many years) -- but Mr. Todd's posts on other topics have
earned the respect of many readers in these forums, and I would hate to see
his credibility mislead others.  

        RSA's business practices, patent royalty rates, and commercial
licensing practices are fair game for criticism -- the market decides if
they are acceptable -- but these comments about the quality of RSA's crypto
engineering and programming are obscenely ill-informed.

        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.   
        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;-)

        In those 17 years, BSAFE Crypto-C code  (now at version 4.3, and
fully backwards-compatable) has never been cracked due to a failure or error
in the RSA-programmed implementation.  It has also proven to be gracefully
portable to thirty-odd different platforms.  I won't say BSAFE Crypto-C code
has never had a bug, but I've never heard a verified report of one.  

        No product is perfect, of course, but RSA's core crypto product has
a tradition and a reputation for robust and high quality programming that
few, if any, commercial products can match. Non-programmers?!? Yeah,  right.

         (Care to suggest why Checkpoint, in Israel, licensed BSAFE SSL-C
and bought rights to use the RSA Security brand name in touting its FW-1 VPN
in the international market?  Why Intel bought rights to use the whole BSAFE
toolkit for future chip-based crypto?  RSApkc has never been patented
outside the US, of course -- and the RSApkc patent will surely expire before
Intel brings serious chipped crypto to market.)

        Those evil RSAS shareholders do indeed own the US-patented RSA
public key algorithm (RSApkc) and -- to a greater or lesser degree, RSADSI
having defined both what is both possible and unworkable for safeguarding
intellectual property in cryptosystems --  to Ron Rivest's symmetric
algorithms too: RC2, RC4, RC5, and RC6.  

        There are people (strikingly, very few programmers among them) who
have spent their professional careers denouncing Rivest, RSA, crypto
patents, and (generally) intellectual property rights for cryptosystems.
Better, they argue -- for everyone but RSA stockholders -- if RSA had freely
published all these ciphers as like it did with Rivest's message-digest
hashes, MD2 and MD4, which were given to the developer community without
restrictions. (MD2 and MD4 were, in their time, state of the art. Even
today, SHA-1 is built upon MD5.  Good hashes turn out to be rare.)  

        Yet, incomprehensibly, these lawyerly "non-programmers"  have:

        - produced in RSA's BSAFE toolkit arguably the single most
widely-trusted (and historically, rock-s0ld) library of implementation code
ever brought to market -- with platform-independent and thread-safe
implementations of both the RSA-proprietary algorithms, D-H and ECC
implementations, as well as  non-proprietrary algorithms like DES and 3DES;

        (You're in finance, Mr. T.  Want to hazard a guess from whom the
biggest US international banks have been buying 3DES implemention code this
year?)

        - fought off 15 years of US government efforts to buy, seize,
discredit, or pre-empt their technology with GAKed NSA crypto; 

        (Want to guess where the big Japanese and Asian financial networks
have for years bought DES implementations they were willing to trust?)

        - promoted their technology by developing what for over a decade has
been the defacto application standards for public key crypto -- see the PKCS
at www.RSAsecurity.com -- while the US and  international standards orgs,
including NIST and the ABA's X9, took NSA orders and sat on their hands and
played deaf, dumb, and blind; 

        -organized the RSA Crypto Challenge contests which have provided the
single most influential measure of the relative strength of both PKC and
symmetric ciphers (effectively discrediting 40 and 56-bit export crypto in
the process.)
        
        - maintained their intellectual property rights, as was their right
and fiduciary duty, by challenging commercial efforts to use their patented
technology without paying the piper. 

        Mind you, I don't think a halo for RSA execs is any less absurd than
the horns and tail commonly put upon them in the current open-source
hysteria; or, earlier, by the acolytes of IP-free crypto; or by the
big-company negotiators who complainted about RSA's "slice of the pie"
licensing policies in the early 1990s.   But the quality of the RSA's
implementation code?  

        RSA's BSAFE ciphers will never be the fastest -- their design and
engineering has other priorities; the  sole product of a speciality crypto
vendor like RSA is trust -- but even RSADSI's critics generally acknowledged
the quality of RSA's research, code, and crypto engineering.

> Second, the bug in question only affects the RSAREF code if it can be invoked
> in a hostile fashion; sufficient parm checking in the caller can protect this
> bug against a remote exploit. So independantly the OpenSSH folks had fixed
> their sshd so that this bug didn't end up producing an exploit for them.

        Early PGP apparently had similar safeguards.  The problem was that
the RSAREF toolkit did not offer internal restrictions on the size of four
inputs -- but then, the freeware RSAREF was never designed to support these
types of production systems.

> Third, the bug is only known to exist in the RSAREF code, which is
> known-bad code. 

        Yeah, right. 

        RSAREF was a freeware toolkit that is explicitly restricted, by the
terms of the license which accompanies it, to the calls available in the
provided user interface.  Period.  Other uses were forbidden.   See the
RSAREF license at: <http://www.epm.ornl.gov/~dunigan/rsaref.txt>

        RSA Security's implementation of its own and other ciphers for
commercial users and OEMs is the well-known BSAFE line of toolkits:
Crypto-C, Crypto-J, SSL-C, and SSL-J. RSAREF was based on pre-BESAFE  code
-- circa 1991 or 1992 -- and has never shared any common codebase with RSA's
commercial implementation code or the RSA BSAFE products.

        RSAREF was designed to allow for academics and corporate users to
study and play with crypto apps, set up testbeds, and support
Privacy-Enhanced Mail (anyone else remember PEM?)  It may place it in
perspective (and help date it for newbies) to point out that RSAREF was, as
much as anything, intended to show off Rivest's free MD2 and MD4 hashes, and
to introduce people to the idea of message digests. 

        RSAREF was not designed, nor tested, nor provided, nor licensed for
applications like  SSH, PGP, SSLeay, OpenSSL, Stunnel, etc.   I think most
of those were pretty obviously rogue apps when, paired with RSAREF, they
slid RSApkc functionality into US commercial sites through the backdoor as
"non-commercial" test-bed applications.  (PEM they were not;-) SSH and
SSLeay were created overseas, of course, where there is no RSApkc patent.
Like PGP, they came into widespread use (built upon RSAREF) in the US
business community simply because  -- gothic legend to the contrary --
RSADSI never went thrashing through the bushes to identify illicit RSAREF
users.  

        (RSADSI initially allowed RSAREF users to spin RSAREFv2 into
limited-profit shareware.  There were also a brief attempt to commercialize
an even more restricted version of RSAREFv.2 -- with an overt limit on
connection-counts -- but that was abruptly cut off in 1997 when C2 showed
that it was possible to overcome those limitations and challenge RSADSI's
OEM licensees with an RSAREF-based SSL-enhanced Apache webserver. 

        (Subsequent negotiations allowed C2 to obtain a full RSApkc patent
license -- but it also led RSADSI to refuse to further support, enhance, or
distribute the RSAREFv.2 freeware to avoid cutting into their core revenue
stream. And that, of course, led directly to the bitterness that Mr. Todd
and many other creative programmers feel toward RSADSI for denying them the
chance to freely program RSApkc and play with it and the other RSA
cryptosystems.)

        The bottom line was that RSADSI was never able to develop a license
which allowed local use of RSA implementation code, or local programming of
RSApkc and other RSA cryptosystems, and still effectively protected the RSA
IP from piracy or reuse in the commercial market (where RSA sells its crypto
skills and products at a pricey premium, typically two percent of  revenues
from an RSApkc-enhanced product.)  

        Maybe today's IP lawyers could pull it off without onerous
restrictions on the user, but I'm not sure of that.   It is also difficult
if not impossible to rework the old RSAREF licenses which remain in
circulation.  Instead, RSADSI chose to let its freeware toolkit die.   RSA
refused to upgrade RSAPKCv2, despite a voracious demand; and (at least until
earlier this month) RSA used the terms of its RSAREF licence to forbid all
third-party efforts  to patch or upgrade the RSAPKCv2 source code.  (Only
the immediate threat to the still-exant RSAREF sites led RSA, a couple of
weeks ago, to formally give users legal permission to patch the old RSAPKCv2
code to block the buffer overflow vulnerability.)

        RSADSI eventually accepted several negotiated deals which
legitimized several huge communities: users of MIT's PGP version (and SSHv1
too, I think) -- and pushed a licensing campaign which now provides SSL
server functionality to consumers at prices as low as the $150 Red Hat
Secure Server.  This is not a satisfactory solution for everyone -- hands-on
programmers like Mr. Todd may still be disgruntled -- but inexpensive SSL
server functionality (which can be used to proxy anything) is now a US
mass-market commodity, despite the burden of RSApkc royalities.

        Mr. Todd also commented:

> RSADSI forces people within the US who want to use RSA 
> for non-commercial purposes to use RSAREF. They sell a closed-source, 
> proprietary BSAFE lib, which may or may not have similar problems (I'd 
> guess it does, since they're not programmers). Most commercial secure web 
> servers sold in the US are probably linked against BSAFE rather than 
> RSAREF, so they may or may not be at risk, and then only if the SSL invoking 
> code happens to be willing to pass the problem through the the library.

          Only Mr. Todd -- who seems unlikely to have had much experience
with BSAFE toolkits, for all his savvy and experience in other aspects of
the craft -- has suggested that the BSAFE Crypto-C toolkit is vulnerable to
this particular problem.  It's a serious charge about any commercial code;
an irresponsible accusation when made without a bit of evidence about code
almost everyone depends upon.

        OTOH, RSA Labs -- the developers of SET, S/MIME, and the PKCS;  the
guys who defined the design criteria for BSAFE  -- says that BSAFE code is
not vulnerable to this threat.  That seems to be sufficient assurance for
the OEMs who rely upon BSAFE code to service hundreds of millions of users.

> And the RSA implementation in OpenSSL doesn't have this problem. Of 
> course it may be a patent violation to use that RSA within the US for some 
> purposes until Sep. 29, 2000.

        Yup.  Of course, Eric Young (eay), the Australian author of SSLeay
--  still the functional core of the OpenSSL toolkit -- became the CTO of
RSA-Australia last year.  He subsequently reworked SSLeay into RSA's BSAFE
SSL-C toolkit, which has been a successful commercial product in both the
international market and in the US. 

         (RSApkc was never patented outside the US, as I noted, but US
export controls effectively blocked RSADSI from competing against firms like
Baltimore Tech in the international crypto market until RSA-Australia broke
free.  The new US export regs expected next month may free the rest of the
BSAFE toolkits to directly challenge their competitors in the unrestricted
world market.)

> The above are all "to the best of my knowlege", but I figured I'd let all my
> ignorance hang out here, if I'm wrong on any of I'm sure I'll get corrected
> fast in this forum:-).

        I've tried this approach myself.  I don't recommend it. 
      
         I beg the indulgence of the List for the burden on the bandwidth.


         Suerte, Safe 2K, and Happy Holidays,

                _Vin       
  --------
  "Cryptography is like literacy in the Dark Ages. Infinitely potent, for
 good and ill... yet basically an intellectual construct, an idea, which 
by its nature will resist efforts to restrict it to bureaucrats and others
who deem only themselves worthy of such Privilege."  
 _A Thinking Man's Creed for Crypto  _vbm
                     
     *    Vin McLellan + The Privacy Guild + <vin () shore net>    *