Cryptography-Digest Digest #57, Volume #14        Sun, 1 Apr 01 23:13:00 EDT

Contents:
  Re: Data dependent arcfour via sbox feedback (Gregory G Rose)
  Re: Problematic Patent (Gregory G Rose)
  Re: Data dependent arcfour via sbox feedback (Mok-Kong Shen)
  primitive polynomial search program (Sean)
  Re: AES VS. DES ("Paul Pires")
  Re: Idea - (LONG) (Nicol So)
  Re: What happens when RSA keys don't use primes? (David A Molnar)
  Re: NEWS READER CRASHING (Nicol So)
  Re: New stream cipher (David A Molnar)
  Re: Deny Anon Remailers access to this newsgroup (David A Molnar)
  Re: NEWS READER CRASHING (Darren New)
  Re: New stream cipher (Paul Rubin)
  Re: Data dependent arcfour via sbox feedback (Terry Ritter)
  Re: Problematic Patent ("boobaloo")

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: Data dependent arcfour via sbox feedback
Date: 1 Apr 2001 15:45:16 -0700

In article <MdDx6.1$TH3.79@interramp>,
Bryan Olson <"nospam"@"nonsuch.org"> wrote:
>How about CBC-mode Rijndael? Rijndael is of course a block 
>cipher, but CBC-mode Rijndael is a stream cipher.  I'll let 

I think you meant CFB (Ciphertext Feedback Mode)
or OFB (Output Feedback Mode). CBC (Cipher Block
Chaining) is nothing like a stream cipher.

CFB is plaintext-aware, OFB is not.

Greg.
-- 
Greg Rose                                       INTERNET: [EMAIL PROTECTED]
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/ 
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C

------------------------------

From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: Problematic Patent
Date: 1 Apr 2001 15:52:45 -0700

There's a method by Rivest and Shamir (IIRC) that
was published way back, for a mutual
authentication method done by sending a hash then
following through with the data later. I think
it's called "interlock authentication"...
something like that. It's in Schneier's AC2, but
I'm not in a position to look it up at the moment.

good luck,
Greg.

