Cryptography-Digest Digest #339, Volume #14 Fri, 11 May 01 21:13:01 EDT
Contents:
Re: PRNG question from newbie (John Myre)
Re: Horst Feistel (John Savard)
crypt analysis of rar archive encryption ("Erwin Molendijk")
Re: extracting random bits from low-entropy data (Bill Unruh)
How do boomerang attacks work? ("Tom St Denis")
Serpent LT is not complete? ("Tom St Denis")
Re: Serpent LT is not complete? ("Tom St Denis")
Re: extracting random bits from low-entropy data (David Wagner)
Re: PRNG question from newbie (David Wagner)
Re: Best encrypting algoritme (SCOTT19U.ZIP_GUY)
USENIX 2001 Annual Technical Conference (Tiffany Peoples)
Re: PRNG question from newbie (John Myre)
Re: Best encrypting algoritme (SCOTT19U.ZIP_GUY)
Re: Best encrypting algoritme (Mok-Kong Shen)
Re: Best encrypting algoritme ("Tom St Denis")
Re: Best encrypting algoritme ("Tom St Denis")
Re: How do boomerang attacks work? (John Savard)
Re: Quasi Functions, a way to design Maximum Secure Cipher ("Scott Fluhrer")
----------------------------------------------------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: PRNG question from newbie
Date: Fri, 11 May 2001 15:02:28 -0600
John Myre wrote:
<snip>
> The creators of Rijndael (*) have ...
> created an algorithm, Panama,
<snip>
Oops. The Rijndael authors are Joan Daemen and Vincent Rijmen.
The creators of Panama are Joan Daemen and Craig Clapp.
See http://standards.pictel.com/ftp/research/security/
JM
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Horst Feistel
Date: Fri, 11 May 2001 21:30:51 GMT
On 11 May 2001 17:47:41 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote, in part:
>Yes I use term american bad habit when I talk. Since that
>can offend Candians and MExican both of which are Amnericans
>being from same contenent.
In English, North America and South America are part of "The
Americas", and an American is someone from the United States of
America, just as a Brazilian is someone from los Estados Unidos do
Brasil.
But Spanish, Portuguese, and even French speakers in the New World
indeed apply the cognate of 'American' to themselves.
So you do not need to worry about offending English-speaking
Canadians.
John Savard
http://home.ecn.ab.ca/~jsavard/
------------------------------
From: "Erwin Molendijk" <[EMAIL PROTECTED]>
Subject: crypt analysis of rar archive encryption
Date: Sat, 12 May 2001 00:06:28 +0200
Hello,
To master the workings of encryption I'm doing various analysis of (weaker)
encryption methods.
At this moment I'm looking at the encryption method used by the Rar
archiver. To my knowlidge there is no known attach to the method used by
this archiver. If needed I can post the C source of the encryption routine.
I only have a vage theoratical approach, which is probably not realy
feasible.
Does anyone have more information on this specific encryption method used by
Rar?
I'm interested in everything, also more theoratical attacks like
plain-text-attack.
Regards,
Erwin
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: extracting random bits from low-entropy data
Date: 11 May 2001 22:15:54 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED]
(Mark) writes:
]So I guess what I'm really asking is this:
]1. How does a newbie like me construct such a hashing function (which must
]be flexible enough to take M bits of input and produce N bits of output,
]where M and N are chosen by me) from standard components I can find source
]code for (like DES or whatever).
Use a standard hash which has been designed to distribute the effect of
all the output bits on all the output bits. Then just use the N last
(first) bits of the hash output. EG for MD5, just use the last two bits
of the hash of each line.
]2. Does this procedure guarantee that the entropy is spread throughout the
]output bits (e.g., I don't want a situation where the first couple of
]output bits contain all the entropy and the rest are non-random).
Of course it does not guarantee. But good cryptographic hashes are
designed so that any bit of input should have its influece spread of all
of the bits of output. (eg, change a bit of input, and about half of the
output bits change).
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: How do boomerang attacks work?
Date: Fri, 11 May 2001 22:46:58 GMT
I am currently reading the boomerang paper very closely... if I get it
right, we take the cipher and break it into two halves (or take the rounds
we are attacking) ie ENC(x) = E1 o E0(x),
Next we have the four inputs P, P', Q and Q' where P xor P' = Q xor Q' = D1.
we then pick another differential D12, D2 and D21 (D1/D12 are the upward
delta signs for those with the paper, D2/D21 are the downward) such that D1
=> D12. we also get P xor Q = P' xor Q' = D2 in the E1 part of the cipher
and ofcourse D2 => D21 between P/Q and P'/Q' in the end.
What I don't get is let's suppose both D1=>D12 occurs in E0 and D2=>D21
occurs in E1, then does D12=>D1 in E1 between P/P' and Q/Q'?
(if you are going to answer you really should have their paper open since I
am copying from page 3/15)
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Serpent LT is not complete?
Date: Fri, 11 May 2001 23:11:52 GMT
I was tinkering with my LT analyzer I wrote for TC15. I think I adapted it
to the LT from serpent but it tells me that each output bit is only a linear
function of 44 other input bits.
Has anyone else tested it wrt to this crtierion? Perhaps (most likely) my
program is faulty... but if it isn't would that not suggest a flaw in the
Serpent design?
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Serpent LT is not complete?
Date: Fri, 11 May 2001 23:17:27 GMT
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:Yk_K6.68827$[EMAIL PROTECTED]...
> I was tinkering with my LT analyzer I wrote for TC15. I think I adapted
it
> to the LT from serpent but it tells me that each output bit is only a
linear
> function of 44 other input bits.
>
> Has anyone else tested it wrt to this crtierion? Perhaps (most likely) my
> program is faulty... but if it isn't would that not suggest a flaw in the
> Serpent design?
Nope bug in my program. Serpents LT is complete after 6 iterations which
means my LT is complete faster (5 iterations). This perhaps doesn't say
much about how much more secure my LT is in my cipher though...
The results for various rounds are (ignoring the sboxes)
1: 0.036743, 4.703125
2: 0.181458, 23.226562
3: 0.596252, 76.320312
4: 0.954224, 122.140625
5: 0.999390, 127.921875
6: 1.000000, 128.000000
Compared to my LT
1: 0.039062, 5.000000
2: 0.171875, 22.000000
3: 0.515625, 66.000000
4: 0.914062, 117.000000
5: 1.000000, 128.000000
It seems Serpent has a faster avalanche but slows down as it approaches 128.
Perhaps thats a sign mine is worse?
Tom
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: extracting random bits from low-entropy data
Date: 11 May 2001 23:26:41 GMT
Mark wrote:
>1. How does a newbie like me construct such a hashing function (which must
>be flexible enough to take M bits of input and produce N bits of output,
>where M and N are chosen by me) from standard components I can find source
>code for (like DES or whatever).
The short answer: Don't. Use a standard one. I suggest SHA1.
>2. Does this procedure guarantee that the entropy is spread throughout the
>output bits (e.g., I don't want a situation where the first couple of
>output bits contain all the entropy and the rest are non-random).
Yes, if the hash function is good -- that's exactly the idea.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: PRNG question from newbie
Date: 11 May 2001 23:28:46 GMT
Bugs Bunny wrote:
>So, a good PRNG is really dependent on a good hash function?
What do you mean by a PRNG?
If you mean something that stretches a short, truly random,
uniformly distributed seed to a long pseudorandom keystream,
the answer is "No".
If you mean something that collects entropy from various
sources of questionable quality and unknown statistical
distribution and attempts to distill this down to a uniformly
distributed value, then the answer is probably "Yes" in
practice.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best encrypting algoritme
Date: 11 May 2001 23:47:50 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<WeWK6.66928$[EMAIL PROTECTED]>:
..
>Which is what BICOM does, but not how. Not only that you haven't
>explained why that is desirable.
Tom I don't have to explain HOW. I think you have used DGJPP GNU C
before so you can but printf statements in at any step of the way
and you will see how.
As for weither or not its desirable I let you answer this by
answering this question. Do you want to use crypto where an emeny
gets a 100% clear defination as to wether or not he has a correct
key to test. Or would you feel safer that no matter what key the
enemy tests. Something comes back where he can never be sure if
the correct key is used.
>
>Not only that but your main complaint is that their is information
>leakage some how. If you use CTR the encryption is done without the
>plaintext. I.e you encrypt the counters, store em, then xor them
CTR is somthing new. That like you say could be thought of as
using a OTP you would have to be clear that the same values not identaical
for different files or the encryption value is lost. However how
safe is it to use sequennces of blocks from same code. I don't think
anybody knows but it does gave the attacker more to chew on so I suspect
if the AES people go for it than its not very secure. Its clearly
not as secure as using BICOM reverse file and BICOM again.
>against the plaintext. The block cipher never sees the plaintext which
>makes patterns and CBC style booboos disappear. you could encode (eight
>blocks) AAAAAAAA or ABCDEFGH and the attacker would not know the
>difference with high probability. (if the ciphertext is IIIIIIII for
>example then all eight input blocks must be different etc... but the
>prob of that occuring is very very very very very very very very small).
But if the attacker knows the encryption is by sequentail blocks
that alone could gave someone one enough knowledge about RIJNDAEL to
break it. It would be sage if those underlying blocks where purely
random instead of in a predicable sequemce. Yes your right I can;t
break it. But I can see added info that would help someone with a
lot insight to the working of RIJ type of alogrithms.
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: Tiffany Peoples <[EMAIL PROTECTED]>
Subject: USENIX 2001 Annual Technical Conference
Date: Fri, 11 May 2001 17:05:09 -0700
2001 USENIX Annual Technical Conference
June 25-30, 2001
Marriott Copley Place Hotel
Boston, Massachusetts, USA
http://www.usenix.org/events/usenix01/
==============================================
REGISTER BY May 25, 2001 and Save up to $200!
==============================================
Join peers, research and industry leaders in Boston at the USENIX Annual
Technical Conference.
FEATURING THIRTY professional-level tutorials, SEVENTEEN brand-new!
Here�s a sampling:
Running Web Servers Securely Internet Security for Linux Sys Admins
Network Security Profiles UNIX Network Programming
Network Programming with Perl Inside the Linux Kernel
Building Linux Applications Large Heterogeneous Networks
Practical Wireless IP Security Exploring the Potential of LDAP
Wireless Networking Fundamentals Configuring & Administering Samba
Servers
* KEYNOTE ADDRESS by Daniel D. Frye, Director of IBM Linux Technology
Center.
* INVITED TALKS on WAP, IP Wireless Networking, Security Aspects of
Napster and Gnutella, Security For E-voting in Public Elections, Virtual
Machines, Online Privacy, Active Content and Secure DNS
*NEWLY ADDED CLOSING SESSION with Cynthia Breazeal, researcher from the
MIT media lab, currently developing robots that can duplicate human
facial emotions.
*VENDOR EXHIBITION featuring innovative companies, products and
services.
For more information on exhibiting, please contact Dana Geffner at
[EMAIL PROTECTED]
For more information and to register, visit:
http://www.usenix.org/events/usenix01/
=====================================================================
The 2001 USENIX Annual Technical Conference is sponsored by
USENIX, the Advanced Computing Systems Association. www.usenix.org
=====================================================================
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: PRNG question from newbie
Date: Fri, 11 May 2001 17:53:03 -0600
David Wagner wrote:
<snip>
> If you mean something that stretches a short, truly random,
> uniformly distributed seed to a long pseudorandom keystream,
<snip>
> If you mean something that collects entropy from various
> sources of questionable quality and unknown statistical
> distribution and attempts to distill this down to a uniformly
> distributed value,
<snip>
If I understand Daemen's contention correctly, it is that the
cryptographic community should study/attempt a single primitive,
instead of breaking it down as above. That is, instead of
helping the PRNG by promising that it's input is a nice
compact key, or helping the hash function by only requiring
a fixed (small) output, we should ask for a function that
takes any amount of input and gives back any amount of output,
preserving the entropy of the input, and making the output
look pseudo-random and uniformly distributed. I think.
Have you heard of this, or have opinions on the idea? How
is this related to the concept of a PRF?
(And if you know I got this wrong...
well, ok, tell me.)
JM
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best encrypting algoritme
Date: 12 May 2001 00:20:09 GMT
[EMAIL PROTECTED] (Simon Johnson) wrote in
<9dhctj$h59$[EMAIL PROTECTED]>:
>
>I really don't follow what you mean by Bijective compression. If
>compression was not bijective then what use would it be, you couldn't be
>sure your uncompressed file was indeed the uncompressed version of the
>original.
Most people when they compress with a lossless compressor
expect the file to be able to be recreated when it uncompressed.
And when one does encryption you are at least subconcously
thinking that your are only compressing to a smaller file
that should hopefully be in the input space of your main
encryptor. But that is not what happens. The proof of this
is that if you test a wrong key most of the time you get either
a file that can't be decompressed or if it can be. When its
recompressed it gets compressed to something different.
There are compresses that are fully bijective to binary files
which is actually the target of most file compressors.
let X be any binary file in a file system that uses 8-bit bytes
then compress( uncompress ( X )) = X
the above is somthing seldom seen in most compressors used with
encryption.
>
>> The point is why use an inferior system that allows most
>> ciphertext message key combinations to be rejected as not
>> even being possible. Knowing squat about the input. It also
>> harder for the NSA to hid trap doors in the combination crypto
>> system if its fully bijective.
>
>Hrm... well.. i don't know if your system is any better then Rijndael.
>Got any source or a PDF describing your technique? Obviously, i wont
>accept a statement: "This is good, but i can't show you the source" --
>that's sprinkling fairy-dust.
The nice thing is you really don't have to use by sysem. You
can roll your own. Example build your own trusted version of
ECB mode RIJNDAEL. Then you can be sure of it.
NExt use a bijective compressor like arb62.exe a 62 wide artimetic
bijective compressor or write your own.
Then use a program to reverse the bytes. again your can do this your
self.
You need utilites to convert file to FOF files and back. See mine
or write your own not that hard.
Then you need routines to convert back and forth between 16 byte file
sizes and FOF files. Not hard you wirte your own or use mine.
To put these to together to get you own custom version of RIJNDEAL
that is bijective you run things in this order
1 compress to file like ARB62.EXE
2.convert from binary to FOF
3 convert form FOF to 16 byte blocks
4 run your own ECB version of RIJNDEAL
5 convert back to FOF
6 uncompress UNAR62.EXE or less expansive bijective uncompressor
7 reverse file.
8 compress ARIB62.EXE again or other bijective compressor
9 convert binary to FOF
10 convert FOF to 16 byte blocks
11 run ECB version of RIJNDEAL
12 convert to FOF
13 convert to binary file
This allows You to use only trusted block mode encryption methods
of your choice. But the attacker never gets to have any specail
relationship bewteen conecutive blocks. ANd can't get the plain
text ciphertext pairs. That might lead to an easy NSA attack
and it treats the whole file like a single block. if Rijndeal
any good it doubles the effective key space.
THe draw back. is its slow. but for small files so what its
much more secure.
>
>As for the NSA hiding trap doors.... they don't need to. They know quite
>well the most insecure part of most cryptosystems is the human element.
>They just exploit this weakness.
Yes but the most insecure part could very well be how the algorithm
is implemeted. Such as with a nonbijective comressor along with something
like CTR mode. THere is no reason not to make the whole crypto package
bijective to the space of binary files. After which you convert to 5 letter
groupings or even 66 letter groupings what ever you like.
Even PGP could make the encrypted part of fields stand alone biejctive
so that an attacker would not know if he had the correct key or not.
you can do a more secure authentication (key check) without giving away
the store.
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: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best encrypting algoritme
Date: Sat, 12 May 2001 02:38:26 +0200
"SCOTT19U.ZIP_GUY" wrote:
>
> Thanks for remembering me.
> But I do have a question for you. You say your not fond
> of the methods I use. However one of the methods I have
> been trying to get people to use instead of the possible
> weak version of Rijndael from the AES people is Matts BICOM
>
> where make you make 3 passes through file
> pass 1 BICOM with a key
> pass 2 reverse file end for end
> pass 3 BICOM again
>
> This does treat the whole file as a single block.
> What would you say about that kind of encryption
> scheme.
>
> Of cousre if it is a text message will could use shaws
> GrandView method before the first BICOM
As I wrote, it is a matter of personal preference and
as such is barely explanable in objective terms.
It is very difficult to analyze one's own psychology.
I think that maybe I am too conservative, so that I
have a strong bias towards matters well established and
thus have difficulties to get a good intuitive feeling of
how well the operations you do contribute to strength
without seeing some results of study.
M. K. Shen
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best encrypting algoritme
Date: Sat, 12 May 2001 01:02:36 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tom St Denis) wrote in
> <WeWK6.66928$[EMAIL PROTECTED]>:
>
> ..
>
> >Which is what BICOM does, but not how. Not only that you haven't
> >explained why that is desirable.
>
> Tom I don't have to explain HOW. I think you have used DGJPP GNU C
> before so you can but printf statements in at any step of the way
> and you will see how.
Um so I have to reverse engineer the program to figure it out? That's not
very scientific. Can't you post a snippet of the code or pseudo-code for
the benefit of the group?
> As for weither or not its desirable I let you answer this by
> answering this question. Do you want to use crypto where an emeny
> gets a 100% clear defination as to wether or not he has a correct
> key to test. Or would you feel safer that no matter what key the
> enemy tests. Something comes back where he can never be sure if
> the correct key is used.
When will you understand that if the key is smaller than the message a brute
force attack is always possible. There is no way around it. (provided
enough plaintext to reliably tell the key).
> >
> >Not only that but your main complaint is that their is information
> >leakage some how. If you use CTR the encryption is done without the
> >plaintext. I.e you encrypt the counters, store em, then xor them
>
> CTR is somthing new. That like you say could be thought of as
> using a OTP you would have to be clear that the same values not identaical
> for different files or the encryption value is lost. However how
> safe is it to use sequennces of blocks from same code. I don't think
> anybody knows but it does gave the attacker more to chew on so I suspect
> if the AES people go for it than its not very secure. Its clearly
> not as secure as using BICOM reverse file and BICOM again.
Why is CTR less secure? Gimme actual details!
> >against the plaintext. The block cipher never sees the plaintext which
> >makes patterns and CBC style booboos disappear. you could encode (eight
> >blocks) AAAAAAAA or ABCDEFGH and the attacker would not know the
> >difference with high probability. (if the ciphertext is IIIIIIII for
> >example then all eight input blocks must be different etc... but the
> >prob of that occuring is very very very very very very very very small).
>
> But if the attacker knows the encryption is by sequentail blocks
> that alone could gave someone one enough knowledge about RIJNDAEL to
> break it. It would be sage if those underlying blocks where purely
> random instead of in a predicable sequemce. Yes your right I can;t
> break it. But I can see added info that would help someone with a
> lot insight to the working of RIJ type of alogrithms.
What added info? All you know is that the input to AES was 0,1,2,...,x and
that the message is N bits long. You are not given any encrypted outputs
(you have to guess them or determine them via known texts).
If I tell you F(3), you are not given any info about the function, if on the
other hand I tell you F(3)=4, you are given info.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best encrypting algoritme
Date: Sat, 12 May 2001 01:05:03 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Simon Johnson) wrote in
> <9dhctj$h59$[EMAIL PROTECTED]>:
>
> >
> >I really don't follow what you mean by Bijective compression. If
> >compression was not bijective then what use would it be, you couldn't be
> >sure your uncompressed file was indeed the uncompressed version of the
> >original
>
> Most people when they compress with a lossless compressor
> expect the file to be able to be recreated when it uncompressed.
> And when one does encryption you are at least subconcously
> thinking that your are only compressing to a smaller file
> that should hopefully be in the input space of your main
> encryptor. But that is not what happens. The proof of this
> is that if you test a wrong key most of the time you get either
> a file that can't be decompressed or if it can be. When its
> recompressed it gets compressed to something different.
> There are compresses that are fully bijective to binary files
> which is actually the target of most file compressors.
> let X be any binary file in a file system that uses 8-bit bytes
> then compress( uncompress ( X )) = X
> the above is somthing seldom seen in most compressors used with
> encryption.
<snip>
Learn to spell... Rijndael (AES), "your self" => "yourself", "conecutive",
etc..
A few typos are ok, but you are notoriously bad. May I suggest you proof
read your posts not only for content (i.e check you answered the question
set forth) but also that you spell a few words correctly.
Tom
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: How do boomerang attacks work?
Date: Sat, 12 May 2001 01:07:56 GMT
On Fri, 11 May 2001 22:46:58 GMT, "Tom St Denis"
<[EMAIL PROTECTED]> wrote, in part:
>I am currently reading the boomerang paper very closely... if I get it
>right, we take the cipher and break it into two halves (or take the rounds
>we are attacking) ie ENC(x) = E1 o E0(x),
>Next we have the four inputs P, P', Q and Q' where P xor P' = Q xor Q' = D1.
My web page at
http://home.ecn.ab.ca/~jsavard/crypto/co041001.htm
explains the boomerang attack, I hope simply and understandably, if I
may toot my own horn.
The thing about the boomerang attack is that you start out only with P
and P', such that P xor P' is D1.
Enciphering them, then, you create from E(P) and E(P') two other
values which differ from them by D2 ... and these two other values
shall be E(Q) and E(Q'). Then you decipher them to get Q and Q'.
_That's_ how it works, and that's why everything adds up.
John Savard
http://home.ecn.ab.ca/~jsavard/
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Quasi Functions, a way to design Maximum Secure Cipher
Date: Fri, 11 May 2001 17:57:49 -0700
Mark Wooding <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Kostadin Bajalcaliev <[EMAIL PROTECTED]> wrote:
> > 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
>
> No, it's not.
>
> > 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});
>
> 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.
>
> > 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.
Not quite. The top 8 bits of B0 are used to select the operation, and
changing (for example) a + to a * can affect all 32 bits of B3. Yes, other
than that, there's no downwards diffusion, and that can be controlled (see
my differential).
--
poncho
------------------------------
** 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
******************************
