Nicolas Roumiantzeff <[EMAIL PROTECTED]> queried the List:
/> Can anyone confirm that RC4 is not a problem anymore?
Bodo Moeller <[EMAIL PROTECTED]> replied:
>It was a trade secret, but obviously is no longer secret; to my
>knowledge, RSA has never asserted to have patents on RC4.
This is correct. OTOH, RSAS has never given up their copyright on
the name RC4 either. (Nor, AFAIK, has RSAS acknowledged the equivalence of
the various RC4 clones -- which might, under US law, void whatever is left
of the trade secret IP it uses to protect its own RC4 implementation code.)
When SSL/TLS was brought to the IETF, there was some sort of special
arrangement -- a concession to the huge SSL installed base (among consumers
and commercial developers) which was accustomed to using RSA-based SSL with
RC4 -- which acknowledged the proprietary RSAS ciphers as an acceptable
alternatives, but not the required options, within the new TLS standard.
DH_DSS is, of course, the new preferred (i.e., "Mandated")
key-exchange scheme in TLSv.1... at least until September.
As I recall, however, the TLSv.1 Internet-Draft mischeviously cited
-- as its cannonical RC4 reference -- one of the several Apparently RC4
(ARC-4) clones. (Those, of course, all stem from the anonymous publication
on the Net of the results of the reverse engineering attack on the RC4
binaries that Bolo and others mentioned.)
The use of the RC4 clone in the draft RFC, as I understood it, was
to give the TLS Working Group (WG) some additional elbow room. The cite for
the "ARC-4" cipher is apparently how the legalists within the IETF
justified their use of "RC4," in a context that was obviously well beyond
what was then required for "backward compatability" with the
politically-embarrassing 40-bit RC2/RC4 "export" SSL cryptosuites.
After US crypto export controls were last loosened -- to allow for
the relatively free US export of 56-bit symmetric key cryptosystems -- the
TLS WG decided to expand the optional TLS ciphersuites to include the
strongest crypto it was possible to export from the US.
(Given IETF politics and the so-called Danvers Resolution, this was
all somewhat problematical. But then, there is a lot of smoke and mirrors
in the claim that TLSv.1 is "backwards compatable" with SSLv.3, right?
Absolutists don't belong in politics, and the standards biz is definitely
political.)
Charles Forsythe <[EMAIL PROTECTED]> noted:
//>You can call your implementation ARC4 -- Alleged RC4. If you claim that
//>your implementation is RC4 with any certainty, you may violate a
//>trademark. Yes, we all know better.
Do we now? You've got to admit it would take a lot of gall for
someone other than MIT Prof. Ron Rivest, today, to bring to market a new
symmetric algorithm called, ummm, "RC7." (The RC, btw, has always been,
according to Ron, simply his label for his newest effort, as in "Ron's
Code" -- number whatever;-)
It might also be fairly said that an "RC7" cryptosystem from
someone other than Ron Rivest would confuse and mislead the consumers and
OEMs who have come to expect the elegant simplicity, ingenious complexity,
and durable security we've seen in Prof. Rivest's RC2, RC4, RC5, and RC6.
(And that, I think, about sums up the business case which justifies a
commercial trademark in any country in the world.)
Nicolas <[EMAIL PROTECTED]> also asked:
>So is there any reason why the combination DH_DSS_RC4 is not available
>among the SSL cipher suites. It seems like DSS is always associated with
DES, >never RC4.
Since D-H popped free of patent restrictions, having served its
time, the standards-makers have tried -- as noted above -- to celebrate its
non-proprietary status by making it the "Mandated" key-exchange scheme in
their efforts to standardize the most successful RSApkc-based commercial
protocols: SSL/TLS and S/MIME.
Despite the demand for RC4's relative efficiency, however, I think
the IETF's TLS WG was uncomfortable with the idea of pairing a free
key-agreement/signature mechanism with a proprietary (copyright, if not
trade secret) RC4 cipher. I think they fudged it by referencing the
non-Rivest ARC-4 source, but still labelling the new TLS ciphersuites as
including "RC4."
Last January or February, Microsoft announced that -- to take
advantage of newly "liberalized" US export regs -- the CSM for WIN2K would
include a new series of 56-bit ciphersuites for RSA1024 (with RC4-56,
RC2-56, and DES) -- as well as DH_DSS_DES.
The TLS WG subsequently persuaded Microsoft to drop RC2-56; add
DH_DSS1024 with RC4-56 *and* DH_DSS with RC4-128 (as well as DH_DSS_DES);
and to switch from MD5 to SHA-1 for all of the expansion suites.
I think the same expansion ciphersuites were adopted for TLSv.1.
I also recall Ben Laurie saying that -- while the WG debated and
danced around these issues -- he had already added the new ciphersuites to
the OpenSSL code base. Ben, is that right? DH_DSS_RC4?
Suerte,
_Vin
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
