Cryptography-Digest Digest #438, Volume #14 Fri, 25 May 01 13:13:00 EDT
Contents:
Good crypto or just good enough? (Tom St Denis)
Re: "computationally impossible" and cryptographic hashs ("Scott Fluhrer")
Re: Is Rijandael = AES ? ("Brian Gladman")
Break on Schneiers first proposed "self-study cipher" (Tom St Denis)
A generic feistel cipher with hash and gf(257) mixers (Jim Steuert)
Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding... ("BenZen")
Re: A generic feistel cipher with hash and gf(257) mixers (Tom St Denis)
Re: A generic feistel cipher with hash and gf(257) mixers (Tom St Denis)
Re: Great Free Encryption Software ("Henrick Hellström")
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Good crypto or just good enough?
Date: Fri, 25 May 2001 16:11:50 GMT
My old employer asked me to ask the group this question.
Would you settle for crypto that is "just secure enough" or "is as
secure as we know how to make it". Both within reason.
His line of thinking was that I was a hypocrite for only having a
dead-bolt on my door instead of a 6" steel vault door.
That's complete BS though. Let's think about this.
Against single DES no one PC is fast enough to find the key within a
reasonable amount of time. Would you be willing to tell me you want to
use single DES when triple-DES is just as available and afawk much more
secure?
His line of thinking is flawed because "better" crypto (better as in in
theory) is almost always just as easy to come by. Specially in the
software world.
Of course I agree with him that block ciphers are not magical and can't
prevent against all attacks, but does it not stand to reason to pick the
best tools from each field? Why settle for lame tools that open doors
to attacks that can easily be shut?
Tom
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: "computationally impossible" and cryptographic hashs
Date: Fri, 25 May 2001 09:04:53 -0700
Harris Georgiou <[EMAIL PROTECTED]> wrote in message
news:9eebgq$28eg$[EMAIL PROTECTED]...
>
> Ï SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> Ýãñáøå óôï ìÞíõìá óõæÞôçóçò:
> [EMAIL PROTECTED]
> > [EMAIL PROTECTED] (Daniel Graf) wrote in
<[EMAIL PROTECTED]>:
> >
> > > I have a basic question about cryptographic hashes. A friend
> > >......
> >
> > Its not a stupid question but many things are written to confuse
> > new commers. But just look at the counting argument. If you have
> > a 64 bit hash. It can only take on 2**64 vlaues. IF you allowe
> > passwords to be long then in theroy you could have more than
> > 2**64 passwords. That means some different passwords will hash
> > to the same value. What people are counting on is that for
> > the number of passwords actaully used. There will be only a small
> > chance of picking two that hash the same. THe point is no matter
> > how small its not ZERO
> >
> > David A. Scott
> > --
>
> Yes, it's a matter regarding hashes that troubled me at first too. This is
a
> common property when the output space is a reduction (in size/dimensions)
of
> the input space.
> Of course, even when the hashing works as a perfect 64-bit random
function,
> (2**64)+1 unique tries gives you 100% chance that you will have found a
> collision, while on average this only takes about: 2**64/2 = 2**63 tries
> (half).
Actually, on average, with a 64-bit random function, it'll take an average
of about 2**(64/2) = 2**32 tries to find a collision. This is called the
birthday paradox, and is why real hash functions always have at least 128
bits of output; to create at least 2**64 strength against collisions.
--
poncho
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Is Rijandael = AES ?
Date: Fri, 25 May 2001 17:20:10 +0100
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (John Savard) wrote in
> <[EMAIL PROTECTED]>:
>
> >On Fri, 25 May 2001 16:10:13 +0200, "Christian Schindler"
> ><[EMAIL PROTECTED]> wrote, in part:
> >
> >>Is the Rijandael-algorythmus the same as AES??
> >
> >Yes.
> >
> >Just about.
> >
> >Several algorithms were submitted to NIST, and of them, Rijndael was
> >chosen for the standard.
> >
> >However, Rijndael _as submitted_ is not the standard itself, but the
> >basis for the standard. The official Advanced Encryption Standard has
> >not yet been issued.
> >
> >One difference that is currently anticipated to exist between Rijndael
> >as submitted and the standard as eventually issued is that Rijndael as
> >submitted included provision for block sizes of 128, 160, 192, 224 and
> >256 bits, and key sizes of 128, 160, 192, 224, and 256 bits, it is
> >likely that the official standard will only provide for a block size
> >of 128 bits and key sizes of 128, 192, and 256 bits.
> >
>
> and don't forget there will be version longer than 256 bits
> for RIJNDEAL I think gladman even has a few test vectors for it,
I am not aware of Rijndael block lengths greater than 256 bits, but I have
published test vectors for 192 and 256 bit blocks. Are you thinking of these
non-AES block lengths?
I have also just published an implementation of Rijndael that offers 128,
160, 192, 224 and 256 bit block and key lengths in any combination.
I have test vectors for all of these block and key lengths but since there
are 200 test vector files in a 4.5Mbytes zip archive, I have not published
them (my ISP gets annoyed if I use up too much of his bandwidth).
Brian Gladman
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Break on Schneiers first proposed "self-study cipher"
Date: Fri, 25 May 2001 16:26:35 GMT
I wanted to beat this idea around.
In Schneiers (he's a thoughtful person btw) "Self-Study" guide he
proposes to break eight rounds of RC5 without rotations.
At first I realized that the LSB's are completely linear. You simply
get two pairs of inputs where the LSB of the B word (following RC5
terminology) are the same and you get two linear equations of two
unknowns.
A1 xor B1 xor K1 = Y1
A2 xor B2 xor K1 = Y2
Since in both cases you know B1/Y1 and B2/Y2 You move to
A1 xor K1 = Y1 xor B1
A2 xor K1 = Y2 xor B2
If you xor the left sides you get A1 xor A2 which I can't see as too
useful.
Anyone care to just point a subtle hint.
I was also thinking of using impossible differentials. Simply place the
difference in the msb bits of A and B. Thus if you guess the key wrong
you get differences in the lower bits with some probability (Prob of
failure is 1-(3/4)^30 in normal RC5, i.e when no carries occur in
difference). But given enough pairs you could filter out wrong keys
when the difference occurs.
That's more of a brute force solution. I am rather certain linear
analysis can break this in a jiffy.
Tom
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: A generic feistel cipher with hash and gf(257) mixers
Date: Fri, 25 May 2001 12:34:24 -0400
Does anyone have an opinion on the security of
generic feistel ciphers like this? The key is mixed
in the middle rounds in a fairly simple manner.
Does this create any weakness?
This generic feistel cipher is based on the efficient
multipermutation hash mixer routine of Bob Jenkins.
I modified his mixer algorithm to use 32-bit rotates
instead of shifts, and then I tested the statistics.
I also added a gf(257) 32-bit byte-wise multipermutation
mixer. (1 is represented by 8-bit 0x00,...,256 by 0xff)
A multipermutation feistel mixer operation: c = a op b
is invertible, in that by fixing any input a, varying the
second input b will cause all possible values of
the output c. This preserves the equal-likelihood
of all output values, in that any single output
value is caused by exactly (2^n) different input (a,b)
pairs, out of (2^n)*(2^n) possible input pairs.
This makes each output value have prob = 1/(2^n).
Of course, the other important (avalanche,etc) qualities are
due to the properties of the gf and Bob Jenkin's mixers,
in particular his use of combined 32-bit add/sub and xor.
This was compiled with -O5 with the mingw version of gcc.
unsigned char gfinverse[256] =
{ 0,128, 85,192,102, 42,146,224, 199,179,186,149,177,201,119,240,
120, 99,229, 89, 48,221,189, 74, 71, 88,237,100,194, 59,198,248,
147,188,234, 49,131,114,144, 44, 162,152, 5,110, 39, 94,174,165,
20, 35,125,172, 96,118,242,178, 247,225, 60, 29, 58,227,101,252,
86, 73,233,222,148,245,180, 24, 168, 65, 23,185,246,200,243,150,
164,209, 95,204,126, 2, 64,183, 25, 19,208,175,151,215, 45, 82,
52,138,134, 17, 27, 62, 4,214, 163,176,244,187,223,249, 43,217,
115,123, 37,112,133,158, 53, 14, 16,157,139,113,219, 50, 84,254,
1,171,205, 36,142,116, 98,239, 241,202, 97,122,143,218,132,140,
38,212, 6, 32, 68, 11, 79, 92, 41,251,193,228,238,121,117,203,
173,210, 40,104, 80, 47,236,230, 72,191,253,129, 51,160, 46, 91,
105, 12, 55, 9, 70,232,190, 87, 231, 75, 10,107, 33, 22,182,169,
3,154, 28,197,226,195, 30, 8, 77, 13,137,159, 83,130,220,235,
90, 81,161,216,145,250,103, 93, 211,111,141,124,206, 21, 67,108,
7, 57,196, 61,155, 18,167,184, 181, 66, 34,207,166, 26,156,135,
15,136, 54, 78,106, 69, 76, 56, 31,109,213,153, 63,170,127,255};
//
// the basic mix hash from bob jenkins
// modified to use rotates instead of shifts.
// The statistic were tested for 5-rounds and
// are as good as full sha-1.
//
#define mix(a,b,c) \
{ \
unsigned long d,e,f;\
a=a-b; a=a-c; a=a^( (c>>13) | (c<<19) ); \
b=b-c; b=b-a; b=b^( (a<<8) | (a>>24) ); \
c=c-a; c=c-b; c=c^( (b>>13) | (b<<19) ); \
a=a-b; a=a-c; a=a^( (c>>12) | (c<<20) ); \
b=b-c; b=b-a; b=b^( (a<<16) | (a>>16) ); \
c=c-a; c=c-b; c=c^( (b>>5) | (b<<27) ); \
a=a-b; a=a-c; a=a^( (c>>3) | (c<<29) ); \
b=b-c; b=b-a; b=b^( (a<<10) | (a>>22) ); \
c=c-a; c=c-b; c=c^( (b>>15) | (b<<17) ); \
}
//
#define unmix(a,b,c) \
{ \
c=c^( (b>>15) | (b<<17) ); c=c+b; c=c+a;\
b=b^( (a<<10) | (a>>22) ); b=b+a; b=b+c;\
a=a^( (c>>3) | (c<<29) ); a=a+c; a=a+b;\
c=c^( (b>>5) | (b<<27) ); c=c+b; c=c+a;\
b=b^( (a<<16) | (a>>16) ); b=b+a; b=b+c;\
a=a^( (c>>12) | (c<<20) ); a=a+c; a=a+b;\
c=c^( (b>>13) | (b<<19) ); c=c+b; c=c+a;\
b=b^( (a<<8) | (a>>24) ); b=b+a; b=b+c;\
a=a^( (c>>13) | (c<<19) ); a=a+c; a=a+b;\
}
#define gfmix(a,b)\
{\
unsigned long d,e,g;\
d = ( (a>>24) & 0xff )+1; e = ( (b>>24) & 0xff )+1;\
g = ( ((d*e) % 257)-1) & 0xff;\
d = ( (a>>16) & 0xff )+1; e = ( (b>>16) & 0xff )+1;\
g = ( (g<<8) | ( ( ((d*e) % 257)-1) & 0xff) );\
d = ( (a>>8) & 0xff )+1; e = ( (b>>8) & 0xff )+1;\
g = ( (g<<8) | ( ( ((d*e) % 257)-1) & 0xff) );\
d = (a & 0xff)+1; e = (b & 0xff)+1;\
a = ( (g<<8) | ( ( ((d*e) % 257)-1) & 0xff) );\
}
#define gfunmix(a,b)\
{\
unsigned long d,e,g;\
d = ( (a>>24) & 0xff )+1; e = gfinverse[(b>>24) & 0xff]+1;\
g = ( ((d*e) % 257)-1) & 0xff; d = ( (a>>16) & 0xff )+1;\
e = gfinverse[(b>>16) & 0xff]+1;\
g = ( (g<<8) | ( ( ((d*e) % 257)-1) & 0xff) );\
d = ( (a>>8) & 0xff )+1; e = gfinverse[(b>>8) & 0xff]+1;\
g = ( (g<<8) | ( ( ((d*e) % 257)-1) & 0xff) );\
d = (a & 0xff)+1; e = gfinverse[b & 0xff]+1;\
a = ( (g<<8) | ( ( ((d*e) % 257)-1) & 0xff) );\
}
void encrypt( data,key1,key2,key3)
unsigned long *data;
unsigned long key1,key2,key3;
{
unsigned long a,b,c,i;
a = data[0]; b = data[1]; c = data[2];
for (i=0;i<20;i++) mix(a,b,c);
gfmix(a,c); // a <-- a*c mod 257 for each byte
for (i=0;i<5;i++) mix(a,b,c);
gfmix(c,b); // c <-- c*b mod 257 for each byte
for (i=0;i<5;i++) mix(a,b,c);
a = a^key1; b = b^key2; c = c^key3;
for (i=0;i<4;i++) mix(a,b,c);
gfmix(a,b); // a <-- a*b mod 257 for each byte
for (i=0;i<21;i++) mix(a,b,c);
data[0] = a; data[1] = b; data[2] = c;
}
void decrypt( data,key1,key2,key3)
unsigned long *data;
unsigned long key1,key2,key3;
{
unsigned long a,b,c,i;
a = data[0]; b = data[1]; c = data[2];
for (i=0;i<21;i++) unmix(a,b,c);
gfunmix(a,b); // a <-- a*(b^-1) mod 257 for each byte
for (i=0;i<4;i++) unmix(a,b,c);
c = c^key3; b = b^key2; a = a^key1;
for (i=0;i<5;i++) unmix(a,b,c);
gfunmix(c,b); // a <-- a*(b^-1) mod 257 for each byte
for (i=0;i<5;i++) unmix(a,b,c);
gfunmix(a,c); // a <-- a*(b^-1) mod 257 for each byte
for (i=0;i<20;i++) unmix(a,b,c);
data[0] = a; data[1] = b; data[2] = c;
}
------------------------------
From: "BenZen" <[EMAIL PROTECTED]>
Subject: Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding...
Date: Fri, 25 May 2001 12:33:09 -0400
Sergei Lewis wrote in message ...
>In article <BakP6.532$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>says...
>
>> I guess you are right. I'm hoping for the 'longest' non-periodic
>> sequence. On the // line of thought; Isn't the 'PI' numerical exact
>> value non-periodical; hence an infinite number of decimals ?...
>> Then why could not be a specific fractal algorithm proven to
>> generate 'irrationnal'-like sequence ?
>>
>> How do we prove PI decimals are non periodic Paul ?
>
>..if you say all that, then why don't you just use the bits of Pi?
>
Because; I always had these impressions:
1- In that case, I would want to start at an arbitrary offset within the
digits of PI... I'ts safe to presume, starting at the 10^23'th digit will take
days to compute.
2- I always thought calculating PI to the N'th digit involves being able to
process N'th and more width; Requiring relatively powerful computers,
contrary to compute a simple Fractal equation: z[n+1]=z[n]*z[n]+c, z[0]=0.
That was possibly true before the recent algorithm.
I checked:
http://www.cecm.sfu.ca/projects/IntegerRelations/2001/future.html
And it seems the algorithm can compute it on a recent personnal computer,
to the Millionth digit in just about 30 seconds.. That might be possible now.
Colin Percieval is currently on the WWW, computing Pi to the Quadrilion'tn
decimal:
http://www.cecm.sfu.ca/projects/pihex/
You can download the program from this link above.
http://www.cecm.sfu.ca/projects/pihex/source.html <--- SOURCE CODE !!!!!! 8D
This instructed me that:
*** SC* algorithms take about linear time, and polynomially logarithmic space ***
So the idea is feasable my friend Sergei.; On top of that PI is also fascinating
by itself. :D
>The key could be an offset into Pi. An algorithm exists to calculate digits
>of Pi independently of each other (a simple Google search reveals pages
>such as section 4 of http://www.cecm.sfu.ca/pi/piquest/ ). If you start
>calculating at a bit position given by the product of the key and the
>maximum length of a message in bits, the bitstreams used for different
>keys are guaranteed different,
>
Interesting indeed; As you noticed, This led me to an extraordinary good link just
above.
>so the message is as secure as the length
>of the key; without all those nasty problems checking whether your key
>results in a periodic sequence or not..
>
>http://www.seanet.com/~ksbrown/kmath410.htm
>hmp.. interesting
>
Your suggestion is very instructive indeed.
More links about my goals to use the Fractal formula to ENCRYPT a bit-stream.
( Fractal Compression.. I'm a believer) with some comments of mine:
*** General about Cryptography, aside my two favorites **
http://www.infosyssec.org/infosyssec/cry1.htm
http://www.infosyssec.org/infosyssec/cry2.htm
General and comprehensive Cryptography A-2-Z :: A must !!
http://www.ssh.com/tech/crypto/
Electronic Privacy :: Interesting Privacy Political issues discussed.
http://www.privacy.org/
Notes and Litterature on Prime Numbers :: Interesting *
http://www.math.utah.edu/~alfeld/math/prime.html
The Prime pages. ::
http://www.utm.edu/research/primes/
Sci.Math ... Prime FAQ
http://www.faqs.org/faqs/sci-math-faq/primes/
Books with Numerical Methods & SOURCE-CODE.
http://www-rab.larc.nasa.gov/nmp/nmpBooks.htm
** Specifics about Fractal / Chaos, and graphic goodies. **
Fractal Quat; Sources for Linux & windows: Fascinating 3D fractals.
http://www.physcip.uni-stuttgart.de/phy11733/quat_e.html
Fractal CENSUS ... :: Programs, authors and links on a clean page.
http://home.att.net/~Paul.N.Lee/Census_S_T.html
Ultrafractal Formulas :: A HUGE collection of Fractal formulas.
http://formulas.ultrafractal.com/cgi-bin/formuladb?browse ((You can browse too.))
QS Flame :: Fascinating 3D Fractals.
http://www.uvm.edu/~msargent/main.htm
Source code for small and various Fractal generating programs.
http://spanky.fractint.org/pub/fractals/code/ :: This Web site is LOADED !
Just some very strange work with Chaos and Cellular Automaton.
http://www.ramos.nl/yyfire.html :: This work can even stimulate a dead crypto brain !
;)
Computer Automaton and Chaos. :: I wanted to read more after I saw Ying Yang Fire.
http://website.lineone.net/~edandalex/chaosynt.htm
Some Whitepapers: (( If you browse the sci.crypt, you have the brains for these. ))
http://www.research.compaq.com/SRC/publications/src-rr.html
>--
>Sergei Lewis
>http://members.tripod.co.uk/Folken
>
Best regards friend,
I hope Mok-Kong Shen appreciat the links too.
Ben
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Fri, 25 May 2001 16:35:38 GMT
Jim Steuert wrote:
>
> Does anyone have an opinion on the security of
> generic feistel ciphers like this? The key is mixed
> in the middle rounds in a fairly simple manner.
> Does this create any weakness?
>
> This generic feistel cipher is based on the efficient
> multipermutation hash mixer routine of Bob Jenkins.
> I modified his mixer algorithm to use 32-bit rotates
> instead of shifts, and then I tested the statistics.
> I also added a gf(257) 32-bit byte-wise multipermutation
> mixer. (1 is represented by 8-bit 0x00,...,256 by 0xff)
>
> A multipermutation feistel mixer operation: c = a op b
> is invertible, in that by fixing any input a, varying the
> second input b will cause all possible values of
> the output c. This preserves the equal-likelihood
> of all output values, in that any single output
> value is caused by exactly (2^n) different input (a,b)
> pairs, out of (2^n)*(2^n) possible input pairs.
> This makes each output value have prob = 1/(2^n).
> Of course, the other important (avalanche,etc) qualities are
> due to the properties of the gf and Bob Jenkin's mixers,
> in particular his use of combined 32-bit add/sub and xor.
> This was compiled with -O5 with the mingw version of gcc.
This is wrong. Nice immunity to GF(2^n) differentials comes from
GF(2^n) decorrelated functions (it's simple to prove it too). In
GF(257) you will see GF(2^8) differentials with probs upto about 12/256
if I am not mistaken.
> unsigned char gfinverse[256] =
> { 0,128, 85,192,102, 42,146,224, 199,179,186,149,177,201,119,240,
> 120, 99,229, 89, 48,221,189, 74, 71, 88,237,100,194, 59,198,248,
> 147,188,234, 49,131,114,144, 44, 162,152, 5,110, 39, 94,174,165,
> 20, 35,125,172, 96,118,242,178, 247,225, 60, 29, 58,227,101,252,
> 86, 73,233,222,148,245,180, 24, 168, 65, 23,185,246,200,243,150,
> 164,209, 95,204,126, 2, 64,183, 25, 19,208,175,151,215, 45, 82,
> 52,138,134, 17, 27, 62, 4,214, 163,176,244,187,223,249, 43,217,
> 115,123, 37,112,133,158, 53, 14, 16,157,139,113,219, 50, 84,254,
> 1,171,205, 36,142,116, 98,239, 241,202, 97,122,143,218,132,140,
> 38,212, 6, 32, 68, 11, 79, 92, 41,251,193,228,238,121,117,203,
> 173,210, 40,104, 80, 47,236,230, 72,191,253,129, 51,160, 46, 91,
> 105, 12, 55, 9, 70,232,190, 87, 231, 75, 10,107, 33, 22,182,169,
> 3,154, 28,197,226,195, 30, 8, 77, 13,137,159, 83,130,220,235,
> 90, 81,161,216,145,250,103, 93, 211,111,141,124,206, 21, 67,108,
> 7, 57,196, 61,155, 18,167,184, 181, 66, 34,207,166, 26,156,135,
> 15,136, 54, 78,106, 69, 76, 56, 31,109,213,153, 63,170,127,255};
> //
> // the basic mix hash from bob jenkins
> // modified to use rotates instead of shifts.
> // The statistic were tested for 5-rounds and
> // are as good as full sha-1.
> //
> #define mix(a,b,c) \
> { \
> unsigned long d,e,f;\
> a=a-b; a=a-c; a=a^( (c>>13) | (c<<19) ); \
> b=b-c; b=b-a; b=b^( (a<<8) | (a>>24) ); \
> c=c-a; c=c-b; c=c^( (b>>13) | (b<<19) ); \
> a=a-b; a=a-c; a=a^( (c>>12) | (c<<20) ); \
> b=b-c; b=b-a; b=b^( (a<<16) | (a>>16) ); \
> c=c-a; c=c-b; c=c^( (b>>5) | (b<<27) ); \
> a=a-b; a=a-c; a=a^( (c>>3) | (c<<29) ); \
> b=b-c; b=b-a; b=b^( (a<<10) | (a>>22) ); \
> c=c-a; c=c-b; c=c^( (b>>15) | (b<<17) ); \
Why not write this a bit simpler as
a = a-b-c^rotl(c,13); \
etc...
Not only that but I see good differentials. I.e try putting a
difference in the upper bits of A and B. They will cancel out in A,
state in B and move into C. It's a short-lived differential but it
shows how easy it is to start one.
> #define unmix(a,b,c) \
> { \
> c=c^( (b>>15) | (b<<17) ); c=c+b; c=c+a;\
> b=b^( (a<<10) | (a>>22) ); b=b+a; b=b+c;\
> a=a^( (c>>3) | (c<<29) ); a=a+c; a=a+b;\
> c=c^( (b>>5) | (b<<27) ); c=c+b; c=c+a;\
> b=b^( (a<<16) | (a>>16) ); b=b+a; b=b+c;\
> a=a^( (c>>12) | (c<<20) ); a=a+c; a=a+b;\
> c=c^( (b>>13) | (b<<19) ); c=c+b; c=c+a;\
> b=b^( (a<<8) | (a>>24) ); b=b+a; b=b+c;\
> a=a^( (c>>13) | (c<<19) ); a=a+c; a=a+b;\
> }
>
> #define gfmix(a,b)\
> {\
> unsigned long d,e,g;\
> d = ( (a>>24) & 0xff )+1; e = ( (b>>24) & 0xff )+1;\
> g = ( ((d*e) % 257)-1) & 0xff;\
> d = ( (a>>16) & 0xff )+1; e = ( (b>>16) & 0xff )+1;\
> g = ( (g<<8) | ( ( ((d*e) % 257)-1) & 0xff) );\
> d = ( (a>>8) & 0xff )+1; e = ( (b>>8) & 0xff )+1;\
> g = ( (g<<8) | ( ( ((d*e) % 257)-1) & 0xff) );\
> d = (a & 0xff)+1; e = (b & 0xff)+1;\
> a = ( (g<<8) | ( ( ((d*e) % 257)-1) & 0xff) );\
> }
High prob Differentials (most likely). Not only that but this is
terribly messy. What are you basing the security on?
For example, you truncate values ((a>>24&255) for example) which means
you have probs that go \Delta X \rightarrow \Delta 0 very easily. For
example a diff in any of the lower 23 bits will not affect d in the
first line.
It's a very complicated cipher that I can't possibly see being faster or
simpler than say AES.
Sorry, back to the books! (This is a lesson I learned many times...
which is why I only come forward with a Toy cipher when it's blazing
fast and as simple as possible).
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Fri, 25 May 2001 16:42:20 GMT
Tom St Denis wrote:
>
> Jim Steuert wrote:
> >
> > Does anyone have an opinion on the security of
> > generic feistel ciphers like this? The key is mixed
> > in the middle rounds in a fairly simple manner.
> > Does this create any weakness?
> >
> > This generic feistel cipher is based on the efficient
> > multipermutation hash mixer routine of Bob Jenkins.
> > I modified his mixer algorithm to use 32-bit rotates
> > instead of shifts, and then I tested the statistics.
> > I also added a gf(257) 32-bit byte-wise multipermutation
> > mixer. (1 is represented by 8-bit 0x00,...,256 by 0xff)
> >
> > A multipermutation feistel mixer operation: c = a op b
> > is invertible, in that by fixing any input a, varying the
> > second input b will cause all possible values of
> > the output c. This preserves the equal-likelihood
> > of all output values, in that any single output
> > value is caused by exactly (2^n) different input (a,b)
> > pairs, out of (2^n)*(2^n) possible input pairs.
> > This makes each output value have prob = 1/(2^n).
> > Of course, the other important (avalanche,etc) qualities are
> > due to the properties of the gf and Bob Jenkin's mixers,
> > in particular his use of combined 32-bit add/sub and xor.
> > This was compiled with -O5 with the mingw version of gcc.
>
> This is wrong. Nice immunity to GF(2^n) differentials comes from
> GF(2^n) decorrelated functions (it's simple to prove it too). In
> GF(257) you will see GF(2^8) differentials with probs upto about 12/256
> if I am not mistaken.
In GF(257) inversion ...
To be more precise Pr[255 => 255] is 256/256, there are some 16/256,
12/256 and alot of 2,4,8/256.
So this is not a good "fixed" sbox. Note that using mults in GF(257)
by random values is good to a point as the average DP value for any
xor-pair (over all unique multiplicands (all 127*255 of them)) is fairly
low (this is a wild guess I should really check sometime).
I would bet for all mults though diffs by 255 would be a source of
weakness... (again wild speculation)
Tom
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Great Free Encryption Software
Date: Fri, 25 May 2001 19:01:33 +0200
I actually downloaded the stuff and looked at it. The GUI looked like
something you could put together with Delphi 3 in a couple of days. The
cipher seems to Enigma(!), so I don't see the point either way...
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"Mark Wooding" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> George Peters <[EMAIL PROTECTED]> wrote:
>
> > Wow! Nothing like good old DOS commands. Talk about cutting edge
> > technology. I guess these guys haven't heard about OOP yet.
> > I do have to point out at least their documentation is pretty good about
> > concepts in cryptograhy, as far as public key is concerned.
>
> Why just have one non-sequitur when you can have three? I don't see why
> whether a program hsa a flashy GUI has any bearing on how clever it is
> inside. And I don't see why object oriented programming has any
> relevance to either.
>
> Hmm. I must be losing it: I'm picking an argument with a spammer.
>
> -- [mdw]
------------------------------
** 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
******************************
