Cryptography-Digest Digest #683, Volume #9 Wed, 9 Jun 99 22:13:03 EDT
Contents:
Re: what cipher? (David Wagner)
Re: being burnt by the NSA ("Douglas A. Gwyn")
Re: $1000 PASSPHRASE GENERATION CONTEST (JPeschel)
Re: what cipher? (David Wagner)
Re: being burnt by the NSA (John Myre)
Re: I challenge thee :) ([EMAIL PROTECTED])
Re: what cipher? ([EMAIL PROTECTED])
Re: being burnt by the NSA (Withheld)
High precision integer arithmetic (Withheld)
Re: being burnt by the NSA (John Savard)
Re: being burnt by the NSA (John Savard)
Jaws Tech's L5 Data Encryption Algorithm ("Chris")
Re: Does scott19u.zip make full use of it's large key size ? (SCOTT19U.ZIP_GUY)
Re: rc4 vs. rand() ([EMAIL PROTECTED])
Re: High precision integer arithmetic ([EMAIL PROTECTED])
Re: being burnt by the NSA ([EMAIL PROTECTED])
Re: Key lengths vs cracking time ([EMAIL PROTECTED])
Re: $1000 PASSPHRASE GENERATION CONTEST ([EMAIL PROTECTED])
Re: $1000 PASSPHRASE GENERATION CONTEST ([EMAIL PROTECTED])
Re: DES (Bruce Schneier)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: what cipher?
Date: 9 Jun 1999 14:00:47 -0700
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> Essentially. More usually called a combiner, come to think of it.
> There are several ways to wire up SR-based cryptosystems, but since
> I don't know of a public source for the information I can't describe
> them. Feel free to invent some.
Ok.
There's one example given at <http://jya.com/nsasuit2.txt> (scroll down
to find the ASCII art) of a NSA SR-based cryptosystem. Since the design
is (apparently) unclassified, I don't feel bad about discussing it here.
Basically, you take an incoming data bit and xor it against an output bit
from a 63-bit LFSR F; the resulting bit is xor-ed into a 14-bit NLFSR R;
both registers are stepped multiple times (it's not entirely clear, but
I'll assume they're stepped independently, with no feedback between them
except when you enter a data bit); and then you repeat. The number of
steps is classified (but may be 29, not that it matters much) and the
nonlinear feedback function for R is classified. There are also some
small extra details which I've omitted.
The algorithm is used as a MAC. The output is the high order 10 bits
of the R register, after all data bits have been processed. The key is
the initial fill of the registers.
This is an interesting design. If you try to squint funny at this until
it looks like an unbalanced Feistel design, for instance, you see that
the F register, for instance, prevents slide attacks by adding "round
dependence" of a sort (think of the F register as a "key schedule").
The multiple stepping adds a lot of avalanche and also makes it look
somewhat like a block cipher, and (probably more importantly) prevents you
from getting access to "before" and "after" snapshots of the R register's
feedback function by querying the algorithm with very short messages.
One of the very interesting features of this design is that (like e.g.
A5/1) it seems to require very few gates in hardware, which is great if
you are in a resource-limited environment.
I guess if I wanted to attack this and if I got to mount chosen-plaintext
attacks (assuming I don't get to desynchronize the endpoints or "reset"
the device to its initial key fill setting), I might try repeatedly asking
for the MAC of the one-bit message "0". Without the F register, this
would eventually reveal the transition diagram for the R register (after
about 2^14 queries), and then additional messages can be easily forged.
With the F register, I think you still might be able to get somewhere,
with an even larger number of queries. Let's first consider a simplified
version where the entire R register is revealed (not just its high 10
bits) and where the F register is stepped just once between data bits
(but the R register is possibly stepped multiple times). By the birthday
paradox, we expect to see some "matching" pairs of query outputs, where
by a "match" I mean that two conditions hold: (1) the R register contents
are the same for both queries, and (2) the next few bits of F output are
the same at both locations. When you have such a match, the R register
contents (i.e. the MAC output) for the next few subsequent queries
will also match. This is a readily recognizable condition. Also, it
gives you some information on the transition diagram for the R register,
and perhaps more importantly, it gives you a few bits of information on
the F register. With a few dozen such matches, you should be able to
recover the F register contents and reduce the problem to one without
a F register.
I think the same attack can also be generalized to the case where just
some of the R register is output. (You might need somewhat more queries,
because you'll need longer "matches".) Also, stepping the F register
multiple times doesn't really help, either, if you assume that the
F register output is suppressed (i.e. doesn't affect the R register)
during the multiple stepping process.
This style of attack could be prevented (it seems) by maintaining the
feedback from the F register to the R register even when no data bit is
present, during the multiple stepping process. (This might already be
part of the design -- it is hard to tell from the brief description in
the above web page.)
In any case, this style of attack may be relatively unrealistic, since
such chosen-text attacks should be readily detectable by the receiver
(if you assume that there is no way to desynchronize the endpoints or
"reset" the tamperproof device without setting off alarms and zeroizing
key material).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: Wed, 09 Jun 1999 21:02:04 GMT
Renegade wrote:
> > The total US national foreign intelligence program budget is about
> > $27 billion, of which about $3.1 billion goes to CIA and about
> > $3.6 billion goes to NSA. NRO gets about $6.2 billion.
> What is the source? Are budgets public information now? This looks
> like a shell game to me, those numbers seem to be way out of whack.
Why do we care how it seems to you?
The CIA did publish the total NFIP budget for FY97 and FY98.
The breakdown by agency comes from a public watchdog group,
which you could find for yourself, but it is fairly close.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: $1000 PASSPHRASE GENERATION CONTEST
Date: 9 Jun 1999 21:09:03 GMT
> [EMAIL PROTECTED]
>Two problems. One is that PGPDisk uses SHA-1 for the hash so you are
>forced to guess passwords. What is saying the password was not three
>hundred chars? Second problem is that how do we know you will make
>good on the money.
>Please don't post rubish.
Yup, Tommy, PGPDisk uses SHA-1 as a hash; and you are, indeed, forced
to guess passwords just as the subject header suggests. The details
of the contest are on the sponsor's page. I only link to it. You could
have looked first before posting.
I won't make good on the money -- it's not my contest. You may, however,
recognize the sponsor. Up to you whether you trust him.
Rubbish -- I've been reading and posting here for a fews years. Until
now no one has ever objected over a post about a cracking contest
or a crack. Now and then some of my other posts may have seemed,
for good reason, like they were written by a cantankerous, old
journalist, but I assure you I'm not *that* old.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: what cipher?
Date: 9 Jun 1999 14:11:20 -0700
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> > Suppose you take a NLFSR, use the plaintext as the initial fill, ...
> > ... Thus, I would claim that the "NLFSR" and the "unbalanced Feistel
> > cipher" are, in some sense, just two ways to view the same object.
>
> Well, no, just the particular way you "wired up" that NLFSR system.
> Other ways of doing it wouldn't be equivalent.
Fair enough. It's probably because I'm most comfortable with block
ciphers that I try to look at everything from that perspective, which
is admittedly not a very good basis for making such claims.
I guess in this case maybe I was trying to force a square peg into
a round hole. Thanks for keeping me honest.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: Wed, 09 Jun 1999 15:17:08 -0600
This sounds a lot like the Electronic Frontier Foundation
machine "Deep Crack" (their book is called "Cracking DES").
It isn't a load of bull; they actually built the thing and
used it at least twice, for RSA Labs' DES Challenges II and
III. (Of course, you could have a different book).
See, for example,
http://www.eff.org/pub/Privacy/Crypto_misc/DESCracker/
http://www.distributed.net/des/
http://www.rsa.com/pressbox/html/990119-1.html
John M.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: I challenge thee :)
Date: Wed, 09 Jun 1999 20:25:00 GMT
<snip>
Most 'polyalphabetic' ciphers are broken by frequency analysis if I am
not mistaken. If this is true all you have to do is understand the
language of the plaintext and you can guess at the key.
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: what cipher?
Date: Wed, 09 Jun 1999 22:07:38 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: David Wagner wrote:
:> The cryptanalysis problem looks much harder when the taps to the main
:> register are not known, or when multiple stages of this construction
:> are applied with differently-tapped registers. Who knows? Maybe such
:> an approach might prove secure, if sufficient care is taken.
: Actually, LFSR isn't particularly secure, and the taps can be found,
: although I don't think the methodology has been published. I was
: instead referring to the further generalizations of the idea, such
: as nonlinear combinators.
The methodology has been published more than a few times. IIRC,
one such was in _Machine Cryptography_ (?) by Deavours and
?Kruh?. But it's blindingly obvious after just a little
thought: it's a linear system, so all you need to do is
solve linear equations in GF(2), using 2n bits of the
unperturbed output bitstream from the LFSR. If you have
no access to a guaranteed unperturbed bitstream, then
you need to do more work (maybe 4n or 8n bits) to
try to determine the coefficients (equivalent to tap
positions) for the LFSR. Deavours and Kruh(?) don't
cover this explicitly, but it's an obvious extension.
--
Mike Andrews
Tired old sysadmin
[EMAIL PROTECTED]
------------------------------
From: Withheld <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: Wed, 9 Jun 1999 23:08:18 +0100
Reply-To: Withheld <[EMAIL PROTECTED]>
In article <7jmhgd$loq$[EMAIL PROTECTED]>, Renegade
<[EMAIL PROTECTED]> writes
>> The total US national foreign intelligence program budget is about
>> $27 billion, of which about $3.1 billion goes to CIA and about
>> $3.6 billion goes to NSA. NRO gets about $6.2 billion.
>
>What is the source? Are budgets public information now? This looks like a
>shell game to me, those numbers seem to be way out of whack.
>
>
I heard an interesting conspiracy theory that said the combined annual
budget of the NSA / CIA / FBI was something in the region of
$600,000,000,000. The theory reckoned they use a lot of it to dig big
holes in the ground, among other equally useful activities...
--
Withheld
------------------------------
From: Withheld <[EMAIL PROTECTED]>
Subject: High precision integer arithmetic
Date: Wed, 9 Jun 1999 23:13:25 +0100
Reply-To: Withheld <[EMAIL PROTECTED]>
Some time ago someone asked about high precision integer arithmetic, ie
wanting to perform calculations with large numbers without losing any
resolution.
If anyone is interested I've been tinkering with a long calculator that
does that sort of thing. Presently it works for numbers up to about 500
digits. I'm looking at getting decent error trapping and bigger numbers
to work but if anyone wants to take a look at it on an "as is" basis,
drop me an email (address in signature) and I'll mail it out. The file
is an ActiveX DLL so is only really useful on a Windoze platform.
If enough people want it I'll put it on a website somewhere.
--
Return address removed for anti-spam purposes.
Email replies to news at maelstrom dot demon dot co dot uk
Email replies to this address may be copied to relevant newsgroups
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: being burnt by the NSA
Date: Wed, 09 Jun 1999 22:20:48 GMT
Gordon Grieder <[EMAIL PROTECTED]> wrote, in part:
>I suggest reading Spyworld by Mike Frost, an ex-CSIS employee.
Ex-CSE.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: being burnt by the NSA
Date: Wed, 09 Jun 1999 22:18:20 GMT
[EMAIL PROTECTED] wrote, in part:
>> You also neglected to mention SHA-1, which is an NSA product and is
>> widely respected and trusted in the open-literature community.
>This is true. I am sorry Mr. NSA. I live in Canada what have they
>done for *me* lately? :) (Well in canada we have our Ceciss or
>something like that. Basically they are the unknown secret agents in
>Canada. Woowee!).
You're thinking of CSIS, which has no U.S.A. counterpart. Previously,
internal security matters were handled by the RCMP in Canada, just as
they are handled by the FBI in the United States, but now we have a
secret agency oriented domestically - a very dangerous thing.
The Canadian counterpart of the NSA is little known, although it
*does* have a web site: the CSE, or Communications Security
Establishment.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: "Chris" <[EMAIL PROTECTED]>
Subject: Jaws Tech's L5 Data Encryption Algorithm
Date: Wed, 9 Jun 1999 16:16:13 -0700
Has anyone heard of a sucessful attack on Jaws Tech's L5 Data Encryption
Algorithm? Information on the Company and products can be found at
www.jawstech.com
TIA,
Chris Brown
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Does scott19u.zip make full use of it's large key size ?
Date: Thu, 10 Jun 1999 02:19:16 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
Redburn) wrote:
>From what I can make out about scott19u.zip (which
>granted is not very much), it appears that
>one of it's main security features is the
>use of an incredibly large S-Box for subtitutions.
>
Well I guess this is true and you do want be to comment on this
yes it has a very large S-box however I belive tha I made it this large
on purpose. If you look at the scott4u.zip the S-box is based on a 4bit
s-table whichs is order of magnitudes shorter than the 19 bit table since
there are only 16 entries of 4 bit for a total of 32 bytes of data for the
table. This actaully gives you a method with 40 bits of keyspace. However
I made the scott4u.zip as a toy and actaully should have made it easer to
really use.
>From posts to this news group and the
>pages by Horst Ossifrage, I think the
>following facts are true about scott19u.zip
>(I think they are also true of his earlier ciphers
>but I'm only really considering scott19u.zip
>because this is the cipher David claims to be the
>strongest):
Yes I think it is the slowest
>
>1. The S-Box is guranteed not to have duplicate
> entries. This means (when considering only
> the substitution phase) that if two 19bit words
> of the cipher text are of equal value, then
> the corresponding plain text words will both be
> of equal value.
Well by defination the S-box is reverseable so
how could 2 entries go to the same values. I am
not sure what you are trying to drive at here. In
some coding methods where noise added the S-boxes
might be non reversable but to use the S-box as a
general encryption device it has to be reversible.
>
>2. The algorithm has very few passes.
it has more passes than IDEA but if you
consider any number less than 100 as small
for passes then it is small. I felt like I did more
than necessary.
>
>3. The S-Box is incredibly large. It contains all possible
> 19bit words.
Yes this is true.
>
>4. The key for the algorithm is only used for generating
> the S-Box. It is not used anywhere else in the
> algorithm.
Yes this is true
>
>(I hope David will correct any parts of this post that
>he considers incorrect - which because of the
>difficult nature of finding out about his algorithm,
>I'm sure there'll be some)
>
>Most people who would use encryption don't
>want or need to encrypt large files.
>
>For scott19u.zip to fully utilise the S-Box (note :
>this is less than fully utilizing the key, but that
>has been covered before), all entries
>in the S-Box must be used by the algorithm.
>Any not used, will not be needed to decipher
>the message.
Yes this is true.
>
>However, due to the small number of passes the
>algorithm makes, I think that it is very unlikely
>that even for files of half the size of the s-box,
>all the entries will be used.
I am not sure but I would suspect that for files
approaching even 25% of the size would use all
the S-table entries.
>
>For small files of a few K, only a very small proportion
>of the S-box will be used.
This is very likely
>
>Ah ! but doesn't it
>mean, because the plaintext is shorter than the key
>that decryption cannot be possible? You just wouldn't
>know which plaintext was correct if you found it?
This is also very likely if you mean there exist
other s-boxes that could decrypt the encrypted file to
more than one possible plain text solution.
>
>Well, maybe, but the fact that two identical words
>of cipher text can *only* be generated by two
>identical words of plaintext at each pass, combined by very few
>passes, must give a lot of information away.
No I think your missing something here if you take to
19bit portions of the file before a pass and if they happen
to be the same before the pass they will most likely be
diffferent after that pass. And when they go into the next
passes s-box they will be even less related.
>
>Has anybody else looked at this in detail, and who therefore
>could determine more accurately if this is a weakness ?
>
Tim to scare you even more. There is more than one s-box
that can solve the scott16u.zip contest. So one really does
not need to exactly solve for the s-box to get the correct
anwser. But you still would have to find one that matched
the four exact characters that I changed in the plain
text file. Maybe you can use this "weakness" to solve the
contest and win the money.
To win you don't have to use the same S-box I used
and since only 4 characters changed you might be able
to solve it by calling a psyhic 900 line or something,
I assume the NSA by know has found the solution or they
are being vastly over funded and should pay me to work
for them.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: rc4 vs. rand()
Date: Wed, 09 Jun 1999 23:45:51 GMT
> Yes all permutations are functions. However so is y= C and many
others. A
> permutation is a bijective map.
> which is a special case of functions -- what Brian is saying is that
the
> criteria is not MERELY that it is a function, but a bijection.
Bijective means any output is possible? But this is not the case, in
the sense of the sbox, only sbox[x]=y is possible. Unless you say that
the contents change. The output of RC4 is not related to the sbox as a
function. You can take sbox[sbox[x]]=x as the inverse of x, which
means the sbox is a one to one function.
> Not all Functions can be inverted. That is what brian is getting
at. I
> know that many of the corrections you are receiving seem pedantic and
small
> minded, but in crypto the devil is in the details -- a minor
misstatement
> in specing an encryption or discussing a result can result in some
huge
> misunderstandings.
All functions can be inverted, that is the definition, well at least
1:1 functions. Things like RSA for example are not 1:1 functions and
that is why they are secure (well for more then that...). Probably a
misunderstanding. It's true that any permutation must be bijective to
be secure...
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: High precision integer arithmetic
Date: Wed, 09 Jun 1999 23:51:22 GMT
<snip>
If you want simple bignums take a look at
www.dunfield.com
And pick up 'Micro-C PC 3.16'. It has an example (it should)
called 'Bignum.c' which is a demo of large number math. I have used it
with numbers >1024 bits but it is kinda slow.
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: being burnt by the NSA
Date: Wed, 09 Jun 1999 11:24:19 GMT
> You also neglected to mention SHA-1, which is an NSA product and is
> widely respected and trusted in the open-literature community.
This is true. I am sorry Mr. NSA. I live in Canada what have they
done for *me* lately? :) (Well in canada we have our Ceciss or
something like that. Basically they are the unknown secret agents in
Canada. Woowee!).
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Key lengths vs cracking time
Date: Wed, 09 Jun 1999 11:29:20 GMT
> What can I say to convince you of the value of assurance and
certainty,
> other than to suggest that you go look for some *rigorous*, non-
trivial
> lower bounds on the complexity of cryptanalyzing your favorite
ciphers?
I know what you are saying, and in fact I would trust a cipher that has
a high lower bound (DES). I just like debating things... :)
> Based on the criterion you seem to be using to judge ciphers, I guess
> you would not use 1024-bit RSA because it doesn't take 2^1005 steps to
> break.
Well no. I guess I put my foot in my mouth. I trust RSA or DH solely
because attacking it requires too much time and too much memory. The
TWINKLE machine for example still requires an enormous amount of memory
to work. In fact no personal computer can crack properly made RSA or
DH keys within this universes lifetime. Ooops.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: $1000 PASSPHRASE GENERATION CONTEST
Date: Wed, 09 Jun 1999 23:49:36 GMT
> Yup, Tommy, PGPDisk uses SHA-1 as a hash; and you are, indeed, forced
> to guess passwords just as the subject header suggests. The details
> of the contest are on the sponsor's page. I only link to it. You
could
> have looked first before posting.
Sorry, I didn't mean to offend you. What I should have said is that
cracking contests are not usually that worthwhile. Cracking algorithms
for example are much more usefull. If they said 'Crack SHA' then ok
that would be a worthwhile contest, but 'crack this message' is not
usually fruitful.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: $1000 PASSPHRASE GENERATION CONTEST
Date: Wed, 09 Jun 1999 11:31:42 GMT
> Help crack a PGPDisk passphrase.
> I've just added this contest to my
> site.
Two problems. One is that PGPDisk uses SHA-1 for the hash so you are
forced to guess passwords. What is saying the password was not three
hundred chars? Second problem is that how do we know you will make
good on the money.
Please don't post rubish.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: DES
Date: Thu, 10 Jun 1999 01:47:13 GMT
On Tue, 08 Jun 1999 09:03:35 GMT, [EMAIL PROTECTED] wrote:
>DES;
>1 That initial permutation; is it actualy worth anything
>cryptograpicaly?
No. They were put there to support the hardware implementation of
DES that was popular in the mid-1970s.
>2 The fixed s-boxes? Surely if they are known, they are worthless?
>Wouldn't it make more sense to have key dependant s-boxes?
It depends on whom you're talking about. It would make more sense to
a cryptanalyst to have key-dependent S-boxes in DES. DES with
key-dependent S-boxes is easier to break (in some attack models) than
DES with the existing known, but strong, S-boxes.
>I am new to this, so please don't attack me... I'm not being
>pretentious; i genuinely want to know how fixed s-boxes give any
>strength, and what the initial/final perms do.
There are dozens of papers in the academic literature on S-boxes and
cryptographic strength; you're not asking a stupid question. I have a
lot of references in Applied Cryptography, but there has been
considerable work done since then too.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
** 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
******************************
