Re: legal status of RC4

[bram]

First off, anybody could make a cipher called 'RC7'. RC7 isn't
trademarked, and 'RC' as a prefix isn't either. It's the same reason why
we have an MP4 unrelated to MP3, and why Intel makes Pentiums instead of
586's.

I'm a little confused about what exactly constitutes 'causing customer
confusion' with regards to using the term RC4. If I publish something
clearly labelled 'Bram's crypto library' and list RC4 as one of the
ciphers supported, there's no implication of anything coming from RSA, it
comes from Bram. There's always the trademark dilution claim, although my
understanding is that only applies to 'famous' trademarks, which RC4
clearly isn't, and the proper legalese response to a claim of dilution can
be roughly translated into plain english as 'blow me'.

-Bram

Re: prove me wrong, go to jail

[bram]

On Thu, 27 Jan 2000, Eric Murray wrote:

> Netscape used to have a similar policy.  I beleive
> that they called it "bugs bounty".   They also posted security bug
> fixes for public review (i.e. the random number bug).

Yep, they sure did. I won one of the $1000 ones. They had some paperwork
problems on it though - a while after I had deposited my check they mailed
me asking if I'd ever gotten one.

-Bram

can the government require your keys?

[Steven M. Bellovin]

Something that's been debated endlessly on the net is whether or not the (U.S.)
government can compel someone someone to turn over their keys.  Some 
(including lawyers) have said yes, on the grounds that a key is 
non-testimonial.  Others (again, including lawyers) have pointed out that a 
key may not be testimonial, but that a defendant's knowledge of it is, and 
that the key is therefore covered by the Fifth Amendment protection against 
self-incrimination.  There's now a new wrinkle.

