Cryptography-Digest Digest #62, Volume #14 Mon, 2 Apr 01 15:13:00 EDT
Contents:
Re: Data dependent arcfour via sbox feedback (Mok-Kong Shen)
Re: Malicious Javascript in Brent Kohler post (was: Re: Who is Brent K (Mok-Kong
Shen)
Re: AES ("James Wyatt")
Re: Data dependent arcfour via sbox feedback (Mok-Kong Shen)
Cryptix JCE performace (AY)
keys and random (Brian D Jonas)
Re: How to do RSA Problem to avoid exponentiation overthrow? (Kirby Urner)
Re: Data dependent arcfour via sbox feedback (Ken Savage)
Re: Cryptix JCE performace (Paul Rubin)
Re: Data dependent arcfour via sbox feedback (Ken Savage)
Re: Blind signature (Mike Rosing)
Re: Data dependent arcfour via sbox feedback (Ken Savage)
Re: Idea - (LONG) (Steve Portly)
Re: Data dependent arcfour via sbox feedback (Terry Ritter)
Re: Data dependent arcfour via sbox feedback (Terry Ritter)
AAECC 14, Melbourne, Australia -- Call For Summaries (Serdar Boztas)
Re: Data dependent arcfour via sbox feedback (Terry Ritter)
Re: Data dependent arcfour via sbox feedback (Terry Ritter)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 18:07:53 +0200
Benjamin Goldberg wrote:
>
[snip]
> The Dynamic Substitution patent covers combining two input streams with
> each other and with the state of a cryptographic object, and producing
> one single output stream (and modifying the object's state).
[snip]
Schneier's AC has in Chap 16 and 17 many schemes of
combining two or more streams with or without feedback.
I wonder whether some of these wouldn't stand in conflict
with the above 'combining'.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Malicious Javascript in Brent Kohler post (was: Re: Who is Brent K
Date: Mon, 02 Apr 2001 18:18:37 +0200
Benjamin Goldberg wrote:
>
> Especially since it might be possible to create for one's mail/news
> reader some sort of plugin which will do search and replace of latex
> math stuff with mathml; it would be disabled by default, but turnonable
> at the user's discretion (and be a last step just before sending).
>
> Why suggest this rather than a latex parser? Well, 1, as you say, the
> standard group's approach is towards mathml and the like, and 2, it's
> much too easy for a parser to interpret something as latex that
> shouldn't be, especially if it's inline with normal text. Also it
> allows for messages which are multipart/alternative, with the first part
> being purely text, with latex for formulae, and the second part html,
> with everything except the mathml enclosed in <pre> tags so it looks
> like the plaintext part (except for showing formulae instead of
> symbols).
Dumb question: Is there anything against the idea of using
the tags <latex> and </latex> to include latex meterials
in html? (Any parsing problems, etc. ?) I don't think so.
Thus the issue seems to be that the standard group hadn't
chosen the way that is the optimum in the current case.
M. K. Shen
------------------------------
From: "James Wyatt" <[EMAIL PROTECTED]>
Subject: Re: AES
Date: Mon, 02 Apr 2001 16:27:06 GMT
The AES proposal on the NIST website says six months from when the Secretary
of State signs the FIPS.
jim
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:9a8t2v$kko$[EMAIL PROTECTED]...
> When will AES become a final standard?
>
> --
> Tom St Denis
> ---
> http://tomstdenis.home.dhs.org
>
>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 18:27:46 +0200
John Savard wrote:
>
[snip]
> To solve this, and retain good error propagation, just XOR the input
> (or output) of DES3 with the output of a good PRNG. Doing the same
> with the input to DES1 and the output of DES2 increases the kinds of
> substitutions that the cipher can generate, and is the next possible
> improvement.
Employing a PRNG with a block encryption appears always
to be a good idea in my humble view.
M. K. Shen
=========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: AY <[EMAIL PROTECTED]>
Subject: Cryptix JCE performace
Date: Mon, 02 Apr 2001 17:42:27 +0100
Hi all,
I am trying to use Cryptix JCE for my project. However I've noticed that
key generation schedules are very slow. I can understand this in case of
RSA keypairs because of the probabilistic nature, but I don't see any
reason it'd take more than 5 seconds to generate a modest Rijndael key
(on a well RAM'd PII). In fact I would expect it to be done in a
fraction of a second?
In fact my experience with ABA JCE is that it could generate 512 bit
RSA keypairs almost intantaneously?
Is this some sort of RNG initialisation issue? Have I done something
incredibly stupid?
Any help or comments appreciated.
AY
------------------------------
From: Brian D Jonas <[EMAIL PROTECTED]>
Subject: keys and random
Date: Mon, 2 Apr 2001 12:56:21 -0400
I want to thank those that answered my original post concerning
diffie hellman key exchange. The site I got my info from was a bit
confusing. So hardcoding the 2 in a=2^x mod p is a-ok. Hardcoding the
prime p is a bad idea. x is the random number of size less than p, but IS
NOT prime. a and p are sent to the receiver. Receiver calcs a1=2^x1 mod p.
Where p is the prime received. Receiver then calculates
k=a^x1 mod p and sends back to sender a1. The sender uses the a1 received
to calc k=a1^x mod p . Now k=k.
p needs to be a random sohpie germain prime
x needs to be a random number less than the size of p
etc etc (for other contacts)
What is the predicted strength of a 1024bit germain prime ? ie: with
current hardware advances, not agorithmic factoring breakthroughs is it
considered secure for 5years, 10 years ?
These "random" numbers are used daily for encryption. Since computers are
NOT random in any way, what functions are used to get pseudo-random
numbers? ie: are secure servers that use random numbers attached to a some
sort of random source ? (lava lamp, decay etc etc) ?
------------------------------
From: Kirby Urner <[EMAIL PROTECTED]>
Subject: Re: How to do RSA Problem to avoid exponentiation overthrow?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 02 Apr 2001 10:10:37 -0700
"Raymond Lee" <[EMAIL PROTECTED]> wrote:
>I have a simple RSA problem that I couldn't figure out
>
>Give p=29, q=53, e=103, plaintext M=199 in the RSA algorithm, calculate d,
>and the ciphertext C.
>
>Here's my calculations:
>
>n = p*q = 1537
>(p-1)*(q-1) = 1456
>103d = 1 mod 1456
>I figure out d=311 by writing a program
This is correct.
>
>C=M^e mod n
>= 199^103 mod 1537
>=634
Something wrong here. Using Python's built-in pow(M,e,n) = M^e mod n
I get:
>>> pow(199,103,1537)
1064
>to double check the answer, I put C=634 to find M, to see if M=199
>M=C^d mod n
>= 634^311 mod 1537
>= 1178, not 634
And the plaintext comes back:
>>> pow(1064,311,1537)
199
>please tell me which part I go wrong, I really appreciate your help, I guess
>I ran overthrow in the calculations.
>
>Please tell me how to do this problem correctly, please let me know.
>
>Thanks
>
>
>
>
------------------------------
From: Ken Savage <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 17:32:10 GMT
Mok-Kong Shen wrote:
>
> Terry Ritter wrote:
> >
>
> > 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
>
> The problem with at least non-professinals of patents is,
> I believe, that such a claim like the above is so general
> that it appears to cover even stuffs like DES. Could
> someone explain why DES is NOT covered by that claim?
Agreed totally!!! Any XOR-type stream cipher can be looked at as two
data streams, the first being the random output, and the second being
the plaintext. You can't tell me that any reversible combination of
two data streams falls under this patent; that would throw a HUUUGE
monkey wrench into all sorts of things -- error correction codes pop
into mind as another possible "interpretation"... Ick.
$0.03 worth,
Ken
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Cryptix JCE performace
Date: 02 Apr 2001 10:37:49 -0700
AY <[EMAIL PROTECTED]> writes:
> Is this some sort of RNG initialisation issue?
Probably.
------------------------------
From: Ken Savage <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 17:47:59 GMT
John Savard wrote:
>
> Data is now being XORed, not only with the quantity produced by the
> RC4 PRNG, but with z, which is the previous ciphertext, substituted
> for in the S-box.
> quantity. However, that means it isn't a "data dependent arcfour" as
It's not always simple to invent a short title that summarizes
the entire article. I think that we can all agree that it is arcfour,
it is data dependent, and that dependence is achieved through feedback
involving the internal sbox :)
It seems that you're right -- that since the swap() statement doesn't
involve sbox[data], or anything pertaining to the data, most people
here are agreeing it doesn't fall into the Dyn Sub patent *phew*.
Still no idea if it's actually a secure cipher though... (Someone was
mentioning earlier in the thread that the internal state could still
be determined by comparing a series of ciphertexts known to be
encrypted with the same key. I'm not convinced, guess it's time to
reread the thread.)
Cheers,
Ken
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Blind signature
Date: Mon, 02 Apr 2001 12:45:16 -0500
Cristiano wrote:
>
> How can I implement blind signature with elliptic curves?
You translate a DL signature scheme to ECC using x^y -> y*X and x*y -> X+Y
where *,+ on the right are over the curve. From the RSA web site
(http://www.rsasecurity.com/rsalabs/faq/7-3.html) we get:
========================
Using RSA signatures (see Question 3.1.1), Chaum demonstrated the implementation of
this
concept as follows: Suppose Alice has a message m that she wishes to have signed by
Bob, and
she does not want Bob to learn anything about m. Let (n,e) be Bob's public key and
(n,d) be
his private key. Alice generates a random value r such that gcd(r, n) = 1 and sends x
= (r^e
*m) mod n to Bob. The value x is ``blinded'' by the random value r; hence Bob can
derive no
useful information from it. Bob returns the signed value t = x^d mod n to Alice. Since
x^d = ( r^e * m)^d = r*m^d mod n
Alice can obtain the true signature s of m by computing s = r^-1 t mod n.
==========================
So the translation is curve E with suborder n.
Then X = M + e*R, T = d*X = d*(M + e*R) = R + d*M.
Alice can compute s = T - R.
Now, this requires n to be a composite with 2 large primes. finding such a curve is
hard (well, not any more with Satoh's algorithm, but I sure dont' understand it :-)
You can find other methods in Brands' thesis which should work better. It's the
translation process that's most useful to you.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Ken Savage <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 18:02:00 GMT
Bryan Olson wrote:
> I'm not sure it's been stated, so I'll note an obvious
> defect in the proposed scheme: If we grant the attacker
> multiple known plaintexts from the same starting state, he
> can easily discover the state.
Forgive the list of questions...
1) By 'state', are you referring to the sbox/x/y/c values,
or are you referring to the random stream's contents which
are xor'ed with the plaintext? In the first case, you would
be able to continuously predict the PRNG, but the latter
would be squashed by the length of the longest plaintext.
2) How would this be any different from standard RC4?
3) If there was an "IV" prepended to the known plaintext,
the combination thereof encrypted, would you be able to
determine the state. All of the plaintext is known, but
that dang 16-byte header isn't :)
Ken
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Mon, 02 Apr 2001 13:09:42 -0500
Mok-Kong Shen wrote:
> Nicol So wrote:
> >
>
> > 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.
>
> Suppose a message has some standard header, say, the name
> of the sending and receiving station, the time, etc. that
> need not be concealed to the opponent (he knows it anyway),
> then one could but obviously need not encrypt the header
> part with any entropy. One can presumably come up with
> a large number of such special cases. On the other hand,
> if the opponent knows in your example that the leading bit
> of a byte is always zero, then expensing entropy to encrypt
> that bit is always a waste. But how about the case where he
> doesn't have that knowledge? Does it help anything in
> security? Thanks.
>
> M. K. Shen
In situations where an algorithm is to be used to encrypt both 7 and 8 bit
content it is easier to code for the 8 bit content even if it is overkill for
the 7 bit. Such an algorithm might use a preliminary round to evenly disperse
however many bits of stuff to be encrypted into the 8 bit channel width. Its
sort of like making pizza or taco shells you roll out the dough before you
fold and pound it.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 18:24:46 GMT
On Mon, 02 Apr 2001 17:59:27 +0200, in <[EMAIL PROTECTED]>,
in sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>>
>
>> 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.
>
>The problem with at least non-professinals of patents is,
>I believe, that such a claim like the above is so general
>that it appears to cover even stuffs like DES. Could
>someone explain why DES is NOT covered by that claim?
>Thanks.
When we check for patent infringement, we don't look at the whole
description and then just somehow form an impression one way or the
other. Instead, we try to match the specific words of each
requirement, phrase by phrase, with the design being checked, e.g.,
"Does this fit? Does this fit," and so on.
Suppose we start checking whether DES infringes Dynamic Substitution
by finding a "substitution means" in DES: Well, we might say that
corresponds to an s-box. So there is a "substitution means," so far
so good. Now we need to show that the entries in said "substitution
means" are "permuted or re-arranged." But nothing like that happens.
Which means this particular interpretation of DES does not "read on"
that claim, and so does not infringe that claim.
Now, is there any other sort of "substitution means" in DES? Not that
I see. Is there any "substitution means" in which the entries are
permuted? I don't think so.
The requirements in a patent claim are not abstract theoretical
concepts. In a machine claim, the invention consists of actual
realizations for the specified entities. To check for infringement,
we try to find each requirement and check it off, one by one.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 18:25:03 GMT
On Mon, 02 Apr 2001 06:34:44 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>The patent does not apply to the proposed cipher, but for an entirely
>different reason than the one Bryan Olson claimed.
The appropriate way to check for infringement is to take the actual
words from a claim and try to fit them to the design being checked.
>The proposed variant combines one single input stream of data with the
>internal state of a cryptographic object, and produces as output one
>single stream of data (and modifies the object's state).
>
>The Dynamic Substitution patent covers combining two input streams with
>each other and with the state of a cryptographic object, and producing
>one single output stream (and modifying the object's state).
>
>The difference between the proposal and the patent is the number of
>input streams, one versus two.
But then the question arises as to whether or not there is in fact
just a single input stream. That does not appear to be the case.
Here is one way it might go:
>Here's the proposed modified RC4:
>
>byte x, y, z, sbox[256];
>encipher(byte data) {
> x = (x + 1) & 255;
Here x might be the "first data source."
> y = (y + sbox[x]) & 255;
Here y might be the "second data source," and sbox[] might be the
"substitution means for translating values from said first data source
into said result data or substitute value."
The "second data source" is modified by said "result data" before use,
but no part of the claims excludes that possibility. Quite the
contrary, as we see . . . .
> swap( sbox[x], sbox[y] );
Here we have the "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."
I draw attention to the phrase: "responsive to *some* *aspect* of said
second data source." The claim thus specifically recognizes that the
original "second data source" value may be modified before use.
And that would seem to complete the requirements for Dynamic
Substitution, claim 1.
> data ^= sbox[(sbox[x] + sbox[y]) & 255] ^ z;
> z ^= sbox[data];
> return data;
>}
>decipher(byte data) {
> x = (x + 1) & 255;
> y = (y + sbox[x]) & 255;
> swap( sbox[x], sbox[y] );
> data ^= sbox[(sbox[x] + sbox[y]) & 255];
> z ^= sbox[data];
> data ^= z;
> return data;
>}
>
>If persons A and B both start with a particular sbox, x, y, z, then A
>sends r=encipher(q), then B can calculate q=decipher(r).
>
>Here's an example of Dynamic Substitution:
>byte sbox[256], sibox[256];
>encipher(byte data1, byte data2) {
> byte dataout = sbox[sbox[data1]];
> swap( sbox[sbox[data1]], sbox[data2] );
> return dataout;
>}
>decipher(byte data1, byte data2) {
> byte temp = sibox[data1];
> byte dataout = sibox[temp];
> swap( sibox[data1], sibox[sbox[data2]] );
> swap( sbox[temp], sbox[data2] );
> return dataout;
>}
>
>If persons A and B both start with a particular sbox, and B calculates
>sibox = sbox^-1, then A sends s=encipher(q,r), then B can calculate
>q=decipher(s,r).
>
>Carefully note the number of inputs to each enciphering method.
But there are *two* stored values: x and y. If we accept x as the
first data input, the obvious approach would be to accept y as the
second data input. Two separate values used as inputs to computation
implies two separate data sources.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Serdar Boztas <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.theory,aus.mathematics,sci.crypt.research
Subject: AAECC 14, Melbourne, Australia -- Call For Summaries
Date: 2 Apr 2001 11:34:14 -0700
Applied Algebra, Algebraic Algorithms and Error Correcting Codes
=====================================================================
Updated Conference Homepage:
http://www.ma.rmit.edu.au/aaecc/index.html
List of Topics:
Algebra, Codes and Algebra, Codes and Combinatorics,
Modulation and Codes, Sequences, Cryptography.
The 14th AAECC Symposium will be held at Royal Melbourne Institute of
Technology (RMIT University) in Melbourne, Australia, on November 26-30,
2001.
Six prestigious invited speakers (R. Calderbank, J. Massey, V. Pless,
T. Recio, A. Shokrollahi, M. Sudan) will cover a range of topics
of interest.
The reviewing process of submitted papers is almost complete. The
outcome of this process is one of the 3 below:
1. Paper appears in Springer LNCS volume and AAECC conference
proceedings.
2. Paper appears in AAECC conference proceedings as a 2 page summary.
3. Paper is rejected.
You can now submit 2 page summaries of papers for conference
presentation.
These 2 page summaries will also appear in the AAECC conference
proceedings.
Papers should be formatted in 12pt type and not exceed 15 pages
including the bibliography. The title should contain the author's
name, address, a short abstract and a small list of key words.
The preferred submission mode is by e-mail.
Please submit (preferably Postscript) files by e-mail to:
[EMAIL PROTECTED]
Otherwise, please fax to:
Serdar Boztas
Department of Mathematics
GPO Box 2476V
RMIT University
Melbourne 3001, Australia
fax: ++61 3 9925 1748
--
Serdar Boztas, RMIT Department of Mathematics, Melbourne, Australia
http://minyos.its.rmit.edu.au/~rmasb/index.html <------ My Homepage
All the colours were soiling at the same speed,
White was given the first prize <----------- poetry by Ozdemir Asaf
http://www.cs.rpi.edu/~sibel/poetry <----------- Turkish poetry page
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 19:06:33 GMT
On Mon, 02 Apr 2001 17:47:59 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt Ken Savage <[EMAIL PROTECTED]> wrote:
>John Savard wrote:
>>
>> Data is now being XORed, not only with the quantity produced by the
>> RC4 PRNG, but with z, which is the previous ciphertext, substituted
>> for in the S-box.
>> quantity. However, that means it isn't a "data dependent arcfour" as
>
>It's not always simple to invent a short title that summarizes
>the entire article. I think that we can all agree that it is arcfour,
>it is data dependent, and that dependence is achieved through feedback
>involving the internal sbox :)
>
>It seems that you're right -- that since the swap() statement doesn't
>involve sbox[data], or anything pertaining to the data, most people
>here are agreeing it doesn't fall into the Dyn Sub patent *phew*.
It appears to me that a very good case could be made for the new
construction infringing the Dynamic Substitution patent.
The Dynamic Substitution patent simply does not require that swap()
involve sbox[data], or anything pertaining to the data.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 19:09:35 GMT
On Mon, 02 Apr 2001 14:09:50 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>On Mon, 02 Apr 2001 06:34:44 GMT, Benjamin Goldberg
><[EMAIL PROTECTED]> wrote, in part:
>
>>The patent does not apply to the proposed cipher, but for an entirely
>>different reason than the one Bryan Olson claimed.
>>
>>The proposed variant combines one single input stream of data with the
>>internal state of a cryptographic object, and produces as output one
>>single stream of data (and modifies the object's state).
>>
>>The Dynamic Substitution patent covers combining two input streams with
>>each other and with the state of a cryptographic object, and producing
>>one single output stream (and modifying the object's state).
>>
>>The difference between the proposal and the patent is the number of
>>input streams, one versus two.
>>
>>Here's the proposed modified RC4:
>>
>>byte x, y, z, sbox[256];
>>encipher(byte data) {
>> x = (x + 1) & 255;
>> y = (y + sbox[x]) & 255;
>> swap( sbox[x], sbox[y] );
>> data ^= sbox[(sbox[x] + sbox[y]) & 255] ^ z;
>> z ^= sbox[data];
>> return data;
>>}
>
>The first three lines implement the RC4 PRNG or something like it.
>
>Data is now being XORed, not only with the quantity produced by the
>RC4 PRNG, but with z, which is the previous ciphertext, substituted
>for in the S-box.
>
>So what we have is a straightforwards autokey. It does indeed lack the
>principal innovation of Terry Ritter's Dynamic Substitution.
While I can't speak to what "the principal innovation" might be, the
construction does appear to "read on" the Dynamic Substitution patent.
>That would have been: swap( sbox[...], sbox[data] ).
Since I have presented the actual claim 1 several times, I am stunned
to see this coming up again. There is no requirement in the claim for
any such thing. It simply is not there.
>One is simply
>using the modified S-box to carry out a conventional autokey, one is
>not modifying the S-box based on a plaintext or ciphertext related
>quantity.
It is the permutation of the S-box by two quantities which is the
problem. The patent does not require that one of the quantities be
based on plaintext or ciphertext.
>However, that means it isn't a "data dependent arcfour" as
>billed.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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
******************************
