Cryptography-Digest Digest #775, Volume #11 Mon, 15 May 00 02:13:01 EDT
Contents:
Re: Unbreakable encryption. ([EMAIL PROTECTED])
Re: S-BOX Construction Tutorial? (John Savard)
Re: S-BOX Construction Tutorial? (John Savard)
Re: Unbreakable encryption. ([EMAIL PROTECTED])
Re: Unbreakable encryption. ([EMAIL PROTECTED])
Re: Encryption of graphics by transposition (wtshaw)
Re: S-BOX Construction Tutorial? (Mok-Kong Shen)
Re: Notes on the "Vortex" block cipher ([EMAIL PROTECTED])
Re: S-BOX Construction Tutorial? ("Scott Fluhrer")
Re: Unbreakable encryption. (wtshaw)
Re: S-BOX Construction Tutorial? (Mok-Kong Shen)
Re: AES Comment: the Hitachi patent (Mok-Kong Shen)
Re: S-BOX Construction Tutorial? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Unbreakable encryption.
Date: Mon, 15 May 2000 04:17:19 GMT
My post must have been unclear to you. Let me explain in another
way.
You need not use 16=F, you can remap 17=F, or 104=F or 222=F
or anything for that matter. This is called symbol remapping.
Its supported in the calc if you are interested in testing it.
Also, you seem to have missed the major point... Fixed keylength
cyphers and fixed symbols table cyphers can be brute force searched.
the keys decryption and encryption are symmetric. Whereas, using
base encryption, you don't even have something to brute force search
through.
1) You don't know the algorithm used (its dynamic), so you
don't have a starting point.
2) You don't know the base, so you also don't have a starting point.
Lets say I give you this...
oisdd9823oieoisdg08eojiweljf##@98oefji23#@2jf
In or whatever, what you would do is start permutating the
keys (lets say 56 bit) starting at
0000000000 0000000000 0000000000 0000000000 0000000000 000000
and end at
1111111111 1111111111 1111111111 1111111111 1111111111 111111
You pipe this through the fixkeylengh cypherblock, and eventually
you will get your decoded message.
Well, lets say I gave you the same message encrypted using
BASE encryption.
Where do you start? You don't know whether
oisdd9823oieoisdg08eojiweljf##@98oefji23#@2jf
is base 100 or base 200 or any base for that matter. Remember,
just one increase in the base (symbol space) changes the answer in the
cyphertext. This involves not just standard mappings, (like you are
used to 16=f). You can remap the input and output characters.
But then you also forgot about the algorithms that are applied to it.
It can be considered an encryption algorithm because
1) It does symbol substitution for remapping (which is the most basic
form of encryption. I think Ceasar used it)
2) It uses base conversion (or any algorithm you can think of) for
basic base conversion (symbol conversion)
3) It uses any combination of operatiors as the actual heavy duty
encryption. (you can use rotation, shift, add, subtract, invert,
a compression algorithm, ANYTHING).
Which means what? It is more secure than DES or Blowfish without
even the different symbols space (base). That is because
the Base encryption algorithm used is dynamic, it can be changed on the
fly. Whereas all the other cypherblock encryptions use standard
routines (rotate, xor, etc) in a fixed sequence.
Remember, dynamic algorithm is more secure than static algorithms.
You seem to misunderstand the major point....
ALL the algorithms and ALL the keylengths of ALL the encryption
systems are static. This is the most unsecure
part. It is the weak link for brute force searches.
And to answer your n-bits input and n-bits output. Think of it
this way... it will clearify my point.
What is the symbol set used before the compression to n-bits?
What is the symbol set used to decompress the n-bits back to regular
text?
They are the same aren't they?
And they are both N bits right?
And you have to break up the message into n-bit size to feed
it into the cypher block right?
So in essense the compression algorithm is basically taking the
same symbol base and compacting it.
Well, you can do the same thing before feeding it into BASE
encryption (it will make it even more secure).
Base encryption can be augmentative, and go on top of or below
existing algorithms if you think universally about it.
Also. BASE encryption is not n-bits, its not fixed. You can FEED
THE WHOLE MESSAGE INTO IT AT ONCE. It is DYNAMIC bits.
The bit size is variable, affected by BASE (symbol set), algorithm
used before and after base conversion (or any other conversion).
So let me repeat...
given...
oisdd9823oieoisdg08eojiweljf##@98oefji23#@2jf
How do you start decrypting it using Base encryption?
You can't right? You have to guess
1) The Base of this message (now did he use base 26? or standard
ASCII, or some large base with duplicates? or a chinese unicode?)
(And is this the result of base 26 or some other base?)
2) What is the conversion algorithm used to remap between the above?
3) What is the actual algorithm used. (shift, rotate, add, 1/x)
and was it before base conversion or after?
In essense, you CANT start anywhere. Because the algorithm is
dynamic (its exponential, even more so than the standard key remapping)
So let me repeat...
given...
oisdd9823oieoisdg08eojiweljf##@98oefji23#@2jf
how do you decrypt it?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 04:31:57 GMT
On Mon, 15 May 2000 02:09:39 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>What are you talking about?
>Every enciphering has some key. Any opponent might just try that key
>at random. Does that make the cipher weak? Does that make the
>keyspace non-flat?
>Similarly, if we construct S-boxes such that they are a "random"
>selection from among the universe of such S-boxes, does the fact that
>one of these is the "identity transformation," others are close, and
>many are somewhat linear make any difference at all (assuming the
>universe of possible S-boxes is "large enough")?
Actually, the fact that some S-boxes are close to being linear, while
others are not, does mean that some keys are "better" than others in a
way that is not applicable to a cipher like DES. (Although DES does
have weak keys for another reason.)
This has been used as a reason - or as an excuse - for not using
key-dependent S-boxes in ciphers.
Given a reasonable amount of known plaintext, if a cipher is designed
so that its security depends on having S-boxes that are random, but it
happens that the key being used has produced nearly linear S-boxes,
then in that case there will likely be a detectable pattern. This is a
danger, a source of unpredictability. It would be better to have a
cipher that was equally secure whatever the key - of course, any key
might still happen to be the one the opponent will try first, but that
involves a much smaller number of cases.
There are, of course, two easy remedies. One is to make the
probability of S-box failure vanishingly small, and the other is to
have other elements in the cipher that maintain its security even in
that case. Another possibility is to choose a method of S-box
generation that avoids "bad" S-boxes; the problem there is that often
methods to do this are chosen that are too simplistic.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 04:33:40 GMT
On Mon, 15 May 2000 02:37:52 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote, in part:
>Replace the sboxes with ones from CAST and you have a 'more' secure
>block cipher.
Well, you eliminate one attack, but with known S-boxes, surely you are
now admitting many others.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Unbreakable encryption.
Date: Mon, 15 May 2000 04:26:11 GMT
Thank you cow, you have given me appropriate publicity.
Here is more...
A New language...
The evolution of languages started first with load/store primative
operations for the CPU. This led to assembly which was basically a
labeling system for the actual numbers the cpu understands. When you
have labels, people created an abstract macro layer above that so that
it produced multiple assembly labels to be compiled into machine code.
This is basically what Basic and Fortran, and Colbol did. But as the
languages became longer and longer, people started inventing ways to
package some of the often used routines, and created the concept of a
method (java), function (c), procedure (pascal), subroutine (basic and
perl). They are basically a way store often used instructions for the
cpu into nice place (label it), and call it anytime you want. But
since these functions usually need information passed into it to work,
pass by reference and pass by value became the norm, and was
incorporated into the language. Usually
when a function is called, the calling function stores the passed
values on a stack (a separate place in memory). The called function
then take these values from the stack and diddles with them. When it
is done, it return usually one value (either a reference or value) by
placing it back on the stack, and the caller then takes it off of the
stack. To make it consistent, and less error prone, some languages
invented the concept of a prototype, which basically says, this
function can only take in 4 passed parameters of type integer, and
return type char, etc etc. Up to this point you have C and pascal.
Then someone comes along and says, hey, why not package multiple
functions
and data into a structure. And that is how classes got started (which
lead to object oriented languages like C++ and java). Now when you are
calling a function, instead of eat food, you say "tom, eat food" you
have to tell which structure/class to do it. Of course tom would have
to know how to eat and what food to eat. That is why Tom needs
a function inside called eat, and you need to pass him food as a
parameter.
Well this is fine, but each time you turn on the computer, the classes
dissapear (well at least the data stored inside of them). So people
invented
components that sort of made classes a little smarter. Components are
basically classes that (usually, not all) contains serialization, and
function query. Serialization means it can be stored to harddrive and
back and keep its data intact. function query (my own term) means you
can
ask a component what functions/methods it supports. Some people group
the functions into ports and some group them into interfaces. These
are basically another layer above the functions that you use to
actually execute a function inside a component. COM, Corba, and
JavaBeans are like these. (I did some things on Ports, like smart
ports, which automatically does introspection(check parameter types)
and automatically
link methods between components if they match). I actually created a
new component architecture before (well contributed to it), but it
wasn't truly a new language (you still had to program in java to create
the component pieces to play with).
Well, Perl is something new to me. It has some old vestiges of
assembly type language structures. For example, a called function
manually pops stuff off of the stack (well indirectly), as opposed to
being defined in variables identified in the function definition. It
can also return multiple values (interesting).
Well, if you look at most cells in your body, you notice that they have
a cell wall, and inside contains the DNA and other goodies. Things are
passed to the cell through the cell wall. This is very similar to
passing variables to a component through an
interface/function.
This new language would have components with no constraints on values
passed to it.
as for the values, instead of being dedicated to a method in a
component/class/function, it would be placed on a bloodstream/"bus".
cells/components would grab it when they have appropriate functions
that can use it.
and of course there is the concept of dynamic operators. operators are
basically built-up from other components.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Unbreakable encryption.
Date: Mon, 15 May 2000 04:34:34 GMT
> Gambling: A discretionary tax on | Anthony David
> those who were asleep during high | Systems Administrator
> school mathematics classes |
>
Here you go...
http://www.edepot.com/blackjack.html
(the MOST accurate implementation of casino blackjack in the world
done in java)
Also, here is a Slick perl program (snakeoil?)
I created a neat perl program that
resembles a dynamic glossary. It basically allows anyone to
enter a term and definition from a web-front end, and the terms
are recursive (if a definition contains a defined term, it will
be linked to that defined term). In addition, it can be integrated
(its modular) with any perl program so ANY generated webpages can have
eGlossary'ed definitions. I tied it to my discussion forums and now
any term someone enters into a message that is defined
in the glossary will be automatically linked to that term (url link).
You can check it out at http://www.edepot.com/religion.html
Pretty cool in my opinion. Maybe I should release the code or
sell it. Direct url to the glossary:
http://www.edepot.com/eglossary.html
And some questions for you...
Perl is a scripting language that basically has an interpreter
that goes through the code and follows the script. It is my
understanding that there is a compilation stage where the script is
compiled into something that resembles bytecodes in java, and the
interpreter will then run the bytecode (am I correct on this?) If this
is the case then Perl has basically the same technology
as Smalltalk and Java. Otherwise the script is not really compiled
into bytecode but basically processed into a more readable form
for the interpreter. Bytecodes contain instructions for a
virtual machine cpu (like Load and Store operations in assembly).
I know in Java the Virtual machines is supposed to run a
garbage collector in the background (or when idle) to reclaim
memory used by unreferenced variables. Early versions of the
VM simply allocated memory and didn't even bother to garbage collect
(the code for it wasn't even in there!) I think the latest versions
have some sort of garbage collection built in.
Does perl have garbage collection? When is it run? Or if there even
is a garbage collector? If it does exist, when does unreferenced
variables get garbage collected? Right when they are not referenced?
Or does a background garbage collection comes around and frees up
memory when memory is low, or when it is idle, or checks periodically
now and then, or runs constantly in the background (don't know if this
is possible if multi-threads are not supported on some platforms).
But anyhow, because it is a dictionary type of perl program, it
uses a lot of memory and it does a lot of comparisons (it will
need speed). So I am guessing there is an upperlimit number
of glossary terms that it can handle before Perl cannot be used
anymore. (In this case needing a c/c++ replacement). Has anyone ever
created a memory intensive and speed sensitive application in perl?
Can you comment on this? Has anyone ever written a perl
program that crashed because of some upper bound in speed or
memory requirement?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Encryption of graphics by transposition
Date: Sun, 14 May 2000 21:56:26 -0600
In article <8fmnji$qht$[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
>
> This makes no sense whatsoever. Try encrypting a two-color image with
> Blowfish and tell me when you see the Mona Lisa.
>
Something simple like a large black circle in the middle of a white field
illustrates what I am talking about; a rough pattern of the blocks will
tend to include the same ciphertext for all white areas, a different
characteristic ciphertext for all black areas, and mixed results for
blocks on the boundaries.
If the encryption method does not yield such a crude pattern, that would
be best. Of course, Mona knows that the best way to hide something is to
be ambiguous. If some crypto helper is necessary to advance the honor of a
lesser crypto algorithm, then it is closer to the primative end of the
spectrum than something that stands alone and does not have the same
problem, such a characteristic being another parameter of strength.
--
Secrets that are told or available are not secrets anymore, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 06:59:34 +0200
Tom St Denis wrote:
>
> Let's take an extreme.... you pick random sboxes that are 100%
> linear.... point made.
>
> Basically if you can't figure out the sboxes the cipher is secure, but
> if the chances of getting linear or etc sboxes is higher then it may
> not be as secure as you like.
Note that you are not using one single S-box. In a DES-like cipher,
there are 16*8 S-boxes, if you use random key-dependent ones.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Notes on the "Vortex" block cipher
Date: Mon, 15 May 2000 04:46:44 GMT
In article <8fn04c$35b$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <8fmvaq$2h4$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > The cipher contest must be taking off if we can get the likes of Mr.
> > Schneier to comment! We need Eli Biham, Ron Rivest and Lars Knudsen
> > next :-)
>
> True, but we have already had David comment and I regard him as a good
> cryptographer as well.
...
> Tom
I certainly didn't mean to slight Mr. Wagner. In fact, he appears to
be leading the pack recently. His slide and boomerang attacks are the
only new attacks that I know of. Both have broad applicabilty to block
ciphers.
Mr. Wagner is an excellent cryptographer and his input is highly valued.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Sun, 14 May 2000 21:56:30 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Terry Ritter wrote:
>
> > DES-style ciphers often have a fixed set of boxes; that means
> > opponents will know the complete structure, thus making their attacks
> > that much easier. An alternative is to key-select each box "at
> > random" from among all possible permutations, but that is another
> > cipher design decision.
>
> I suspect that one factor that has favoured the use of fixed S-boxes
> (and the same for all rounds) is ease of implementation (possibly
> particularly in hardware).
Another cost of having key dependant sboxes is key agility. If you either
are using a different key to encrypt each different message, or if you use
so many different keys that it is impractical to save the expanded key
schedules, then how long it takes to set up for a particular key is
important. And, having to compute what the S-boxes look like each time is a
serious hit.
Although, I must say that Twofish took an interesting approach. Perhaps
other cipher designers should examine it.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Unbreakable encryption.
Date: Sun, 14 May 2000 22:50:22 -0600
In article <8fn7bg$ahq$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
....
>
> Well, I never realized that what I invented on the spur of the
> moment really is unbreakable. It is revolutionary in its concept.
> I hope this post clarifies anything left out of the previous postings.
> I am hoping someone uses this information to good use. ...
That is a big claim. But, you should not be shot down for trying.
>
....
>
> Well, once you get into high bases, the plaintext and cyphertext
> can have symbols that have duplicates (code 11 is A and also code 49,
> etc). The calculator I wrote does one type of strict mapping
> (a base conversion routine that supports floating point, and works
> on unlimited lengh numbers, which means it can encrypt any long
> message). But others can be used as well. The Base encryption
> is dynamic as well. In addition to the plaintext and cypher text
> base convertion, you can use floating points and any of the standard
> operators (+-*/ etc) to create your own algorithm from scratch.
> In the previous posts I simply used the inverse (1/x) and some
> operators, and nobody could break it.
Any algorithm that is so entered is a key unto itself, which might be
difficult to get sufficient keyspace alone
>
> To summarize, the number of symbols in the source and the number of
> symbols in the destination is not the same. And the relationship
> between symbols in the source and the symbols in the destination
> is also not the same. (They are in different base). And in high
> bases if you run out of symbols, you can use duplicates (or the
> chinese unicode for all i care).
>
> Well, (I need to repeat redundantly, so I can get to the point),
> this alorithm is unbreakable, because.
>
> 1) It is exponentially expensive to search the keyspace.
> Unlike the garage door opener where you can permutate the bits
> until you find a match... THERE IS NO KEYSPACE YOU CAN SEARCH
> BECAUSE YOU DON'T KNOW WHEN THE KEYSPACE ENDS!
>
> 0011001 wont open the door.
> 00011001 will open it.
> 000011001 wont.
>
> They are essentially the same key, but because the decryptor
> does not know the key length, he/she has to permutate starting
> at 1 bit, then
> work to 2 bits, then work to 3 bits, then work to 4 bits, etc.
> THIS IS EXPONENTIALLY EXPENSIVE, and is secure from brute force
> keysearch.
You have a pattern, and you must repeat your pattern, simple or complex.
> Hardware stuff like the EFF DEEP CRACKER would be
> obsolete when trying to crack this algorithm. ...
That is a custom device that is already inappropriate for use in any other
algorithm than as intended,
>
> In this garage door example, it maps fine into the different
> base of the plaintext and cypher text. THE DECRYPTOR DOESN'T KNOW
> WHAT THE PLAINTEXT BASE IS!!! HE ALSO DOESN'T KNOW WHAT THE
> CYPHERTEXT BASE IS!!! (there could also be duplicates in the symbol
> table).
And, you can have several bases in between plaintext and ciphertext, each
with their own keys. My game is to demonstate flexible keyspaces. Yes,
homophones are one means of adding confusion, and are found in quite a few
ciphers. I prefer more chices, but I play with fewer ones now and then.
>
> 2) Base encryption algorithm is dynamic. Meaning? It can change
> on the fly. Most standard cracking alorithms relies on a fixed
> algorithm (DES, RSA, IDEA, etc ALL have fixed algorithms).
> Well, changing the algorithm in Base encryption is as simple
> as changing the operators. (and you can create any, like 4*pi*x,
> or use any lossless compression algorithm for daring people).
> Good ones use floating points (the calculator does
> floating point calculations in any base) because it is new and
> no hardware supports it infinite floating point digits.
IFD, must be nice, but I get your point. Don't count on lack of
capabilites elsewhere.
>
> 3) Base encryption is useful for streaming cyphers that are
> unbreakable. Because you can change algorithms on the fly,
> you can have the first segment use algorithm 1, base x, second
> algorithm use algorithm 2, base y, etc. And because the decryptor
> does not know the BASE and the ALGORITHM, he can't brute force
> search it, and even (lets say it takes a year and he happens to
> permutate through base 500 starting from base 2 on a future
> super computer), he wouldn't know whether the message is true unless
> he examines the message one by one and pick out ones that looks like
> it has meaning.
Using different bases is a fertile area for implementation of all sorts,
keep working on your ideas. I'm learning more each day myself. We had a
discussion here the other day about formats, part of an algorithm or not.
Surely including them greatly limits any nice convenient area an attacker
wants to believe in.
>
> In conlusion, BASE encryption (and it can use standard base conversion
> or another type) and the use multi symbols and dynamic algorithms is
> the only encryption algorithm that is as secure as one-time pad
> (may be even more because even in one-time pad you know the symbol
> space).
It is promising, but can be better that a OTP, at least less of a burden
after the fact.
>
> I just don't understand why ALL the encryption algorithms these
> days are fixed. Whenever you have anything that is fixed, it
> can be brute force searched in a given time period.
>
Monumental keyspaces help. Unknown algorithms have their place, whole or
in part. Frog demostrated some of the techniques related to your
approach, certainly worth additional exploration, but that is only one of
several ways of building keyspace.
Yes, easily defining what can be brute forced is noot too smart, as such
spaces can be divided and conquered, technology making that increasingly
more attractive. Better to at worse define a hugh keyspace, and march off
into it in a custom fashion.
> The plaintext in this case could be the base 60 or base 26 (you
> pick). Try out different bases, you will see different answers.
> My god! Such simple unbreakable algorithm and nobody even
> thought of it. People keep inventing the same tried methods,
> and they keep getting broken because they can be brute-force
> searched, and the algorithm is static.
>
I suppose that I pick a little more formal limitations, self-adopted
criteria that limit the number of algorithms. Even so, I'm finishing my
11th base-78 ciphertext algorithm in recent weeks, as I keep rooting
around up there to see what I can uncover.. I find that some number
combinations can be most useful over others, but there are potentially
many hundreds of algorithms that meet my criteria.
Over unbreakable, how about sufficiently complex to thwart an attacker by
making him loose confidence and interest, which is what you want.
--
Secrets that are told or available are not secrets anymore, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 07:54:45 +0200
John Savard wrote:
> [EMAIL PROTECTED] (Terry Ritter) wrote,
> >My approach is to try to eliminate every ghost of weakness I can see.
> >I suppose others have different approaches.
>
> It does appear that many others seem to have the approach of not
> putting anything in a cipher that they don't understand...which leads
> to using only things that _are_ potentially weak (but strong enough
> not to fall to known attacks).
>
> I prefer your approach, and I try to use it myself.
This underlines, I believe, the desirability of simplicity in design.
Complexities, which even the authors of the algorithms themselves
need some substantial effort to oversee or understand, are inevitably
sources of troubles.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: AES Comment: the Hitachi patent
Date: Mon, 15 May 2000 07:54:50 +0200
Bruce Schneier wrote:
> This particular example is a counter to the "IP attack" argument
> espoused by some as a reason to select multiple AES algorithms instead
> of a single one. It is most likely that IP attacks, if any, will be
> based on very broad and ambiguous claims (like those of Hitachi) that
> the patent holder attempts to apply to all encryption systems.
This looks like that a number of other people have previously advanced
similar arguments like my recent post in this group (7th May, 'An
argument for multiple AES winners'). If yes, could you give pointers?
Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 07:54:38 +0200
Tom St Denis wrote:
> [EMAIL PROTECTED] (Terry Ritter) wrote:
> > Every enciphering has some key. Any opponent might just try that key
> > at random. Does that make the cipher weak? Does that make the
> > keyspace non-flat?
> >
> > Similarly, if we construct S-boxes such that they are a "random"
> > selection from among the universe of such S-boxes, does the fact that
> > one of these is the "identity transformation," others are close, and
> > many are somewhat linear make any difference at all (assuming the
> > universe of possible S-boxes is "large enough")?
>
> Actually yes it does. Blowfish can be attacked if any pair of entries
> in the sboxes are the same. These sboxes are random as you would say.
>
> Replace the sboxes with ones from CAST and you have a 'more' secure
> block cipher.
Note that there are different approaches. You can choose like in DES
a small number of fixed S-boxes and make these as good as possible
or you let all be random, relying on the fact that the possibility of the
extremely weak ones turning up is very small and the fact that having
random instead of fixed S-boxes renders certain techniques of attack
that are tuned to fixed S-boses very difficult to apply. (If you use a fair
coin to generate a long bit sequences, do you worry much that you get
a sequence of all 0's? As Terry Ritter mentioned elsewhere, do you
worry that the analyst on a very lucky day correctly guesses your
key out of the blue? BTW, there is nothing absolutely secure in life.
If you desire absolute security, you shouldn't ever fly with an airplane,
for example.)
M. K. Shen
------------------------------
** 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
******************************