In article <GXJx6.28781$[EMAIL PROTECTED]>,
boobaloo <[EMAIL PROTECTED]> wrote:
<
<A patent has been recently issued that appears absurdly broad, and that
<could dramatically limit activity in the field.
<
<US patent 6165072
<(enter number here: http://164.195.100.11/netahtml/srchnum.htm)
<
<Claim 51 would seem to cover any situation in which one sends encrypted data
<and then later sends the plaintext.
<
<Claim 51 states:  >>>>>>>>>>>>>>>
<
<51. Apparatus for creating and verifying secret data transactions over a
<communications network, comprising:
<
<a first processor for:
<
<(i) generating a first processor secret arbitrary data input;
<
<(ii) computing a first processor data input irreversible transform from said
<first processor arbitrary data input;
<
<(iii) communicating said first processor data input irreversible transform
<to a second processor over the communications network; and
<
<(iv) after (i) and (iii), communicating said first secret arbitrary data
<input to a second processor over the communications network.
<
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
<
<If you have prior art references for this common occurance, please post
<them.  Likewise if you have references regarding the related claims 52-56.
<
<


-- 
Greg Rose                                       INTERNET: [EMAIL PROTECTED]
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/ 
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C

------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 00:57:57 +0200



Gregory G Rose wrote:
> 
> Bryan Olson <"nospam"@"nonsuch.org"> wrote:
> >How about CBC-mode Rijndael? Rijndael is of course a block
> >cipher, but CBC-mode Rijndael is a stream cipher.  I'll let
> 
> I think you meant CFB (Ciphertext Feedback Mode)
> or OFB (Output Feedback Mode). CBC (Cipher Block
> Chaining) is nothing like a stream cipher.
> 
> CFB is plaintext-aware, OFB is not.

Is the classical auto-key encryption a stream cipher?
If yes, then CBC of a block cipher could be similarly
considered to be a stream cipher (one has more bits in
a block than in a character of auto-key encryption of
the historical version, of course), I suppose. It appears 
therefore that one shouldn't make an overly strict 
distinction between block and stream ciphers.

M. K. Shen

------------------------------

From: Sean <[EMAIL PROTECTED]>
Subject: primitive polynomial search program
Date: Sun, 01 Apr 2001 23:38:59 GMT

I've written a C language primitive polynomial search program which finds
primitive polynomials of degree n, modulo p for any prime p such that
p^n <= 2^62.

It's fairly fast, taking less than a few seconds in most cases on a Pentium
class PC.  The algorithm is based on the method of Alanen and Knuth in the
journal Sankyha.

Source code is available under the GNU Public License with detailed
documentation at http://seanerikoconnor.freeservers.com
under Professional Interests, Primitive Polynomial Generation.
Alternate location is http://seanerikoconnor.freeyellow.com



------------------------------

From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: AES VS. DES
Date: Sun, 1 Apr 2001 16:39:26 -0700


James Wyatt <[EMAIL PROTECTED]> wrote in message 
news:LZJx6.538925$[EMAIL PROTECTED]...
> I read somewhere that it would take longer than the Earth has existed to use
> a brute force attack on AES. That is assuming one processor running around 1
> gHz. I have no doubt that the NSA has methods to break this algorithm....
<snip>

They are not godlike. They may waste time and money, but probably not
by design. What you are saying is that:

The designers of AES were in cahoots with the NSA.
        or
The NSA found a way to break AES that has escaped the public analysis.
       or
The NSA has godlike powers beyond the ken of mere mortals.

Keep it simple. They might have a break on AES but probably not.
They are probably not working actively on one but merely letting
thier analists play with it in hopes.....

If they want your data, AES won't help you. There are far easier
and far more cost effective ways than cracking AES.

Paul





------------------------------

From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Sun, 01 Apr 2001 19:45:07 -0400
Reply-To: see.signature

Mok-Kong Shen wrote:
> 
> Nicol So wrote:
> >
> > Nicol So wrote:
> > >
> > > If you take source entropy out of consideration, the kind of statements
> > > you can make becomes less precise. You can avoid explicitly considering
> > > plaintext entropy by upper-bounding it, but the kind of statements you
> > > can prove will be worst-case bounds that are *not* tight. ...
> >
> > Oops. What I wrote didn't exactly convey what I meant. What I meant to
> > say was: the provable results can only tell you worst-case bounds, which
> > are not tight when *applied to a particular situation*. But as
> > worst-case bounds, they may be tight.
> 
> I am not sure that I understand you. First, a global
> question: Are you criticizing Shannon's result in any sense?

No, I was trying to clarify it. It's a common misunderstanding that the
key must be at least as along as the plaintext. That's not true in the
general case--that's true only with additional assumptions. What is true
is that the entropy in the key has to be at least at great as the
entropy in the plaintext.

> I am not aware of any cipher that says 'this cipher
> is recommended only for use on plaintexts that have at
> least such and such an amount of entropy'. 

It doesn't matter. Shannon's result is a statement of mathematical fact
about several quantities--the relationship holds whether or not it's
prudent to make assumptions about plaintext entropy in designing a
cipher for practical use.

> I think that
> that's not viable for a practical reason: One barely knows
> how much entropy there is in a piece of plaintext. 

But that's not what the result is about.

> Further,
> Shannon's perfect security says only that the opponent's
> aposteriori knowledge is equal to his apriori knowledge,
> if I don't err. 

That's correct.

> I don't yet see how Douglas Gwyn's
> 'pattern of plaintext' could be an issue that affects the
> arguments of OTP.

It's actually quite simple. Consider a source that outputs a sequence of
8-bit characters of even parity. Now a message of N characters consists
of N*8 bits, but the amount of entropy needed to transmit the message
with perfect secrecy is only N*7 bits. You don't need to expend 8 bits
of shared randomness to perfectly mask a plaintext symbol--you can use
an random even-parity character with only 7 bits of randomness.

The point is: source characteristics affect the amount of key entropy
required for perfect secrecy.

-- 
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.

------------------------------

From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: What happens when RSA keys don't use primes?
Date: 1 Apr 2001 23:57:10 GMT

Stefan Katzenbeisser <[EMAIL PROTECTED]> wrote:

> This was proved by H. Hule and W. B. Mueller in a paper entitled
> "On the RSA-Cryptosystem with Wrong Keys", which appeared in "Contributions to
> General Algebra 6", 1988, Hoelder-Pichler-Tempsky (a small Austrian
> publishing house), Vienna, 1988, pp. 103-109. The paper is quite old now
> (and perhaps difficult to get); unfortunately I don't know of any more
> recent work on this problem...

