Cryptography-Digest Digest #655, Volume #11 Fri, 28 Apr 00 17:13:01 EDT
Contents:
Re: combine hashfunctions (Tom St Denis)
Re: factor large composite (Tom St Denis)
Another naive question (Mok-Kong Shen)
Re: factor large composite (Tom St Denis)
Re: ECC's vulnerability to quantum computing (Diet NSA)
Re: sboxes for the bored... (Tom St Denis)
Re: sboxes for the bored... (Tom St Denis)
Re: sci.crypt think will be AES? (Terry Ritter)
Re: Science Daily overstates significance? (NFN NMI L. a.k.a. S.T.L.)
Re: A naive question (NFN NMI L. a.k.a. S.T.L.)
Re: A naive question ("Trevor L. Jackson, III")
Re: Speaking of HD Overwriting... (NFN NMI L. a.k.a. S.T.L.)
Re: Karatsuba threshold (NFN NMI L. a.k.a. S.T.L.)
Re: sci.crypt think will be AES? (Vernon Schryver)
Re: Requested: update on aes contest (Diet NSA)
Re: The Illusion of Security ("Joseph Ashwood")
Re: sboxes for the bored... (Terry Ritter)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: combine hashfunctions
Date: Fri, 28 Apr 2000 19:16:05 GMT
Runu Knips wrote:
>
> Gregor Leander wrote:
> > I have a document M and two hash-functions h1,h2. So, what I use now as
> > a hash value (for signing for example) is (h1(M),h2(M)). It is clear,
> > that this is at least as strong as the strongest of h1,h2,
>
> Why is that clear ? Maybe its possible to construct two h1, h2 where
> h1 is easier to break, and breaking h1 gives informations about how
> to break h2 easier ?
If h1 and h2 are unrelated then this is obviously true. For example
SHA-1 || TIGER will give you a 160+192=352 bit hash, this composite hash
function is believed to be collision resistant iff h1 and/or h2 is
collision resistance. The resistances (in this case) is equal to a 352
hash (i.e O(2^176) to find a collision) iff *both* hashes are collision
resistant.
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://24.42.86.123/search.html, it's entirely free
and there are no advertisements.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: factor large composite
Date: Fri, 28 Apr 2000 19:18:26 GMT
Jeffrey Williams wrote:
>
> Your objection applies only to those for whom market economics apply
> (ie: you, me, business, etc). It doesn't apply to government, which does
> not aim to make a profit. A government may feel the need to have a
> large computer (say a Beowulf cluster, for example) to break codes for
> national security. That need may justify dropping <place insane quantity
> of cash here> on such a computer.
>
> Therefore, if you wish to keep your information secret from governments,
> etc, 768 bit RSA may be inadequate.
>
> Bottom line is that it really depends upon your adversary.
And the reality of the situation. Talk to Bob Silverman about the
memory required on avg to hold the matrix for the nfs of a 1024 bit RSA
style composite. Then tell me it depends on your adversary. I don't
know alot about the highest tech computers (this much is obvious) but
looking at the quotes and papers on the nfs I doubt that it could be
done at all right now.
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://24.42.86.123/search.html, it's entirely free
and there are no advertisements.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Another naive question
Date: Fri, 28 Apr 2000 21:27:21 +0200
Suppose one has a block cipher and two plaintexts of equal length
with
C1 = E(P1)
C2 = E(P2)
Let
C3 = C1 xor P2
Assuming that the opponent has no knowledge of P1, is C3 easier
or more difficult to analyze than C2 in general? Thanks.
M. K. Shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: factor large composite
Date: Fri, 28 Apr 2000 19:21:29 GMT
Johnny Bravo wrote:
>
> On Tue, 25 Apr 2000 19:52:03 -0700, "Dann Corbit"
> <[EMAIL PROTECTED]> wrote:
>
> >Also, I think the computer network cooperation approach would not be
> >terribly successful if the effort were focused to steal someone's money, so
> >the bazillion computers on the net metaphor won't work to solve the problem.
>
> Sure it would, you just don't tell the network what you are really
> doing. For example, SETI@Home is running at around 300% computing
> power. What if they had the client working on 2/3 of the computers
> trying to break Microsoft's bank codes. It would cost them almost
> nothing to do so, since the computing power is free and unused anyway.
> There isn't much need to check each SETI packet 3 times. :)
>
> Risk vs reward, sure the chances are next to nil that a large RSA
> key will be broken, but if the machines are going to be sitting idle
> anyway, why not have them trying to crack it? The cost is nothing,
> the payoff is huge, and if you get very, very lucky, you succeed.
You are missing a big point. Sure the sieving step of the NFS could be
done for 768 bit composites, however to actually store and manage the
matrix when you try to solve it will be a problem. This is why
factoring general composites > 500 bits is taking a long time.
At best we will have computers to somewhat meet the requirements
probably in 10 years or less. I dunno the exact requirements to factor
the number (check any paper on NFS).
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://24.42.86.123/search.html, it's entirely free
and there are no advertisements.
------------------------------
Subject: Re: ECC's vulnerability to quantum computing
From: Diet NSA <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2000 12:31:41 -0700
In article <8e6c94$fhq$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
>
>Bruce Schneier's Nov.1999 Crypto-Gram states that ECC's are
based on
>discrete logarithms, yet he mentions that most modern factoring
>algorithms are nearly similar to discrete logarithms. Does this
hold
>true for reversible quantum algorithms?
I'm not sure what you mean specifically by stating that "most
modern factoring algorithms are nearly similar to discrete
logarithms". Along with his factorization result, Peter Shor
demonstrated that discrete logs can be solved in random quantum
polynomial time.
>
>Intuitively, I would assume that ECC does not hold up either,
but it
>seems that because of its relative strength at the same key size
to RSA,
>maybe if it doesn't, it would still last longer at least,
although at
>that point it might be like putting the milk back in the bottle.
Your intuition is correct. Also, IIRC, in the original Shor
paper solving discrete logs is not accomplished quite as
efficiently as factoring. You should read this abstract [which is
only one paragraph long] which mentions the authors' contention
that the discrete logarithm problem can be done efficiently over
any group including Galois field & elliptic curves :
http://theory.stanford.edu/~dabo/abstracts/quantum.html
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: sboxes for the bored...
Date: Fri, 28 Apr 2000 19:35:25 GMT
Terry Ritter wrote:
>
> On Wed, 26 Apr 2000 16:29:03 GMT, in <[EMAIL PROTECTED]>, in
> sci.crypt Tim Tyler <[EMAIL PROTECTED]> wrote:
>
> >[...]
> >Large s-boxes take up too much space in hardware, and chew up your cache
> >in software.
>
> An 8-bit s-box only takes 256 bytes.
>
> >It seems to me that using a potentially large number of
> >small s-boxes seems to have some advantages over it:
> >
> >It is practical to test them for non-linearity; and offer guaranteed
> >minimum levels. When creating a single large s-box, real-time testing
> >is impractical and thus there's still a /chance/ of linearity (and thus
> >of weak keys).
>
> Well, testing is fairly quick even at the 8-bit level. But the point
> is that we *don't* have to test 8-bit tables: We use multiple of them
> and so make the probability of linearity far smaller than the
> probability of choosing the correct key at random.
>
> >If you use enough independent small s-boxes in series the resulting system
> >can still be made quite strong.
>
> Chaining substitutions in sequence just produces another substitution.
> No possible sequence of 4-bit substitutions can be any different than
> some other 4-bit substitution.
>
> And no 4-bit substitution has a nonlinearity over 4. That means that
> changing only 4 bits in the Boolean function for some bit position
> will yield a linear Boolean function.
What is the min/max bounds for a non-linear 'n' bit function? Like for
a 4x4 sbox it's -4/4, for an 8x8 it appears to me to be -32/32.
> In contrast, it is difficult to even *find* an 8-bit substitution with
> a nonlinearity below 78.
When you say "nonlinearity" do you mean the output from the WT? Because
I can easily get sboxes bounded to -32/32 (output from the WT) with my
program. Either I am misunderstanding something, or we are using
different algorithms.
>
> >If you use a small number of them the
> >system can be made quite small and fast. Use of a single large s-box does
> >not appear to offer you a simple way to trade-off between strength
> >and performance.
>
> But 4-bit tables have almost no strength at all. In contrast, each
> 8-bit table has almost enough nonlinearity on its own to be a cipher,
> were nonlinearity the only issue.
This is not true, since Serpent uses 4x4 sboxes and it's completely
immune (as we know it) to standard diff and linear cryptanalysis. So is
GOST (although no sboxes were ever standardized).
> That said, I have demonstrated ways to increase the nonlinearity of
> small tables by using two small tables and mixing their outputs in
> Balanced Block Mixers. So we might use small tables, at the cost of
> more tables and another layer of mixing.
If 4 bits goes in, and 4 bits comes out, it's a 4x4 sbox. If you are
talking about using two 4bit inputs and mixing them, then you
essentially are making a 8x8 sbox using 4x4 which is a cool idea.
> >If you could easily vary the size of the s-box this might be less of an
> >issue - but if you only have one s-box you can't change its size without
> >changing the number of inputs or outputs - which typically has knock-on
> >effects elsewhere in your design.
>
> Personally, I *never* have only one s-box. I believe in having many
> such structures, and in generating them from the key. When used in
> stream cipher combiners, I generally select from among multiple tables
> "at random" (that is, using the keying sequence).
Well in software it's easy (for example) to store 1024 4x4 sboxes, and
to pick (say) eight per key. You could even make them at run time (my
source takes 2 seconds to make 1024 4x4 sac (4/-4) sboxes). Just have
the key seed a prng which makes sboxes and test them. At most you can
spend 50ms or so on a decent desktop making sboxes...
Hmm gives me an idea, make a cipher like GOST that makes four 8x8 sboxes
based on the key (which is fed into a prng). The keysetup would take at
most 5 seconds using the naive random method, but would be hard to
analyze I think. Or revert to 4x4 sboxes (keysetup would take under a
ms)...
Just some more thoughts...
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://24.42.86.123/search.html, it's entirely free
and there are no advertisements.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: sboxes for the bored...
Date: Fri, 28 Apr 2000 19:43:59 GMT
[EMAIL PROTECTED] wrote:
>
> Is it pssoble to combine F functions together to make a stronger
> non-linear S - Box:
>
> e.g.
>
> Yi = Xi .OR. F(F1,...Fn)
>
> where F(F1...Fn) = F1(K1,Xi+1).OR.F2(K2,Xi+1)...Fn(Kn,Xi+1)
>
> either an OR or ¦ or some other non-linear combination....
>
> How would that work?
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
If I had two 4x4 sboxes A and B, and just did this C(a,b) = A(a) ||
B(b), where A(a) becomes the upper four bits and B(b) becomes the lower
four bits, you get a very weak sbox. You have to have some intermitent
stage... Try something like
(a, b)
for i = 0 to n
a = a xor B(b)
b = b xor A(a)
next n
Again the output could be weak, which is why the resultant sbox has to
be tested. Why would you want todo this? Hmm.. well you can simply
store the two 4x4 sboxes and use them at runtime (say loads of ram), iff
you test the resultant sbox first.
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://24.42.86.123/search.html, it's entirely free
and there are no advertisements.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: sci.crypt think will be AES?
Date: Fri, 28 Apr 2000 19:59:26 GMT
On Fri, 28 Apr 2000 10:36:01 -0700, in <[EMAIL PROTECTED]>,
in sci.crypt Roger <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>> The reality is that an inventor may not know whether
>> an AES design infringes. As a crypto patent holder, I certainly have
>> spent no time at all thinking of AES infringement. And as far as I
>> know, I cannot be required to spend time and treasure addressing some
>> possible future NIST standard.
>
>Right, you cannot be, but you may be forgoing your rights.
>
>As a practical matter, you will have to goto court to enforce
>your patents. You will look very silly when you argue:
>
>1. You applied for a patent because you thought you had
>something new and unique, and yet you cannot easily recognize
>whether someone is using your invention.
First, I doubt that any AES entrant uses any of my techniques:
Dynamic Substitution is mainly a stream-cipher technique, and both
Balanced Block Mixing and Variable Size Block Ciphers seem too radical
for conservative designers to propose. My casual look at the first
AES proposals suggested that most were basically Feistel ciphers, but
I haven't gone much beyond that.
Since I already have patents, I don't have to *argue* that I *thought*
I have something new and unique; that has been confirmed.
And I don't find it at all unusual for an inventor to not immediately
or in a legally conclusive sense recognize that a different
construction may infringe the legal grant. One can have all sorts of
opinions, of course, but we are talking about property ownership,
rights, testimony, lawyer fees, court time and other serious stuff.
This is not something that should be casually addressed.
Nor is this secret stuff which requires the personal attention of the
inventor: *Anyone* can analyze the AES proposals versus issued
patents and come to a conclusion. I suspect that the inventor's
analysis is not really what is desired: What they want is a final
decision, on their time schedule, so they can be assured the patent
holder won't sue. But since it is unlikely that any holder could
provide such a decision without costly technical and legal analysis,
if that is what they want, perhaps they should pay for it. Even then,
though, the patent could be sold, and *that* holder just might have a
different opinion.
>2. You had an opportunity to stop infringement, but chose
>not to (for whatever reasons).
Well, I *may* have the opportunity -- *IF* I spend time analyzing
multiple designs which probably will not be standards. But even that
only works if the designs clearly do or do not infringe, a question
which is as much legal as technical and thus requires legal services.
I certainly do *not* have that opportunity based on a casual glance.
On the other hand, if there is infringement, both NIST and the
manufacturers *also* have the opportunity to stop it before it starts:
simply do not infringe. The patent literature is open for their
review. If they choose to infringe anyway (for whatever reasons),
they will look kind of silly claiming either lack of knowledge or
permission based on a lack of response to no direct contact.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (NFN NMI L. a.k.a. S.T.L.)
Subject: Re: Science Daily overstates significance?
Date: 28 Apr 2000 20:09:00 GMT
<<As far as I understand it, this technique, if implemented, could
permit secure session key distribution without public-key
methods--methods which *may* eventually succumb to computational
power. >>
The first statement is right. The second sort of isn't. Quantum computing, as
I understand it, allows factoring to be done in polynomial time, but it's still
slower than multiplication. At worst, if I remember correctly, it does not
spell the death of RSA, just the arrival of larger keysizes. And symmetric
keysizes will have to be doubled, I think.
-*---*-------
S.T. "andard Mode" L. ***137***
STL's Wickedly Nifty Quotation Collection: http://quote.cjb.net
------------------------------
From: [EMAIL PROTECTED] (NFN NMI L. a.k.a. S.T.L.)
Subject: Re: A naive question
Date: 28 Apr 2000 20:12:27 GMT
If you have, (I don't like 56) 256 bits of cryptographically secure random
bits, then they can be used as an OTP. Or they can be used as the key to a
symmetric cipher (block or otherwise) that is "unbreakable" in that its only
weakness is to brute-forcing. In that case, the longer the message encrypted,
no weakness appears because of the definition of the cipher. Real ciphers will
tend to leak more and more information as the amount of ciphertext generated
increases.
-*---*-------
S.T. "andard Mode" L. ***137***
STL's Wickedly Nifty Quotation Collection: http://quote.cjb.net
------------------------------
Date: Fri, 28 Apr 2000 16:26:23 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: A naive question
"NFN NMI L. a.k.a. S.T.L." wrote:
> If you have, (I don't like 56) 256 bits of cryptographically secure random
> bits, then they can be used as an OTP. Or they can be used as the key to a
> symmetric cipher (block or otherwise) that is "unbreakable" in that its only
(known)
>
> weakness is to brute-forcing. In that case, the longer the message encrypted,
> no weakness appears because of the definition of the cipher. Real ciphers will
> tend to leak more and more information as the amount of ciphertext generated
> increases.
>
> -*---*-------
> S.T. "andard Mode" L. ***137***
> STL's Wickedly Nifty Quotation Collection: http://quote.cjb.net
------------------------------
From: [EMAIL PROTECTED] (NFN NMI L. a.k.a. S.T.L.)
Subject: Re: Speaking of HD Overwriting...
Date: 28 Apr 2000 20:19:04 GMT
<<It's more complicated than that. The write laser melts the metal under a
nonmelting
transparent layer.>>
I thought CD-RWs were made of some organic compound, not metal. I forget what
CD-Rs are made of.
<<The actual area that is melted is close to the wavelength of the laser,
so the very idea of "missing" or "hitting" the spot is fuzzy - you need to get
into
the quantum behavior to understand what is going on.>>
I don't understand this objection. The wavelength of visible light, from 400nm
to 800nm (and CD lasers are red, if I remember, so that's 800nm), in other
units, is .4 to .8 microns. Quantum behavior in solid stuff isn't _too_
apparent at this scale, right? After all, transistors don't get all leaky
until you hit .01 micron or thereabouts. So my original thought remains: the
very outer edge of the area affected by the laser will not be as heated as more
central parts of that area. On rewriting, jiggling of the laser, etc, may
cause the laser to miss those outer edges and not melt the entire previous
area. Similar to how a HD head may not remagnetize the entire area that
constitutes a bit (actually, it's a perfect analogy). ....Right?
-*---*-------
S.T. "andard Mode" L. ***137***
STL's Wickedly Nifty Quotation Collection: http://quote.cjb.net
------------------------------
From: [EMAIL PROTECTED] (NFN NMI L. a.k.a. S.T.L.)
Subject: Re: Karatsuba threshold
Date: 28 Apr 2000 20:22:27 GMT
I believe that FFT multiplication is _the_ method of choice for multiplying
huge-ass numbers, but this is only due to my knowledge of the Lucas-Lehmer
test. (Prime95.exe squares 10-million-bit numbers modulo another 10-million
bit number.) Perhaps FFT is not as efficient as other algorithms when you're
not doing the mulitplication modulo a Mersenne number, but the side benefits it
provides in Lucas-Lehmer testing makes it the best for Mersenne primality
tests.
-*---*-------
S.T. "andard Mode" L. ***137***
STL's Wickedly Nifty Quotation Collection: http://quote.cjb.net
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: sci.crypt think will be AES?
Date: 28 Apr 2000 14:28:01 -0600
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> ...
>Since I already have patents, I don't have to *argue* that I *thought*
>I have something new and unique; that has been confirmed.
>
yeah, confirmed by the same experts who determined that
http://patent.womplex.ibm.com/details?&pn=US05446889__ and
http://www.patents.ibm.com/details?&pn=US06025810__&s_all=1#23
are new and unique. 6025810 looks like a somewhat but not entirely
new or unique to me idea, but I can't see how anyone skilled in the art
might think 5446889 is new or unique.
In other words and not merely because of those two stellar examples, anyone
who points to their name on a patent as proof that they came up with
something new or unique might have invented something, but certainly has
personal problems. It's possible that those problems are merely abject
ignorance of the de facto purpose and functioning of the patent system
but probably not. The problems usually start with misunderstanding the
concepts of new and unqiue and continue to difficulties that need
professional attention or at least extended private reflection.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
Subject: Re: Requested: update on aes contest
From: Diet NSA <[EMAIL PROTECTED]>
Date: Fri, 28 Apr 2000 13:38:35 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bruce Schneier) wrote:
>I strongly second this. The NIST process is not a scientific
one.
>They are soliciting comments from the community. Everyone who
has
>comments--about the algorithms, the number of algorithms, the
process
>in general, anything--should submit them to NIST.
>
Besides NIST, are other government or military groups (e.g., NSA,
FBI, etc.) involved in the AES process? For instance, do they
advise or provide other kinds of info to NIST?
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Fri, 28 Apr 2000 13:38:21 -0700
> I doubt they restricted the keysize to protect the
citizens.
Actually that seems to have been at least a sideeffect of
what they did. They reduced he key size to match the level
of security. What is it about this that you don't
understand?
Joe
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: sboxes for the bored...
Date: Fri, 28 Apr 2000 20:42:23 GMT
On Fri, 28 Apr 2000 19:35:25 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>>[...]
>> And no 4-bit substitution has a nonlinearity over 4. That means that
>> changing only 4 bits in the Boolean function for some bit position
>> will yield a linear Boolean function.
>
>What is the min/max bounds for a non-linear 'n' bit function? Like for
>a 4x4 sbox it's -4/4, for an 8x8 it appears to me to be -32/32.
>From the Glossary:
http://www.io.com/~ritter/GLOSSARY.HTM#BooleanFunctionNonlinearity
Boolean Function Nonlinearity
'The number of bits which must change in the truth table of a
Boolean function to reach the closest affine Boolean function. This
is the Hamming distance from the closest "linear" function.'
A "4-bit" table has 16 entries; it thus contains 4 different Boolean
functions of 16 bits each. Each of those have a nonlinearity, and we
use the lowest value to represent the whole table. At 4 bits, the
greatest possible nonlinearity is 4 (not -4). A real 4-bit table may
also have a nonlinearity of 2 or even 0 (an actual linear function).
An "8-bit" table has 256 entries, with a typical nonlinearity of 100.
That means some 100 bits (out of the 256 in a single Boolean function)
must be changed to get to the closest affine Boolean function.
See, for example:
http://www.io.com/~ritter/JAVASCRP/NONLMEAS.HTM
>> In contrast, it is difficult to even *find* an 8-bit substitution with
>> a nonlinearity below 78.
>
>When you say "nonlinearity" do you mean the output from the WT? Because
>I can easily get sboxes bounded to -32/32 (output from the WT) with my
>program. Either I am misunderstanding something, or we are using
>different algorithms.
Yes, and yes. Measuring Boolean function nonlinearity is well-known
technology. If you don't get the same results as my JavaScript page,
you are probably doing it wrong.
>> >If you use a small number of them the
>> >system can be made quite small and fast. Use of a single large s-box does
>> >not appear to offer you a simple way to trade-off between strength
>> >and performance.
>>
>> But 4-bit tables have almost no strength at all. In contrast, each
>> 8-bit table has almost enough nonlinearity on its own to be a cipher,
>> were nonlinearity the only issue.
>
>This is not true, since Serpent uses 4x4 sboxes and it's completely
>immune (as we know it) to standard diff and linear cryptanalysis. So is
>GOST (although no sboxes were ever standardized).
"...were nonlinearity the only issue."
>> That said, I have demonstrated ways to increase the nonlinearity of
>> small tables by using two small tables and mixing their outputs in
>> Balanced Block Mixers. So we might use small tables, at the cost of
>> more tables and another layer of mixing.
>
>If 4 bits goes in, and 4 bits comes out, it's a 4x4 sbox. If you are
>talking about using two 4bit inputs and mixing them, then you
>essentially are making a 8x8 sbox using 4x4 which is a cool idea.
Block ciphers are just simulated huge Simple Substitutions. So if we
can create the characteristics of a large block from a small one, we
can make a cipher. I have shown (see:
http://www.io.com/~ritter/ARTS/VSBCNONL.HTM
) how to use several keyed half-size substitutions to simulate a keyed
full-size substitution. Then we wind that down recursively to the
size table we want to use.
>> >If you could easily vary the size of the s-box this might be less of an
>> >issue - but if you only have one s-box you can't change its size without
>> >changing the number of inputs or outputs - which typically has knock-on
>> >effects elsewhere in your design.
>>
>> Personally, I *never* have only one s-box. I believe in having many
>> such structures, and in generating them from the key. When used in
>> stream cipher combiners, I generally select from among multiple tables
>> "at random" (that is, using the keying sequence).
>
>Well in software it's easy (for example) to store 1024 4x4 sboxes, and
>to pick (say) eight per key. You could even make them at run time (my
>source takes 2 seconds to make 1024 4x4 sac (4/-4) sboxes). Just have
>the key seed a prng which makes sboxes and test them. At most you can
>spend 50ms or so on a decent desktop making sboxes...
And if one uses the fundamentally far stronger 8-bit boxes, setting up
still should be fast. See:
http://www.io.com/~ritter/KEYSHUF.HTM
---
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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