According to an article in the NY Times CyberLaw Journal (see 
http://www.nytimes.com/library/tech/00/01/cyber/cyberlaw/28law.html), the 
issue arose during the Mitnick case.  However, rather than demanding the key 
under penalty of a contempt citation, the prosecutors declined to turn the 
encrypted files over to the defense team.  Although Rule 16 of the Federal 
Rules of Criminal Procedure require the government to turn over documents that 
"were obtained from or belong to the defendant", the prosecutor argued that 
the government didn't really possess the files, since they couldn't read them. 
They further claimed that the files might have illegally-obtained information 
or "for all we know, it could be plans to take down a computer system."  The 
information "might be dangerous"; it was likened to a defendant asking for a 
coat back without the government knowing if there was a pistol in the pocket.

The judge sided with the prosecutors.  Unfortunately, the ruling probably 
can't be appealed at this point, given the plea bargain.  But it will come up 
again; the Clinton administration is apparently planning on introducing a bill 
on access to keys.

--Steve Bellovin

Re: prove me wrong, go to jail

[Eric Murray]

On Thu, Jan 27, 2000 at 10:31:46AM -0800, Ed Gerck wrote:
> I can imagine a company writing, for the benefit of all:
> 
>  We support open assessment of risks -- if you find a security fault
>  in our systems, please tell us first so that we can fix it first.  We commit
>  ourselves to making public all such communications after a solution
>  is found so that publication will not compromise the system further. We
>  also reward any recognized security fault called to our attention, up to
>  US $1,000 from a minimum of US$ 50 -- value to be defined by us in
>  relationship to known faults and to its relevance.  To be ellegible for
>  the reward, we must be the first and only to be informed about it. The
>  company reserves the right to consider legal measures to the full extent
>  of law if  a fault is discovered or a reward is pursued by illegal actions.


Netscape used to have a similar policy.  I beleive
that they called it "bugs bounty".   They also posted security bug
fixes for public review (i.e. the random number bug).

-- 
 Eric Murray www.lne.com/~ericm  ericm at the site lne.com  PGP keyid:E03F65E5

Re: legal status of RC4

[Vin McLellan]

Arnold G. Reinhold <[EMAIL PROTECTED]>  asked:

>Are you sure RC4 is a registered trademark? I've never seen anything 
>that would indicate that.

RSADSI first filed for a US trademark on "RC4" in 1993.  

RSA has used RC4 (R) since 1988 in "trade and commerce" (as the
phrase goes) to refer to the RSA-branded stream cipher Ron Rivest had
created for RSADSI.   (RC4, I suppose, became a common law trademark -- in
the US and elsewhere -- sometime thereafter.)  

The  "RC4" trademark was formally Registered by the US Patent and
Trademark Office on August 15, 1995.  

The USPTO registration number for RC4 is: 1911168.

The USPTO Trademark Database citation for RC4 is on the Web at:


Surely a RC4 TM is no surprise.  Over the years, RSA has routinely
noted that "RC4" is a registered trademark  trademark. 

In the US and elsewhere, a trademark is intended to prevent
confusion among buyers by clearly indicating who is providing a given
product to the market.  The basic idea is that a consumer should not have to
open a package (or do an MD5 hash on a digital product;-) to be confident
that his TM-based assumptions about the _source_ of a product -- and any
prior knowledge he has about vendor's support, QA, warranties,
compatability, business practices, etc., etc. -- are valid.  

By the latter half of the 1990s, of course, almost everyone with a
computer had it loaded with a SSL ciphersuite -- which included a
clearly-labelled, RSA-coded, RC4 crypto module.  (RSADSI's willingness to
gamble on Netscape and SSL and accept a fabled one percent of Netscape's
equity  in return for permitting Netscape access to RSA's BSAFE ciphers,
including RC4,  paid off  handsomely.)

I'm don't mean to be disingenuous. I acknowledge that there are many
who claim that the various independently-coded ARC4 ("Apparently RC4")
ciphers are functionally and otherwise equivalent to the RC4 implementation
found in RSA's BSAFE.   Whether that is (or is not;-) the case --  it is
also clearly and incontestably true that none of the various ARC4-like
ciphers are actually coded, QAed, or sold by RSA Security.

Last year, Kalle Kaukonen of SSH and Rodney Thayer of Counterpane
even wrote an Internet Draft RFC --
http://search.ietf.org/internet-drafts/draft-kaukonen-cipher-arcfour-03.txt
-- to offer yet another version of  "Arcfour."  The RFC explains that they
hoped their Arcfour would  smooth the transition to IETF-endorsed standards
from the earlier generation of defacto compsec standards  (hich had the ill
but entreprenurial grace to be based on proprietary RSA ciphers, RC4
prominent among them;-)

   These days, most people in the Craft would conceed that it would take
a humungous amount of gall for some individual, company, or committee --
anyone *other than* RSA or MIT Prof. Ron Rivest -- to publish a new cipher
labelled, say, "RC7." Which is not to say that it won't happen, of course.

(In response to a query in private e-mail for evidence off the RSA
website  that RSA publicizes the RC4 trademark), I just did a quick search
of  and pulled up three notable references to the RC4
trademark. See: 

1. Specs for RSA's newest version of BSAFE Crypto-C toolkit:
URL: 

"Crypto-C includes all popular secret- and public-key encryption algorithms,
including the RC4® stream cipher, the high performance RC5"

2. The 1998 announcement of BSAFE 4.0:
URL: 

"RC2® and RC4® are registered trademarks and BSAFE is a trademark of RSA
Data Security, Inc."

3. The 1994 announcement of BSAFE 2.1:
URL: 

"The RSA logo, BSAFE, RSA Public Key Cryptosystem, RSA Digital Signature,
RSA Digital  Envelope, RC2, RC4, MD, MD2 and MD5 are trademarks of RSA Data
Security, Inc. [...]"

Surete,
_Vin








 

Personally, I believe that Trust -- a value might be consistently
associated with a specific trademark --  is the critical factor in any
intelligent purchase of a cryptographic cipher or product.  It doesn't seem
to matter much whether the buyer is an individual consumer, a corporate PO,
or a globe-girdling OEM. To the extent that Trust matters to end-users --
and many OEMs act like they believe that it matters a lot --  RSA's
trademarks come into play.  

Re: The problem with Steganography

[William Allen Simpson]

Catching up on the thread, the comments about fitting the stego into the 
image reminded me of http://www.outguess.org/ by Niels Provos.  Looks like 
he's a few months ahead of you

Marc Horowitz wrote:
> 
> Rick Smith <[EMAIL PROTECTED]> writes:
> 
> >> Thus, a 'good' stego system must use a crypto
> >> strategy whose statistical properties mimic the noise properties of the
> >> carrying document. ... So, can't we detect the presence of stego'ed data by
> >> looking for 'noise' in the document that's *too* random?
> >>
> >> ... Once we replace those bits
> >> with data, the bits will have serously random statistical properties. So,
> >> we can detect stego'ed data if the implementation uses any well known
> >> strong encryption algorithm.
> 
> If the picture was taken by an actual camera, the least significant
> bits will be random due to the nature of the way CCDs work in the real
> world.  They might be biased, but it's not very hard to bias a
> "random" data stream.  

[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32