Thanks for the reference. I seem to recall from a previous thread that
Salomaa's _Public-Key Cryptography_ has a number of exercises along these
lines, as well.

-David

------------------------------

From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: NEWS READER CRASHING
Date: Sun, 01 Apr 2001 20:14:00 -0400
Reply-To: see.signature

John Savard wrote:
> 
> On 1 Apr 2001 00:24:09 GMT, [EMAIL PROTECTED]
> (SCOTT19U.ZIP_GUY) wrote, in part:
> 
> > I have noticed that sometimes I get a message that flat crashes
> >my newsreader. I found it best to just not look at such messages
> >a second time becasue it is repeatable.  I use Xnews read for now
> >but today I opened a message up and the next thing I new my browser
> >opened and was sending mail. I killed the connection but has this
> >happened to any one else. The post that caused the mail was in
> >another news group but it kind of surprised me.
> 
> There was a malicious JavaScript posting in several newsgroups -
> including this one. Some newsreaders, like Free Agent, don't try to
> execute content from postings you view.

I would like to understand the problem better. Do you have more
information about how the malicious script works?

-- 
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.

------------------------------

From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: 2 Apr 2001 00:55:47 GMT

John L. Allen <[EMAIL PROTECTED]> wrote:

> They're under the "accepted submissions" link:
>  https://www.cosic.esat.kuleuven.ac.be/nessie/workshop/submissions.html

For some reason my browser does not recognize the certificate this site uses?

-David

------------------------------

From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Deny Anon Remailers access to this newsgroup
Date: 2 Apr 2001 00:52:20 GMT

Darren New <[EMAIL PROTECTED]> wrote:

> I didn't mean to offend anyone who likes Finland. There's someone who wears
> a  tinfoil-hat and posts the most absurd messages to sci.crypt about how
> he's being persecuted and all. My favorite was his ex-blood relatives (think
> about it) trying to deport him to Finland for some reason after having the
> FBI steal all the money out of his bank accounts. Or something like that.

Oh, OK. I'm afraid I stopped reading that a while ago. Thanks for explaining. 

> If you don't recognise the reference, it's not funny. But it wasn't a cut at
> anyone's homeland or anything.

No, I didn't think it was a cut at someone's homeland - rather I thought it 
was some oblique reference to anon.penet.fi, which was one of the first and 
perhaps the most popular anonymous remailer. 

-David

------------------------------

From: Darren New <[EMAIL PROTECTED]>
Subject: Re: NEWS READER CRASHING
Date: Mon, 02 Apr 2001 01:34:03 GMT

Nicol So wrote:
> I would like to understand the problem better. Do you have more
> information about how the malicious script works?

while true:
  Open a new window.

Quite simple, really, and effective only if you're using an OS where such
will harm you.

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST).  Cryptokeys on demand.
        schedule.c:7: warning: assignment makes calendar_week 
                          from programmer_week without a cast.

------------------------------

From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: 01 Apr 2001 19:23:45 -0700

David A Molnar <[EMAIL PROTECTED]> writes:
> >  https://www.cosic.esat.kuleuven.ac.be/nessie/workshop/submissions.html
> 
> For some reason my browser does not recognize the certificate this site uses?

Yeah I seem to remember it's a Globalsign cert.  They only work in the
latest browsers.  That's why they're giving them away.  Do you care?
Are you sending anything secret to the nessie site?

------------------------------

From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 02:33:55 GMT


On Sun, 01 Apr 2001 10:16:12 GMT, in <MdDx6.1$TH3.79@interramp>, in
sci.crypt "nospam"@"nonsuch.org" ("Bryan Olson") wrote:

>In article <[EMAIL PROTECTED]>, Terry Ritter wrote:
>>
>>Bryan Olson wrote:
>>>RC4 and the proposed 
>>>modification do not encrypt by substitution of the data 
>>>characters; that's what makes Ritter's patent inapplicable.   
>>
>>I can only discuss the issue theoretically:  I can't speak to either
>>RC4 or the current proposal.  
>
>Well, you could if you looked at them.

No, I could not.  The coverage of an issued patent is a legal matter,
not a technical matter, and I would be one of the contesting parties.


However, this particular issue seems clear enough for almost anyone to
investigate quickly, and then form an opinion about what the courts
are likely to uphold.  


