Cryptography-Digest Digest #348, Volume #14 Sun, 13 May 01 13:13:00 EDT
Contents:
Re: Quasi Functions, a way to design Maximum Secure Cipher (SCOTT19U.ZIP_GUY)
wide-trail ("Tom St Denis")
note to Kostadin and other Newbies ("Tom St Denis")
Re: Quasi Functions, a way to design Maximum Secure Cipher (rep To MARK) ("Tom St
Denis")
CABLECRYPT new domain for sale ("Nuijtemans")
Re: Horst Feistel ("Thomas J. Boschloo")
Re: Searching for a free OCSP implementation (Michael =?iso-8859-1?Q?Str=F6der?=)
Re: Quasi Functions, a way to design Maximum Secure Cipher (rep to Scott) ("Scott
Fluhrer")
Re: Comparison of Diff. Cryptanalysis countermeasures (wtshaw)
Re: Comparison of Diff. Cryptanalysis countermeasures (wtshaw)
Re: About DES or AES ? (Mark Wooding)
Re: Noekeon sbox design? (Mark Wooding)
Re: About DES or AES ? ("Tom St Denis")
Re: Noekeon sbox design? ("Tom St Denis")
Re: Best encrypting algoritme (wtshaw)
Trying to Poking holes in Noekeon (was Re: Noekeon sbox design?) ("Tom St Denis")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Quasi Functions, a way to design Maximum Secure Cipher
Date: 13 May 2001 14:47:59 GMT
[EMAIL PROTECTED] (Kostadin Bajalcaliev) wrote in
<[EMAIL PROTECTED]>:
>Hello
>
>After a years of research I have finally define the Quasi Function
>theory, and its practical implementation in cryptography the Polymorphic
>Encryption.
>Here is only the Introduction chapter of the thesis describing the
>results accomplished. I hope you will have interest to examine this
>thesis, all the comments and suggestions are welcomed. The full text of
>the thesis is available at
>
>http://eon.pmf.ukim.edu.mk/~kbajalc/algo/theory/pme
>or
>http://kbajalc.tripod.com/algo/theory/pme
>
>As a illustration here is the round function of SQ6 the cipher
>implementing the theory described in the thesis:
>
>B0 B1 B2 B3 - are 32-bit words, Message BLOCK
>S0 S1 ... S15 - 32-bit words, the KEY
>F[0..0xFFFFFFFF](A1,A2) - array of functions returning 32-bit word
>
>
>Each Round is Defined as
>
>B3^=F[B0](B1,B2);
>(B0,B1,B2,B3)=(B3,B0,B1,B2) /* rotation */
>
>
>The function is defined as:
>
>T{i,j} denote the number formed from the i-th to the j-th bit of T
>Op = {+,xor,*,-}; Op[i] denote the i-th element of set Op
>S[0..15] array of 32-bit words = 512-bits of KEY
>
>F[G](A,B,C)= (S[g]<<<g) og A og (S[g]<<<g) og B og (S[q]<<<g)
>
>og - operation choused by G
>g - the value of a particular binary substring of G
>
>-------------------------
>F[T](A1,A2) = (S[{T{3..0}] <<< T{7..4}) \\
> op[T{25..24}] A1
>\\
> op[T{27..26}] (S[T{11..8}] <<< T{15..12})
> \\ op[T{29..28}] A2
>\\
> op[T{31..30}] (S[T{19..16}] <<< T{23..20});
>
>Fox example having T=To=11 01 00 10 0010 1101 0101 1001 1011 1010
>The function F will be:
>
>F[To](A1,A2) = (S[10] <<< 11) * A1 + (S[9] <<< 5) xor A2 - (S[13] <<<
>2);
>
>==================================================================
>
>
>1. Introduction
>
>The best representative of the classical block-cipher design paradigm is
>Feistel Network with
>its most prominent realization, the Data Encryption Standard. The
>security in this approach is
>determined by the non-linearity of the S-box. Even there have been a
>wide interest and
>discussion about the design of S-boxes there is no algorithm proposed
>for generating “secure
>S-box”. Maybe the invention of Differential and Linear cryptanalysis is
>the final word about
>this paradigm. DES-like ciphers are not candidates for Maximum Secure
>Cipher.
>
>Maximum Secure Cipher (MSC) is an encryption algorithm immune to all
>possible
>(existing and to-be-invent) attacks. Existence of an attack against MSC
>implies a
>need for a significant knowledge about the key as a precondition to
>launch it. The
>growing disparity between the advance of the cipher-design and the
>cryptanalysis
>indicate a convergence in the process of developing secure ciphers. The
>limit of this
>process is the MSC.
>
>The MSC should be immune to any kind of attack that is trying to
>discover the key without a
>prior knowledge about it. The classical approach promote the use of
>fixed transformation, the
>key and plaintext enter a predefined sequence of transformations. Both
>the key and the
>plaintext have no impact on the algorithm, c=E(k,p) concept. Because of
>this the properties of
>f can be independently analyzed abstracting the key and the plaintext.
>As the history has
>shown there is an alternative approach. RC5 has introduced the
>data-depend-rotation. This is
>the simplest instance of what is going to be described here as
>Polymorphic Encryption. Instead
>of being a passive object of transformation, the plaintext determines
>part of them. The history
>of science is showing that each improvement in the human ability to
>understand the nature or
>to construct something lead to a discovery of at least one new problem.
>Because of this, it is
>an imperative to acknowledge the boundaries of advance concerning a
>given problem. Having
>cryptography in mind, the problem of designing secure cipher is
>equivalent to the problem of
>estimating the efficiency of the possible attacks. This implies
>existence of two distinct classes
>of solutions. The first approach is to design cipher immune to the
>attack, and the second to
>design cipher incompatible to the attack. For example, there is no use
>of the Differential
>cryptanalysis if the cipher is not Feistel-Network based, AES is a nice
>example. MSC should
>be designed to be incompatible to any kind of attack assuming the
>secrecy of the key.
>The Polymorphic Encryption is a general concept applicable in MSC
>design. The idea is
>originally presented in 1997 in ANIGMA [1] cipher and MEX [2] hash
>algorithm.
>Consequently, there are several different implementations: A2 [3], SQ2
>[4], Z876 [5]. These
>algorithms present the evolution of the theory presented in this thesis
>as well as the previously
>published draft version of this thesis [6]. The goal is to construct a
>cipher that act significantly
>different according to the key. This is an analogy of the nature, the
>key is the DNA and the
>cipher is the body. The encryption algorithm specifies a template what
>should happen, but
>DNA - the key, determines how it is going to, the cipher is an algorithm
>that generate an
>encryption function according to the key.
>
>=========================================================================
>=
Before I read about this great advance as you call. Is it at least
fully bijective. That is can any output file be thought of as
a possible encrypted message?
And is no information added during the encryption prosess to
actaully weaken the encryption. By that I mean if an attacker tests
a key. Does it decrypt to something then when encrypted by that same
wrong key. Come back to the same cipher text. If not then what is
so hot about it.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: wide-trail
Date: Sun, 13 May 2001 14:59:07 GMT
What does it mean? I have heard it said before. Does it mean something
like a SPN where the diffusion is maximized?
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: note to Kostadin and other Newbies
Date: Sun, 13 May 2001 15:01:08 GMT
Please use a proper posting method. I.e quote the message with > or
something since if you don't it hard to follow who is saying what.
Also please post in TEXT always. HTML is annoying and wastes bandwidth.
Finally it's common politeness (for some reason) to post using mainly lower
case letters. I dunno why maybe it's psychological...
Enjoy this newsgroup and above all try to learn something new each time you
read/post here.
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Quasi Functions, a way to design Maximum Secure Cipher (rep To MARK)
Date: Sun, 13 May 2001 15:04:52 GMT
"Kostadin Bajalcaliev" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> > or
> > http://kbajalc.tripod.com/algo/theory/pme
>
> No, it's not.
>
> WHAT EXACTLY IS MISSING ?
>
> I pause here to note that you're rotating 32-bit things by amounts
> between 0 and 15. You really want 5-bit rotate amounts.
>
> THERE HAVE BEEN NO OTHER CHOICE IF I WANT TO USE ALL THE BITS BUT ONLY
ONCE
> PER TRANSFORMATION.
That makes no sense at all. Random rotates are generally not immune to
differential attacks (prob is w-log2(w)/w of passing a simple diff).
> > Fox example having T=To=11 01 00 10 0010 1101 0101 1001 1011 1010
> > The function F will be:
> >
> > F[To](A1,A2) = (S[10] <<< 11) * A1 + (S[9] <<< 5) xor A2 - (S[13] <<<
2);
>
> Your cipher has very poor downwards diffusion. In particular, I believe
> that a change in the top n <= 8 bits of any or all of the plaintext
> words will only affect the top n bits of the ciphertext words. This (a)
> is a trivial distinguisher for SQ6 and (b) leads to a fairly simple
> key-recovery attack.
>
> I DONT THINK SO, CHANGE IN ANY OR ALL THE 8 MSB IN THE PLAINTEXT WILL
RESULT
> ONLY THE LSB BE THE SAME FOR ADD XOR & SUB.
No his comment is that multiplication is a directed operation. So you could
say that thru the multiplication the lower bits are more linear than the top
ones. Your rotates mess this up a bit, but ideally each output bit should
be an equal non-linear function of all input bits. Like RC6 for example
still has attacks that can break quite a bit of rounds...
> > Maximum Secure Cipher (MSC) is an encryption algorithm immune to all
> > possible (existing and to-be-invent) attacks.
>
> That's a bold claim. Try proving it. Don't just wave hands: prove it.
>
> MSC IS A CONCEPT, NOTHING EXISTING I CLAIM TO BE MSC. NOBODY PROVE
EXISTANCE
> OF CONCEPTS.
So what? If you say MSC is provably secure then you must show how.
> > The first approach is to design cipher immune to the attack, and the
> > second to design cipher incompatible to the attack. For example, there
> > is no use of the Differential cryptanalysis if the cipher is not
> > Feistel-Network based, AES is a nice example.
>
> No. Completely wrong. Differential and linear-approximation techniques
> can be applied to any cipher. It's not even true that Feistel networks
> are particularly susceptible to these kinds of attacks. The reason that
> Rijndael is resistant to differential cryptanalysis is that it's been
> carefully optimized (using the wide-trail system).
>
> IT IS TRUE THAT MOST OF CIPHERS CAN BE ANALIZED USING THE DIFFERENTIAL
> CRYTPANALYSIS BUT IT IS SIGNIFICANTLY HARDER TO ANALIZE THOSE NOT USIGN
FN.
> SQ6 CAN NOT BE ANALIZED AT ALL, THEORETICLY THERE CAN BE SOME
DIFFERENTIALS
> BUT THE ASSUMTIONS ABOUT THOSE ATTACKS WILL BE TOO BIG.
That's rubbish. All functions can be analyzed wrt to diff and linear
attacks. Whether the attacks become feasible is an ENTIRELY different
issue.
> Your cipher above, indeed, demonstrates differential weakness that is
> well beyond anything exhibited by DES.
>
> INTERESTING I WOULD BE HAPPY TO HEAR HOW IT WILL BE DONE.
Try reading some papers and learn how to use USENET.
Tom
------------------------------
From: "Nuijtemans" <[EMAIL PROTECTED]>
Crossposted-To:
alt.binaries.games.encrypted,alt.satellite.tv.crypt,hacktic.crypt,sci.crypt.random-numbers
Subject: CABLECRYPT new domain for sale
Date: Sun, 13 May 2001 15:30:50 GMT
www.cablecrypt.tv
a new bestsellername, Now for sale.
A lot of possibilities with this name, because of the
big grow of pay-tv and cable-tv
send a mail for more info!
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: Horst Feistel
Date: Sun, 13 May 2001 17:45:08 +0200
"Douglas A. Gwyn" wrote:
>
> Jim Reeds wrote:
> > Most Americans pronounce it with the stress on the second
> > syllable (fai-STELL), even though in German it's correct to put
> > the stress on the first syllable, as Paul indicates.
>
> Jim, it would have never occurred to me to accent the
> second syllable.
Fay stel looks a bit wrong to me (from my domain you can see that I am
Dutch, we get German language in high-school). I would say "horst
fi-stal". (accent on first syllable)
Also German is very similar to Dutch. We dutch only think German is more
'pompous' (btw, maybe Mok-Kong Shen could help you folks out! He is a
regular poster to this group).
To be sure, I like the Germans very much. Some of my favorite bands like
Unsane and ATR are from there (Berlin??).
Regards,
Thomas
--
"Software patents harm the flow of free information"
------------------------------
From: Michael =?iso-8859-1?Q?Str=F6der?= <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Searching for a free OCSP implementation
Date: Sun, 13 May 2001 17:51:21 +0200
Reply-To: [EMAIL PROTECTED]
Tor Rustad wrote:
>
> "Tomas Perlines Hormann" <[EMAIL PROTECTED]> wrote in
> message
> > need an implementation of the "Online Certificate Status Protocol
> > (OCSP)" as specified in IETF RFC 2560.
> > [..]
> > Does anybody know of a free implementation?
>
> Check out the latest cryptlib release, but when I asked Peter G. about OCSP
> half a year ago, he had some problems finding an OCSP valdidation site which
> was up and running...
Sorry for getting in so late. The latest snapshots of OpenSSL have
also OCSP support (based on a new ASN.1 engine).
Ciao, Michael.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Quasi Functions, a way to design Maximum Secure Cipher (rep to Scott)
Date: Sun, 13 May 2001 08:58:12 -0700
Kostadin Bajalcaliev <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Don't forget you'll need to define the associativity.
>
> THERE IS NO NEED TO ASSOCIATIVITY AT ALL.
Is the caps-lock on your keyboard stuck? If not, don't use all caps -- IT'S
RUDE.
>
> GENERALY YOUR ATTACK CAN WORK, BUT IF YOU HAVE READ THE THEIS X MUL Y IS
> DEFINED AS X MUL Y = X+ X * Y + Y, JUST BECAUSE WHAT YOU HAVE DESCRIBED
CAN
> HAPPEND BY USING MULTIPLICATION.
The operation X op Y = X + X*Y + Y = (X+1)*(Y+1)-1 handles my differentials
just the same as X*Y would -- you just need to assume that the appropriate
lsbit is 1, rather than 0.
Besides, if you're going to whine that people haven't read your "theis",
then you really should give people links to it that work,
> HAVING THIS SMALL CHANGE IN MULTIPLICATION
> (BECAUSE 2^32+1 IS NOT A PRIME) DISSABLE THE ATTACK YOU HAVE DESCRIBED.
YOUR
> ATTACK IS BASED ON ASSUMPTION THAT THERE ARE WILL BE ENOUGHT PLAINTEXTS
> HAVING A LOT OF ZEROS, WHICH IS POSSIBLE, USING A SIMPLE MULTIPLICATION
WILL
> RESULT IN NO CHANGES TO BE DONE IF THE MULTIPLICATION IS CHOUSEN BY R3, AS
I
> SAID THIS PROBLEM HAVE BEEN NOTICED. THERE IS ONE FURHTER COMPLICATION,
HERE
> IS THE CODE:
>
> int JV_Encrypt(void *block)
> {
> UL *BL, O[4], T, P;
> UI R,i;
>
> BL=(unsigned long *)block;
>
> for(R=0;R<16;R++)
> {
> >>>>>>>> BL[0]+=BL[1]+BL[2]+BL[3]; T=BL[0];
> P=JV_Key[(UI)(T%16)]; T>>=4; P=ROT32(P,T%16); T>>=4;
>
> O[0]=BL[1];
> O[1]=JV_Key[(UI)(T%16)]; T>>=4; O[1]=ROT32(O[1],T%16); T>>=4;
> O[2]=BL[2];
> O[3]=JV_Key[(UI)(T%16)]; T>>=4; O[3]=ROT32(O[3],T%16); T>>=4;
>
> for(i=0;i<4;i++)
> {
> switch(T%4)
> {
> case 0: P+=O[i]; break;
> case 1: P^=O[i]; break;
> case 2: P=((P*O[i]) + P + O[i])%0xFFFFFFFBL; break;
> case 3: P-=O[i]; break;
> }
> T>>=2;
> }
>
> BL[3]^=P;
> T=BL[3]; BL[3]=BL[2]; BL[2]=BL[1]; BL[1]=BL[0]; BL[0]=T;
> }
>
> return 0;
> }
Ok, here's how to break the revised cipher in 2**38 chosen plaintexts. It's
based on a slide attack:
Let us call an input to the cipher (a,b,c,d). Then, after 1 round, the
cipher will be (e,a+b+c+d,b,c) (e=d^F[a+b+c+d](b,c)), and after 16 rounds,
the cipher will be (w,x,y,z).
Now, consider what would happen if we gave as input to the cipher
(f,a+b+c+f,b,c). If e!=f, then the output after 16 rounds will be
effectively random. However, if e==f, then it will flow through the cipher
exactly like the first input, only shifted by one round, and hence the
output will be (v,w+x+y+z,x,y)
By chosing an (a,b,c,d) and then all 2**32 possible values of
(e,a+b+c+d,b,c), we can use this observation to find a solution to
d^e=F[a+b+c+d](b, c) (and, incidentally, z^v=F[x+y+z+w](x,y), but our
attack won't use that).
The selecting a+b+c+d appropriately, we can set all operations within the
first round to xor, and this gives us an equation which is linear in GF/2.
We select 2**5 such values which are linearly independent, and we can solve
for the "JV_Key" (up to a complement, but we can try the two remaining
possibilities).
>
>
>
> Free hint: no cryptographer with a clue would ever confidently describe
> anything he invented as "immune to all possible (existing and
> to-be-invent[sic]) attacks", at least, not without an iron-clad
mathematical
> proof in hand.
>
> THANKS FOR THE HINT. AND THANKS FOR CONFIRMING MY CONSLUSIONS ABOUT
> MULTIPLICATION MOD 2^32 AND THE JUSTIFICATION OF USING X MUL Y = X + XY +
Y.
Except I gave you no such justification: as I said, that revised
multiplication is just as vulnerable as standard multiplication mod 2**32.
> THERE IS A LOT OF MATH IN THE THESIS DESCRIBING THE MODEL, AND MAXIMUM
> SECURE CIPHER IS A CONCEPT INTRODUCED, THERE IS NO CLAIM THAT THE CIPHER
> PRESENTED IS MAXIMUM SECURE, ONLY THING CLAIMED IS THAT PME CAN BE USED IN
> DESIGNING THE MAXIMUM SECURE CIPHER.
"PME can be used in designing the Maximum Secure Cipher"? If you call MSC
the cipher you just presented, that's a pretty safe claim. What security
claims do you make that PME, or any specific cipher designed using it, can
give you? I have pretty quickly broken two ciphers created using it, and so
it doesn't appear to be that powerful.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Comparison of Diff. Cryptanalysis countermeasures
Date: Sun, 13 May 2001 09:56:41 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> I think PGP and the like are designed with these flaws so the
> NSA can still easily read messages. Of course to keep people using
> them they have to espose other flaws now and then so they can fix
> them and keep people hooked.
>
The question is where the incompetence or sophistocated competence is. I
see it as a combination and both are present in both camps depending on
the technical topic. Information security is touted as a problem to
achieve while using tools that are problem prone. The answer is to play
with neither a fixed deck nor an incomplete one.
--
Mother Nature always gets her revenge.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Comparison of Diff. Cryptanalysis countermeasures
Date: Sun, 13 May 2001 09:49:32 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> No I'm not paranoid. You all think I'm paranoid, don't you!
No.
--
Mother Nature always gets her revenge.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: About DES or AES ?
Date: 13 May 2001 16:41:49 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Simple. They both have inverses. All invertable functions are
> permutations.
Wrong. A permutation is a bijective function where the domain and range
are the same set.
Consider the function from F_{2^8} to Z/256Z defined by the map f |->
f(2) + 256Z. It's clearly bijective (think about it for a little bit)
but just as clearly not a permutation. It translates, invertably,
between apples and oranges.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Noekeon sbox design?
Date: 13 May 2001 16:47:23 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> After analyzing the sbox it seems it's not ideal for a bitslice
> cipher...
The Serpent substitutions are more complicated and rather better. But
they're also much slower to compute. I think Noekeon gets the
compromise right here.
I espectially like the fact that I can still remember the entire cipher
well enough to implement it.
> A good question is: Is it worth it in terms of speed and size to use a
> possibly weak sbox instead of something remotely better.
Yes, given the decent diffusion provided by the lambda function. This
is the essence of wide-trail designs. The important thing is that gamma
is strong *enough* given the number of active boxes in a given trail.
-- [mdw]
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: About DES or AES ?
Date: Sun, 13 May 2001 16:36:56 GMT
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > Simple. They both have inverses. All invertable functions are
> > permutations.
>
> Wrong. A permutation is a bijective function where the domain and range
> are the same set.
I stand (sit) corrected.
>
> Consider the function from F_{2^8} to Z/256Z defined by the map f |->
> f(2) + 256Z. It's clearly bijective (think about it for a little bit)
> but just as clearly not a permutation. It translates, invertably,
> between apples and oranges.
Hmm that's abstract though. Let's say GF(2^8) and Z256 are different
structures (they are) but in memory to a computer they are the same
elements(i.e 8-bit units). There are 2^8 elements in both structures and
they all have the same binary representation (00000000 to 11111111). So
they look the same, they taste the same, to the computer they must be the
same.
I agree though they MEAN different things but they are in fact the same.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Noekeon sbox design?
Date: Sun, 13 May 2001 16:40:43 GMT
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > After analyzing the sbox it seems it's not ideal for a bitslice
> > cipher...
>
> The Serpent substitutions are more complicated and rather better. But
> they're also much slower to compute. I think Noekeon gets the
> compromise right here.
Well they are just as slow as mine afaik (they have dependancy chains).
>
> I espectially like the fact that I can still remember the entire cipher
> well enough to implement it.
Hmm other than four rotates you can remember my cipher from scratch too :-)
> > A good question is: Is it worth it in terms of speed and size to use a
> > possibly weak sbox instead of something remotely better.
>
> Yes, given the decent diffusion provided by the lambda function. This
> is the essence of wide-trail designs. The important thing is that gamma
> is strong *enough* given the number of active boxes in a given trail.
Their lamda function is only usefull because of PI1/PI2. Otherwise the
differences could easily cancel out.
Also isn't their claim that their cipher an involution similar to using say
17 round DES [without the final swap]. (i.e swap the keys around and it's
invertable!).
It is a neat design though...
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Best encrypting algoritme
Date: Sun, 13 May 2001 10:29:24 -0600
In article <[EMAIL PROTECTED]>, "John A. Malley"
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> >
> [...]
> >
> > In short, everytime you encrypt the same thing, the ciphertext should
> > substantially vary, no IV's, not reference to adjacent blocks. To get
> > enough polymorphism, the length of the encrypted block will probably be
> > longer than the plaintext considering character set size and/or length of
> > the block in characters.
>
> This sounds like a suggestion for homophonic substitution.
Yes, of a very sophistocated kind. Usual means of doing so are hard to
manage, mere lists of options. For blocks of any size with more that a
few homophones a better method is needed. The goal is to make correlation
of ciphertext blocks impossible.
Whether I actually did so is unanswered, but the data seems to fall where
I like it, at least for six years. A quick study of many homophonics
suggests that they have weaknesses that can be exploited, mainly small
working keys.
>
> >
> [...]
> >
> > Better block ciphers have some sort of obvious key changes going on that
> > allows for increased variability; best is from an input of randomness.
> > The problem of reestablishing a random sequence at both ends can be
> > removed if the encryptive algorithm stores the path back as part of the
> > cipher text. Therefore, original random generation need not be
> > duplicated.
> > >
>
> Changing the key with each block by selecting a new key uniformly at
> random from a key set looks like a significant improvement over ECB with
> the same key. Now the challenge is sharing the key sequence secretly,
> so only Alice and Bob know the random key sequence.
I solve that problem with the pathcode gambit which encrypts a Hansel and
Gretel solution so that the effects of the sequence can be reversed.
>
> This sounds like Douglas Gwyn's proposal of Alice selecting a new key at
> random from a key set, encrypting it with the current shared key and
> transmitting it to Bob (well) before the ciphertext length under the
> current key reaches its unicity distance.
I prefer the Big Bad Wolf metaphor.
>
> We must also watch out for key clustering in the keyspace. We can fool
> ourselves into thinking a large key in and of itself leads to greater
> security and forget that if we aren't careful, we could reveal
> statistics in the ciphertext that depend only on statistics of the
> key. This would allow the cryptanalyst to limit his search for the
> secret key to just a particular subset of the keyspace.
>
Yes, the method of key making is important. I can use many different
methods and easily make a generator that works in pretty much its own
domain while this is not obvious to a BBW. It is a cruel result that
attackable keyspace because it may be widely used can easily be replaced
with a Monty Python Generator, MPG, "And now for something completely
different."
--
Mother Nature always gets her revenge.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Trying to Poking holes in Noekeon (was Re: Noekeon sbox design?)
Date: Sun, 13 May 2001 17:03:20 GMT
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > After analyzing the sbox it seems it's not ideal for a bitslice
> > cipher...
> I espectially like the fact that I can still remember the entire cipher
> well enough to implement it.
Picking on Noekeon some more..
One could note some inefficiency. For example we have
PI1(state)
GAMMA(state)
PI2(state)
Where PI2 is in fact the inverse of PI1. This means the same bits interact
in the sbox (GAMMA) all the time. i.e bits 0,33,65,99 go into the first
sbox ALWAYS. So I don't see what the rotations accomplish (well in
conjunction with THETA I do... )
Also in THETA there are tons of chances to cancel out differences. For
example from the second half (assume no diff in a[0] or a[2])
temp = a[1]^a[3]
We see that obviously if any bit differences line up we get a zero
difference easy. Of course for that to happen two sboxes must be active
(sbox0 and sbox3). However, through the xor-pair table I can't easily see
how to line this up except to note that Pr[2=>8] = Pr[8=>2] = 4/16. This
means a diff in a[1] will lead to a single bit diff in a[3] and vice versa.
I can't figure out how to use that fact though (i.e this is not a break
yet).
Supposing we did get the diffs though.... we know now that DELTA_temp = 0,
thus there is no diff in a[0] or a[2] either.
The problem is now we have the lsb of a[1] and a[3] active we must have a 1R
attack or we are lost...
arrg... must scratch on paper!...
Any hints?
Tom
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
