Cryptography-Digest Digest #817, Volume #12 Mon, 2 Oct 00 19:13:00 EDT
Contents:
Re: is NIST just nuts? (Tom St Denis)
Re: is NIST just nuts? (Tom St Denis)
Re: is NIST just nuts? (Paul Rubin)
Do not vote for those communistic policies of Al Gore .... (William A. Nelson)
Re: Choice of public exponent in RSA signatures (David Wagner)
Re: is NIST just nuts? (Tom St Denis)
Related Key Attack on MyFish (Tom St Denis)
My Theory... (Cornelius Sybrandy)
Re: It's Rijndael (lcs Mixmaster Remailer)
Re: is NIST just nuts? (SCOTT19U.ZIP_GUY)
Re: What am I missing? (Scott Craver)
Key Attack on Serpent (Tom St Denis)
Re: Shareware Protection Schemes ("musashi_x")
Problem question (Ernest Dumenigo)
Re: Why is TwoFish better than Blowfish? ("Douglas A. Gwyn")
Re: Ciphers and Unicode ("Douglas A. Gwyn")
Re: Key Attack on Serpent (Tom St Denis)
Re: Choice of public exponent in RSA signatures (Bodo Moeller)
Re: It's Rijndael ("Douglas A. Gwyn")
Re: Comments on the AES winner ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Mon, 02 Oct 2000 21:45:58 GMT
In article <[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
> Tom St Denis <[EMAIL PROTECTED]> writes:
> > Well given that the requirement of a block cipher is primarily
> > security, i think the fact that Twofish is more secure makes my
> > complaint quite valid.
>
> Where is your evidence that Twofish is more secure? Apparently NIST
> and the NSA didn't think it was more secure.
Where is their evidence? From what we know Twofish appears much more
secure. Of course that's not scientific, but given what we can do,
it's the best we have.
They said "Rijndael performs well on a variety of platforms" but from
what I have seen Twofish does just as well. What is their
justification for not picking Twofish?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Mon, 02 Oct 2000 21:47:40 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] (alex) wrote in
<8rajuk$r1h$[EMAIL PROTECTED]>:
>
> >you could email monika lewinsky, she could perhaps ask the President
for
> >that.
> >
> >
> >Tom St Denis <[EMAIL PROTECTED]> a �crit dans le message :
> >8raips$vsd$[EMAIL PROTECTED]
> >> As if that was picked... From what I understand it's not at all
close
> >> to the securest block cipher. Will aes specify that cipher with
more
> >> rounds? What a shame...
> >>
> >> I demand a recount! Twofish should have won!
> >>
> >> Tom
> >>
>
> I guess Tommy still does not understand. Real security has
> little to do with the contest. I am not sure two fish is secure
> but the government has to pick a cipher the NSA could break or they
> would not allow it to be used. I just hope it modivates him to find
> a break. It is even possilble the NSA may yet want another alogorithm
> so we may magically see a break in this cipher or a weakness so that
> another one of there choice could be placed out there.
I doubt they picked Rijndael because it's ultimately insecure. I just
would have picked a cipher that resisted the cryptanalysis so far.
For all purposses Rijndael is still secure since 10 rounds cannot be
broken. But this parallels the arguments 30 years ago against short
keys...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: 02 Oct 2000 15:02:04 -0700
Tom St Denis <[EMAIL PROTECTED]> writes:
> > Is that so? Do you have a break for Rijndael but not for Twofish?
>
> Well I said earlier that in terms of practicallity Rijndael was not
> broken. But in that case why not just design a fast block cipher that
> takes say 2^60 work... cuz that's stupid?
Because it would not have satisfied the AES specification.
> Square was broken because of it's structure, the same attack works on
> Rijndael with limited success (7~8 rounds). Again the best attack
> against Twofish barely breaks half of the rounds.
A cipher is not broken unless an attack breaks all the rounds, or
looks like it can be extended from breaking only some of the rounds.
> At anyrate a block cipher is suppose to be secure, I would have enjoyed
> Serpent being picked over Twofish, but at the least Twofish.
I was also rooting for Twofish, but I don't think either one of us
is qualified to say Twofish is more secure or less secure than Rijndael.
------------------------------
From: William A. Nelson <[EMAIL PROTECTED]>
Subject: Do not vote for those communistic policies of Al Gore ....
Date: Mon, 02 Oct 2000 22:08:36 GMT
Do not vote for those communistic policies of Al Gore .... I do not
think that you and your property should be controlled by Al Gore's
communistic policies ....
William
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Choice of public exponent in RSA signatures
Date: 2 Oct 2000 22:27:49 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
John A. Malley wrote:
>The number e = 2^16 + 1 = 65537 is a reasonable choice for a small
>encryption exponent that minimizes the number of possible unconcealed
>messages when encrypting with RSA and SIMULTANEOUSLY allows the same
>message (or variations of that message) to be sent to a large number of
>different recipients while minimizing the threat of a specific attack
>(from Coppersmith) that relies on the same message (or a variation of
>that message) sent to a number of different recipients.
I must admit I don't understand this motivation too well.
In practice, real implementations of RSA encryption use a large
amount of random padding (see, e.g., OAEP). So long as you implement
it correctly, the Hastad and Coppersmith attacks are not a threat.
Perhaps it is a robustness issue -- you are worried that you
misimplemented the padding? -- but if so, it seems not as strong
a justification as what you mentioned in your post. Maybe it is
better to devote your effort to getting the padding right in the
first place; I don't know.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Mon, 02 Oct 2000 22:21:34 GMT
In article <[EMAIL PROTECTED]>,
David Schwartz <[EMAIL PROTECTED]> wrote:
>
> Tom St Denis wrote:
>
> > Well given that the requirement of a block cipher is primarily
> > security, i think the fact that Twofish is more secure makes my
> > complaint quite valid.
> >
> > Tom
>
> If security was the only factor, they could have picked any
cipher
> (almost) and just quadrupled the number of rounds. While security was
> allegedly the primary factor, it was never even claimed to be the only
> factor. Personally, I do believe that Rijndael has too few rounds.
Four
> more rounds would make me much happier.
Above all security is the primary concern. If Twofish and Rijndael
were "estimated" to have the same level of security then fine pick
Rijndael. But for all we know Serpent seems to be a more conservative
design. Hence Serpent would be more secure and satisfy the primary
goal much better.
Adding four more rounds to Rijndael may make it more secure, but lowers
it's performance, which means "why not pick Serpent or Twofish in the
first place?"
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Related Key Attack on MyFish
Date: Mon, 02 Oct 2000 22:24:54 GMT
In MyFish the round keys and sbox keys are made from the output of a 32
element LFSR (with 21 taps I believe). Doesn't this mean that linearly
related keys can be made to have identical (or of properties desired)
sboxes? I dunno if this can be used to attack MyFish but it certainly
isn't a super property to have.
Also I should check at the position the sbox bytes are generated to see
how many key bytes the sbox keys are a function of. If I understand
LFSR's right every output can be found (without stepping sequentially)
if you know the right linear combination of seed bits. This means that
the sbox keys (near the 160th output of the LFSR) could be a linear
function of only a few key bytes.
This means the LFSR "was/could be" a stupid idea right? Shame on me....
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Cornelius Sybrandy <[EMAIL PROTECTED]>
Subject: My Theory...
Date: Mon, 02 Oct 2000 18:43:44 -0400
Note, this is just a theory, not a reason for Tom to get nasty with me
(I too thought TwoFish was going to win).
I read a little of the reasons Rijndael was picked They felt that it
was the most consistant of all the candidates when it came to
performance and that it one of the most suitable for hardware. Also, I
believe it is also the only algorithm immue to timing attacks. Now, of
all of the ciphers, Rijndael was the one that scaled the best blowing
the others away on 64-bit architectures. This I think is one of the
keys. By being able to scale as well as it did, it allows the addition
of more rounds to improve security while remaining very fast on 64-bit
processors, which will become the norm.
Now, looking ahead into the far future (probably farther than NIST),
let's look at further scalability: 128-bit processors. Hell, the
Playstation 2 will have a 128-bit processor! I can only imagine what
throughput you'll get with Rijndael on that with a 256-bit block on
something like that. How far down the road are 128-bit chips? I don't
know, but I think (not sure here) that some of the new CPU's will have
128-bit MMX/SSE/3DNow/Whatever registers. I'll have to recheck, but I
think the multimedia registers in the Intel and AMD chips are 64-bit, so
I expect them to increase proportionally when the 64-bit chips come out.
The only other cipher that allowed for redefining blocksize was RC6, a
very elegant cipher, but it didn't scale as well. One reason for this
is that they still used 32-bit wordsizes when they did the testing. If
we were to benchmark RC6 and Rijndael with 256-bit blocks on a 64-bit
processor, I'm sure we would see some very different results.
Well, that's my theory. Do I believe that Rijndael is a suitable AES
winner? Yes. Do I believe it needs more rounds? From the evidence
I've seen, yes. I honestly believe that the standard should increase
the number of rounds especially since it appears it will not have a
great affect on the performance of the cipher on the up and coming
64-bit processors.
Enjoy.
csybrandy
------------------------------
Date: 2 Oct 2000 22:40:03 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
NIST has got its web site working again. The rationale document at
http://csrc.nist.gov/encryption/aes/round2/r2report.pdf has some
troubling aspects.
Pure cipher strength actually played very little role in the selection.
All the ciphers were judged adequately strong. Rijndael's main advantages
were in practical implementation issues, plus resistance to various
hardware failures.
Section 3.2 analyzes cipher strength. The results are summarized
in section 3.2.2. NIST explicitly rejects simple measures of cipher
strength which compare number of rounds attacked/broken against total
numbers of rounds. This single number is not always meaningful, but
it does give an idea of overall strength. NIST judged MARS, Serpent
and Twofish to have "high" security margin, and RC6 and Rijndael to
have "adequate" security margin.
Rijndael has attacks on 6 or 7 out of the 10 rounds for 128 bits keys;
7 out of 12 rounds for 192 bit keys; and 7, 8 or 9 out of 14 rounds for
256 bit keys (Rijndael uses more rounds for larger keys). The attacks
against larger numbers of rounds require prohibitive levels of work.
Apparently, NIST judged all ciphers adequately strong on this basis.
The decision as to which to pick was made on other grounds. Rijndael is
fast, easy to implement in hardware, and lightweight. These traits seem
to be what led to its choice.
For those whose primary interest in AES is high security, the emphasis
might have been placed elsewhere. Rather than choosing a cipher with
merely an "adequate" level of security, they would prefer that the
choice had been made from among those ciphers judged highest in security:
MARS, Twofish and Serpent. Choosing from among these ciphers by similar
criteria of efficiency would probably have led to Twofish.
Rijndael appears to be a compromise between security and efficiency.
This leaves us in an unhappy and uncomfortable position. It may well be
that Twofish and perhaps Serpent continue to be widely used alternatives
to AES.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: is NIST just nuts?
Date: 2 Oct 2000 22:38:49 GMT
[EMAIL PROTECTED] (Mark Carroll) wrote in
<8rb042$23d$[EMAIL PROTECTED]>:
>In article <[EMAIL PROTECTED]>,
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>(snip)
>>little to do with the contest. I am not sure two fish is secure
>>but the government has to pick a cipher the NSA could break or they
>>would not allow it to be used. I just hope it modivates him to find
>(snip)
>
>Uh? That's why they made DES more resistant to differential
>cryptanalysis by changing the S-boxes even though leaving it as it was
>would have given the NSA an advantage over the public in breaking it,
>as differential attacks weren't public knowledge then?
>
>-- Mark
They may have cleaned come some things up. But are your forgetting the
key size was lowered to be 56 bits. That alone made it easy for
them to break.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: What am I missing?
Date: 2 Oct 2000 22:36:39 GMT
Sagie <[EMAIL PROTECTED]> wrote:
>> Okay, but the idea of watermarking is that removing the scheme
>> requires distorting it into the ground. Sufficiently low parameters
>> will damage the music, and at that point you can keep the music.
>
>Obviously. Question is, what is their criterion for "low".
Indeed, quality standards are a real problem for watermarking.
Consumers still rent movies in VHS resolution. They'll happily
compress stuff well beyond what artists and professionals consider
fair quality. I guess people hope that going digital will make
people addicted to better resolution. First they'll all need to
upgrade to better speakers, tho.
>So does watermarking, as long as I pay the price for the product. I
>don't want anything that is deformed or defective.
I figure, if a consumer can not determine any difference
between regular and marked versions of a song by ear alone,
then it is not deformed or defective enough to be a problem.
If you're not willing to buy music deformed by a watermark,
then probably your ears are so sensitive that you won't be
willing to buy music that is MP3-compressed.
>> Here's a less stupid example: spread spectrum.
[...]
>> The watermark is detected by correlation.
>
>Yes but if the tweaking is so slight, you'll have to do it over a large
>portion so the correlation will have sufficient data to build up on.
It won't be used for computational reasons, but the portion
size is okay: SDMI marks must be detectible in a minimum of
15 seconds of music, and that's a freakin' lot.
> Either way, all compressions nowadays tweak frequencies (in fact, MP3
> files contain FFT representation of the music, which was maimed to fit
> in the bitrate).
Right, but that doesn't mean that spread-spectrum data-hiding
won't work. JPEG and MPEG also tweak frequencies, but a great
deal of really kick-ass data hiding schemes for images work in
the frequency domain.
The idea of spread-spectrum is not just working in the
frequency domain, but over such a huge chunk of it that it
is immune to "jamming" by various means.
>That's true, but the more damage the correlation suffers, the more
>signal it needs to correlate, and we're talking about finite-signals
>here.
The amount of data available is usually big enough not to be
the problem.
>Plus, the receiving end has got its limits, and were not talking
>about big video/picture editing stations, but normal computers and even
>portable audio devices, where resources are scarce and no one would
>sacrifice them to correlate a large chunk of audio for any
>organization.
This is usually the problem.
>> You can imagine this in theory, but not count on this in
>> practice. Stretch any image you own by 1% in width.
>> This is subtle and practically undetectable by most users,
>> w/o reference to the original. But no image compression scheme
>> will know to undo it. No image compression scheme will take
>> all images around 480 pixels wide and scale them to 480 pixels
>> to wipe out that undetectable change. Width is off-limits.
>
>Stretching the width will not benefit you anyway. This is not a
>watermark.
There are watermarks based on spatial distortions.
And attacks based on spatial distortions.
>Anyway, the point is not to "undo" the watermark, but rather
>to hurt the correlation enough so it would not be detected.
Very well, then still no image compressor will sufficiently
damage that subtle stretch that it could not later be detected.
[...]
>This is of course a general notation, because it should be performed
>for each bin of the FFT. Either way, doing this is stupid because once
>they'll decide on a certain method they'll have to publish it.
They don't necessarily have to. Quite possibly they will
keep the embedding method secret, rather than patenting or
publishing it.
At least, I wouldn't expect to ever find specs available
to the public from SDMI.
>Obviously. This is a tedious procedure, which is why I would wait for
>the specs.
Ah, but that's cryptanalysis for you. Lovely, lovely tedium.
>...and it will definitely not survive it... Come on... A copy
>machine??? Most of the times *I* can't make up anything from a copy
>machine copy.
The pioneering work by Cox et al exhibited an image watermark
that survived printing, running once through a Xerox machine,
then rescanning.
Later, they toned down this particular claim, because while
enough of the signal survived to be pretty certain, it wasn't
entirely fair to set the detector threshold low enough to catch
it, or perform the normalization necessary to show it's there
(invertibility attacks, after all, are possible with low
thresholds.
Other schemes, however, have followed in this tradition, and
the print-Xerox-scan manuever is occasionally used as a
benchmark for really robust schemes.
-S
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Key Attack on Serpent
Date: Mon, 02 Oct 2000 22:38:06 GMT
I just thought... why can't the same problem with MyFish be a problem
with Serpent?
Serpent uses a 8 element LFSR which means any on round key could be a
linear function of only a few key word inputs (say dependent on 64 bits
of the 256 bit key)...
Am I just nuts?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "musashi_x" <m u s a s h i _ [EMAIL PROTECTED]>
Subject: Re: Shareware Protection Schemes
Date: Mon, 2 Oct 2000 18:44:03 -0400
<snip>
> There is no private key in symmetric encryption algorithms such as
> Blowfish.
Actually my original thought was that I would separate the first 7
characters (yeah, bad phrasing, this isn't a pub/private key system) of
*the* key. Once reajoined with the key that I send the person (through a
Help/Register Box), it would unlock the extra features.
They could just cut and paste the key from e-mail, and it would only work
for their copy. I've really been getting helpful responses about possible
flaws in my logic, which was what I was looking for (there's ALWAYS
something ya didn't think of). Really, I don't expect this to be an
impenetrable defense, I would just like it to be harder than the average
protection to patch and to eliminate serial number distribution. By making
every copy a slightly different length, wouldn't that make it very difficult
to distribute a patch for it?
------------------------------
From: [EMAIL PROTECTED] (Ernest Dumenigo)
Subject: Problem question
Date: 2 Oct 2000 22:21:09 GMT
I've been working on some of the problems given in Military
Cryptanalytics, while reading it, and I am completely stuck on one of the
problems, and have not been able to solve it!!
The Plain text has been broken up into five letter groups, and each
letter put in alphabetical order in each group:
ORSUU ABIMR AEHNS ENSUV ADKOR ADEGM EEINN EMNVY EELSS S
What I have come up with (and don't know if its right or wrong) is:
Our submarine has ENSUV ADKOR ADEGM nine enemy vessels
Can anyone make sense of that middle part? Or am I completely off track?
--
=====
Ernest
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Why is TwoFish better than Blowfish?
Date: Mon, 02 Oct 2000 18:57:35 -0400
"SCOTT19U.ZIP_GUY" wrote:
> ... to keep people using poor compression so that ciphers which
> use a compression stage are easy to break.
As somebody who breaks ciphers, I object to that claim.
In general, *any* effective general compression method
applied to the plaintext before encipherment will make
the system *harder* to break than if compression had
not been used, for any reasonable enciphering algorithm.
If the encipherment is already sufficiently secure,
then precompression merely reduces the size of the
ciphertext while not increasing the likelihood of
successful cryptanalysis. (For it to be otherwise, the
encipherment would not be sufficiently secure for
certain plaintexts, contrary to supposition.) The loss
of redundancy in general interferes with cryptanalysis.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Ciphers and Unicode
Date: Mon, 02 Oct 2000 18:59:52 -0400
Ray Dillinger wrote:
> One basic issue I see is that if we start writing english with a
> 16-bit character set, ...
External text formats should be UTF-8 encoded, which is no
different from 7-bit ASCII for the characters in the ASCII
codeset.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Key Attack on Serpent
Date: Mon, 02 Oct 2000 22:45:03 GMT
In article <8rb2oe$eoc$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> I just thought... why can't the same problem with MyFish be a problem
> with Serpent?
>
> Serpent uses a 8 element LFSR which means any on round key could be a
> linear function of only a few key word inputs (say dependent on 64
bits
> of the 256 bit key)...
>
> Am I just nuts?
Yes you are tom... the nuttiest in the world.
Anyways my attack won't work because (8 choose 4) is larger then say (8
choose 2). What does that mean? It means on average four words (of
the LFSR) are used to make each linear output. It means my attack will
work with a low probability over all possible keys.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: Choice of public exponent in RSA signatures
Date: 2 Oct 2000 19:48:04 GMT
Francois Grieu <[EMAIL PROTECTED]>:
>> Are you sure ? Casual look at the user interface tells me PGP 2.63
>> by default use odd e of at least 17 bits (that is, at least 2^16+1).
>> Comments in the source seem to confirm it.
> On second though I am not so sure. The user interface of FatMacPGP.263
> does propose me 17 bits of e by default, and does generate keys
> with e = 2^16+1 when I do nothing special. Comments in the source code
> on one hand tell me the value taken from the user interface is the number
> of bits, and on another tell me the default and minimal value for the
> number of bits is 5 bits and that it can yield e = 17. Maybe the
> default size of e is not the same across all the 2.x versions ?
The user interface of the original PGP versions is that you invoke PGP
as 'pgp -kg' (for _k_ey _g_generation). Optional arguments, besides
'-u username', are the modulus length ('keybits') and the length of
e ('ebits'). Function dokeygen (in keymgmt.c) gets these as parameters.
If 'ebits' is not set, then the default value defined by the line
if (ebits==0) ebits=5; /* default is 5 bits long */
in rsagen.c is used.
On Macs ("#ifdef MACTC5") a function getRSAkeySize is called by
dokeygen (I don't know where getRSAkeySize is defined, I'm looking the
source code in pgp263is.tar.gz right now which does not appear to
include the complete Macintosh support). getRSAkeySize can set both
optional parameters, whereas the standard procedure just asks for the
kelength; so on Macs the default length of e might be longer.
If you have pgpacket (a Perl script that parses PGP packets), you can
use it to verify that 0x11 is indeed a typical e value in PGP keys.
If you have gnupg, try 'gpg -v -v some_keyring'.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Mon, 02 Oct 2000 19:03:19 -0400
Daniel Leonard wrote:
> On Mon, 2 Oct 2000, Serge Paccalin wrote:
> > Who remembers the original name of DES?
> Wasn't it Lucifer ?
No, Lucifer was a different, weaker system.
It did serve as a starting point for development of DES,
however.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Comments on the AES winner
Date: Mon, 02 Oct 2000 19:05:47 -0400
Anton Stiglic wrote:
> In a rump session talk at Crypto 2000, N. Ferguson
> (I believe it was) came up with an equation, in GF(2^8)
> I believe, stating that if one can solve this equation
> one can break Rijndael encryption. ...
> Someone knows what the equation was?
What's the point? *Any* block cipher can be expressed in
such an equation. It doesn't imply practical solvability.
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