>>However, the Dynamic Substitution claims do not require encryption by
>>substitution.
>
>All the claims on encryption methods require two data 
>sources, the first of which is transformed by substitution 
>to form the output or substitute values.

OK, that's it.  I can't make you read; or having read, understand; or
having understood, accurately represent the facts.  

The Dynamic Substitution Combiner and Extractor patent covers
mechanisms which can be useful in cryptography, not necessarily "an
encryption method."  It covers those mechanisms however used in the
general field of cryptography.  It could, for example, cover the use
of these mechanisms in the production of random numbers.  


>From the Abstract on the first page of the patent:

"The combiner can also be used to combine two pseudo-random confusion
streams into a more-complex confusion stream."


I just don't know what could be clearer than an explicit statement in
the issued patent that combining confusion streams is a reasonable use
for the patented mechanism.  

So the claim that: "RC4 and the proposed modification do not encrypt
by substitution of the data characters; that's what makes Ritter's
patent inapplicable," is laughably ridiculous and clearly false to
anyone willing to actually read and understand the patent.  We can be
sure that a court would be so willing.  


OK, here is the text from the patent again (or see:

   http://www.io.com/~ritter/PATS/DYNSBPAT.HTM#Claims

or, United States Patent 4,979,832 from the PTO:

   http://www.uspto.gov/

):


"
I claim as my invention: 

1. A mechanism for combining a first data source and a second data
source into result data, including: 

      (a) substitution means for translating values from said first
data source into said result data or substitute values, and 

      (b) change means, at least responsive to some aspect of said
second data source, for permuting or re-arranging a plurality of the
translations or substitute values within said substitution means,
potentially after every substitution operation. 
"


Notice the absence of the term "encryption method."  All that is
necessary for this patent to apply is that the stated things exist in
the relationship described in at least one claim.  And it doesn't
matter how much other stuff is around.  

This is a "mechanism" -- a machine claim.  The patent covers the
described machine, wherever it exists, as hardware or software or any
other implementation technology.  That is quite similar to many other
patents for digital logic systems.  

In the US, we don't allow someone to take a patented digital logic
system, implement that system in software and then claim: "We can
make, sell and use whatever we want without license, because patents
can't apply to software."  In the US that is a decided issue: patents
*do* control exactly that sort of "software."  And in cryptography we
know this from the RSA patent, the IDEA patent, and the other patented
ciphers which do require a license when implemented in software.  

---
Terry Ritter   [EMAIL PROTECTED]   http://www.io.com/~ritter/
Crypto Glossary   http://www.io.com/~ritter/GLOSSARY.HTM


------------------------------

From: "boobaloo" <[EMAIL PROTECTED]>
Subject: Re: Problematic Patent
Date: Mon, 02 Apr 2001 02:43:43 GMT


"Rich Wales" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "boobaloo" wrote:
>
>     > A patent has been recently issued that appears absurdly
>     > broad . . .  US patent 6165072 (enter number here:
>     > http://164.195.100.11/netahtml/srchnum.htm)
>     > Claim 51 would seem to cover any situation in which one
>     > sends encrypted data and then later sends the plaintext.
>
> Actually, it sounds like it covers a situation in which one computes
> and sends a checksum / fingerprint / signature / message digest of a
> file, followed by the file itself.  (Note that the patent describes
> the transform as "irreversible".)

I concur.  If valid, the scope of this claim would seem to be enormous.

> For example, if I post to a newsgroup (or on a Web page) saying that a
> particular file is at such-and-so place on the net, and here's its MD5
> fingerprint so you can verify that your downloaded copy of the file is
> intact, then I've apparently infringed on this patent claim. (!)

I don't think so, since the claim regards sending both pieces of
information.

> An almost identical situation would be a CD-ROM with pieces of software
> plus their MD5 checksums -- so the installation process can verify that
> each piece of the distribution was read correctly from the CD.  FreeBSD
> releases have employed this technique for years, and I'm sure there are
> many other examples.  This isn't absolutely the same as what is claimed
> in the patent (both the data and the checksum are sent simultaneously,
> and sending someone a CD-ROM isn't exactly the same as sending data via
> a network), but the differences seem trivial in my opinion.

Similar, but certainly different.  The claim requires the "irreversible
transform" to be sent before the message itself.





------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list by posting to sci.crypt.

End of Cryptography-Digest Digest
******************************

Reply via email to