Cryptography-Digest Digest #371, Volume #14 Thu, 17 May 01 07:13:00 EDT
Contents:
Re: Kernaugh maps (try #2) (Xcott Craver)
Re: Avoiding RSA padding altogether? (Paul Crowley)
Re: function decomposition (Ulrich Kuehn)
Re: MISTY -- no simple truncated difs (Ulrich Kuehn)
Re: Evidence Eliminator works great. Beware anybody who claims it doesn't work
(propaganda) (Beretta)
Re: TC15 analysis (more) (Mark Wooding)
Re: PRNG question from newbie (Paul Crowley)
Re: OAP-L3: "The absurd weakness." (Anthony Stephen Szopa)
Re: Kernaugh maps (try #2) ("Tom St Denis")
Re: Best, Strongest Algorithm ("Joseph Ashwood")
Re: TC15 analysis (more) ("Tom St Denis")
Re: Crypto web-page ("Joseph Ashwood")
Re: function decomposition ("Tom St Denis")
Re: What Is the Quality of Randomness? (Tim Tyler)
Re: TC15 analysis (more) (Mark Wooding)
Re: TC15 analysis (more) ("Tom St Denis")
----------------------------------------------------------------------------
Subject: Re: Kernaugh maps (try #2)
From: [EMAIL PROTECTED] (Xcott Craver)
Date: Thu, 17 May 2001 04:44:05 GMT
In article <[EMAIL PROTECTED]>, Jim Steuert <[EMAIL PROTECTED]> wrote:
>About the gray code, yes. Also, a gray code is any walk of the
>karnaugh map (except diagonal moves), because any rectangular
>movement only changes 1 bit per move.
If you really want to blow your mind, it turns out the
n-dimensional Hilbert curve is a generalization of gray code.
Normal gray code turns an n-bit number x into a string of
bits f(x) = <b_1, b_2, ... b_n>, such that f(x) and f(x+1)
only differ in one b_i.
A discrete approximation of the Hilbert curve turns an
n*m-bit number x into a string of m-bit numbers
h(x) = <y_1, y_2, ... y_n>, such that h(x) and h(x+1)
only differ in one y_i, and the difference is always just 1.
When m==1, h(x) = f(x).
There is an algorithm for computing h(x) in arbitrarily
many dimensions, written in 1969, which is amazingly
efficient and amazingly opaque. One day I'll offer a
reward for the first person who can figure out why the
algorithm actually works.
-S
------------------------------
Subject: Re: Avoiding RSA padding altogether?
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Thu, 17 May 2001 05:34:29 GMT
"Jakob Jonsson" <[EMAIL PROTECTED]> writes:
> > Thanks for these kind words! Does anyone happen to know if NFDH has
> > been written up with an exact security proof anywhere? If not, would
> > it be worth me doing it?
>
> IMHO, it would certainly be worthwhile. I haven't seen any such proof, but I
> cannot tell for sure. Coron or Bellare/Rogaway would certainly know the
> answer.
Mihir Bellare was kind enough to give me a pointer to the crypto
course he teaches, in which it turns out that this scheme is presented
as "PSS0". The course is a very useful resource in and of itself and
I'm very glad to have been informed of its existence:
http://www-cse.ucsd.edu/classes/wi01/cse107/index.html
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
"Conservation of angular momentum makes the world go around" - John Clark
------------------------------
From: Ulrich Kuehn <[EMAIL PROTECTED]>
Subject: Re: function decomposition
Date: Thu, 17 May 2001 09:00:11 +0200
Reply-To: [EMAIL PROTECTED]
Tom St Denis wrote:
>
> In MISTY they decomposed the GF cubing operation into a set of gate logic.
> How do they do that? I have seen a few bitslicer programs (like those for
> DES) but often they are not elegant examples (i.e no source or poorly
> written source).
>
> What are the logical steps? I was trying to decompose GF inversion with a
> 4-bit field on paper by just say "ok bits 1 and 3 are set and the output bit
> 1 is on so it must be a function of those two..." but often there are
> conflicts...
>
> My goal is to decompose a GF inversion of eight bits that will lead to
> hopefully a somewhat decent translation...
You might want to do a literature search on Quine-McClusky.
Ulrich
------------------------------
From: Ulrich Kuehn <[EMAIL PROTECTED]>
Subject: Re: MISTY -- no simple truncated difs
Date: Thu, 17 May 2001 08:51:06 +0200
Reply-To: [EMAIL PROTECTED]
Tom St Denis wrote:
>
> Wow man the sboxes in MISTY are keen. They have a very low dpmax of 2/512
> and 2/128 respectively... cubing in GF(2^n) n=odd is obviously very
> effective :-)
>
That is why the sboxes are chosen that way :) Look into the original
proposal of Matsui. I suggest that you read that document before diving
deeper into analysing the cipher. It was presented at FSE '97 and should
also be a part of the NESSIE submission.
Ulrich
------------------------------
From: Beretta <[EMAIL PROTECTED]>
Crossposted-To:
alt.privacy,alt.security.pgp,alt.security.scramdisk,alt.privacy.anon-server
Subject: Re: Evidence Eliminator works great. Beware anybody who claims it doesn't
work (propaganda)
Date: Thu, 17 May 2001 08:12:15 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
On 17 May 2001 03:22:17 GMT, [EMAIL PROTECTED] wrote:
<snip>
>
>Evidence Eliminator really makes my life simpler. I don't have to
>bother buying forensic analysis software. If I catch any employee
>with Evidence Eliminator on their hard disk at work, I have them
>fired. It doesn't matter whether they are doing anything illegal
>- they violated company policy by having unauthorized software on
>company machines. It makes things much simpler than trying to
>decide what is and what isn't kiddie porn or copyright-infringement
>porn.
>
>>You have nothing to lose and everything to gain. We can clean your hard
>>drive so well that even the FBI-type software could not get evidence back
>>from it.
>
>Does Evidence Eliminator eliminate all evidence of Evidence Eliminator?
>Either it doesn't or users aren't using it right.
Haha! Amen, brother.
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.5.8
iQA/AwUBOwOH0fPe1mUZTfNpEQKucgCgyoxetAkmowwoN2F7pWPXmgoF1goAnAxg
7dATK6fQeUjSJ2dWAwwsxzG1
=6B82
=====END PGP SIGNATURE=====
PGP Key: 0x194DF369
Fingerprint: B777 DB2A FB11 55FA 509D CE63 F3DE D665 194D F369
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: TC15 analysis (more)
Date: 17 May 2001 09:03:14 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> It seems with the Noekeon sbox there are no 1R attacks with less than four
> active sboxes... neato... time to make a new sbox for TC15.
The various components in Noekeon, the detailed structures of the
nonlinear layer gamma and the linear layer lambda to seem to support
each other more than is required by the design criteria. To that
extent, I think I'd say that they got lucky.
-- [mdw]
------------------------------
Subject: Re: PRNG question from newbie
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Thu, 17 May 2001 09:27:06 GMT
"Roger Schlafly" <[EMAIL PROTECTED]> writes:
> Aarrgh. IMO, people should use different terminology if that is what
> they mean. The obvious meaning of "secure hash function" is that of
> a hash function such that usage as a hash function is secure from known
> attacks. Behaving like a random oracle is a very different and nebulous
> thing.
What would you call a primitive whose goal is to behave like a random
oracle?
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
"Conservation of angular momentum makes the world go around" - John Clark
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: OAP-L3: "The absurd weakness."
Date: Thu, 17 May 2001 02:58:20 -0700
James Felling wrote:
>
> Anthony Stephen Szopa wrote:
>
> > James Felling wrote:
> > >
> > > Anthony Stephen Szopa wrote:
> > >
> > > > James Felling wrote:
> > > > >
> > > > > Tom St Denis wrote:
> > > > >
> > > > > > "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> > > > > > news:3AF65E02.34D45
> > >>(SNIP)
> > > And if you believe that there is this bridge in NY you really need to buy.
> >
> > There must be a very good reason why you have chosen not to
> > communicate.
>
> I find the way you edited my original post deliberately misleading. You claim I
> am not trying to comunicate?
> I feel that the shoe is on the other foot here my friend.
>
> >
> >
> > Can't you just take one point then and explain yourself. Just
> > because you understand (?) what you mean you have not helped us
> > to understand what you mean by communicating it.
> >
> > For instance, your idea of "Mixamixfile is a subgroup of the
> > generic permutation of 105 elements holding first element fixed."
> > Explain this in some detail as to what exactly you mean and how
> > this relates to your claims.
>
> OK. I will define some terms here for you. And try to keep it simple. I will
> rephrase in less formal notation.
>
> Mix a mix file can be viewed as a special case of the following 'Generic
> Method'.
> Generic Method: Imagine the sets of 0-9 digits as cards. and the source file as
> a giant stack of cards. you take the first 105cards off the stack, put the first
> card on the table, then reorder the remaining cards in an arbitrary but known
> manner, i.e find card 103, put it on top of the first card, then find card 10
> put it down, and so on until you are out of cards from that original set of 105,
> then pickup annother 105 cards from the big stack, and repeat.
>
> This generic method is a more efficient mixing method that mix a mix file( by
> orders of magnitude), because with the 105 cards under the generic method you
> can get any possible order(104! possible orderings), and with mix a mix file you
> only can get 14! possible orderings. However, since all possible results of mix
> a mix file can be reproduced by this generic operation and that operation is a
> group, mix a mixfile cannot be arbitrarially repeated with the expectation of
> continued good results, it can at best contribute the randomness of the generic
> operation.
>
> >
> >
> > Just do this one point. Or choose perhaps a simpler one like,
> > "Scramble is a group" and tell us what you mean and how this
> > somehow supports your claims.
>
> Scrambe is a group means the following.Given any key1 and key2, there exists a
> key 3 such that Scramble(key1,Scramble(key2,S))= Scramble(key3,S).And it comutes
> with all of your other methods. This is why I told you long ago that this method
> should only be used 1X.(I am glad to see that you finally added my advice to
> your helpfile, it is a welcome change)
>
> >
> >
> > State your specific claim and describe what you mean by your
> > description then show us how this supports your claim.
>
> your methods can achieve good results, that much is true. However, Your methods
> are not likely to evenly distribute your results across the space of all
> possible results. Since Mix a mix file has fixed points, and is a special case
> of a generic op, it must be used only in combination with other methods to
> provide maximum security.
>
> >
> >
> > I can't discuss what you are talking about if you cannot
> > communicate it.
>
> >
> >
> > Thank you.
>
> Simply put, my assertions are as follows.
>
> Firstly, your methods require excessive effort to achieve good results, since
> they do not efficiently use the keying data that is input to them. Even given a
> substantial amount of mixing, there will be sections of your files that will
> have artifacts of the generation process. Far more so than other such stream
> cyphers would have given an equivalent amount of keying data.(You have the stone
> knives and bearskins of cryptography -- Your tools can and do work, they just
> are less efficient than other more modern and efficient methods)
>
> Secondly, your methodology for generating data results in points of compromise
> not present in other methods.( i.e. the large files on your system are key
> equivalent. With a modern stream cypher and a nice front end, I can memorize my
> key, and never need to store key equivalent data anywhere.
>
> Finally, it seems obvious to me that you do not have a deep understanding of the
> operation of your own cyphersystem. For example, with mix a mixfile, the first
> thing I saw, literally 30 seconds into reading the help file is that there was a
> fixed point in mix a mix file, and 30 second later, I had thought of a minor
> coding change that would fix that issue. Maybe you simply overlooked it, but a
> flaw found after 1 minutes work should have been caught -- if only after the
> first month of people criticising your program on the net. I wonder why you
> made some of the choices you made (i.e. 14 seems to be a common number for you,
> and does not seem to be an oprimal choice in some areas, in addition you seem
> very insistent on the 0-9 'sets' being kept toether, even though this does
> constitute something of a weakness. ( Do you know why? Study the Enigma for a
> clue)
I am trying to read your post with some conscientiousness so I do
not want to jump and make a less than thoughtful response.
But you have clearly not done the same.
You have stated that I have taken your advice and changed my Help
Files: "(I am glad to see that you finally added my advice to your
helpfile, it is a welcome change)"
Are you nuts?
Prove it.
The Help Files you see on my web site are the original help files and
I have not changed them at all. They have been on the site for about
three years now or longer.
This is my proof that you are not playing with a full deck. So for
starters, explain to us all why you have taken this position which
is completely untrue.
Your credibility is zero so far with me. So how do you plan to
correct this?
I'll reply to the rest of your post in a day or two when I have more
time.
Thank you.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Kernaugh maps (try #2)
Date: Thu, 17 May 2001 10:06:26 GMT
"Jeffrey Walton" <[EMAIL PROTECTED]> wrote in message
news:3b034702$0$[EMAIL PROTECTED]...
> Tom,
>
> Here's how I would group them. I omitted the row and column headers
> (e.g., ab 00 01 10 11)
> ---
> | 1 | 0 0 0
> --- ---
> 0 0 0 | 1 |
> -------- |---|
> | 1 1 | 0 | 1 |
> | | |---|
> | 1 1 | 0 | 1 |
> ------- ---
>
> A) Taking the quad is given (the four grouped at the lower left hand
> side). This is f = a'c.
Ahh that's what blows my mind half the time is that each of the little
subexpressions only need to involve the bits required to make up the
pattern. So because the bottom square only exists where a is zero and c is
one the expression a'c will make it.... neato.
> B) The lone 1 at the upper left hand corner is combined (shared) with
> the lower left 1 of the previously taken quad. (Remember, k-maps can
> loop like this). This is f = a'b'd'.
>
> The three on the lower right hand side is two groups lying one over top
> of the other:
> ---
> | 1 | ---
> | 1 | AND | 1 | <== shared by both
> --- | 1 |
> ---
>
> C) So, the upper pair is f = ab'd.
> D) And the lower pair is f = ab'c.
>
> Also note: My choice of grouping with C) and D) we kind of arbitrary.
> I had to take the upper group to get the 1 in at ab'c'd. This left the
> remaining 1 to be grouped with something, and I choose as shown above.
> You could also group it with part of the quad and get the same result.
>
> So, my final equation would be f = a'c + a'b'd' + ab'c + ab'd
>
> BTW, Can you change the font on your news reader to a Fixed Font such as
> Courier? The response will look better (align properly).
Yup fixed with font made it better. So the Kernaugh map is just a way to
optimize the expressions for where a 1 occurs in the table?
Thanks,
Tom
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm
Date: Thu, 10 May 2001 14:34:43 -0700
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Lets clear this up since Joe may have complicted it.
> even a 19bit block size would need a key of over a million
> bytes. to represent all the possible transforms. In scott19u
> for example the true key over a million bytes long. The
> reason its hard to break is that it hard to find any input
> output pairs for the 19 bit blocks used.
>
> If one is going to use a cipher of 128 bits for a block
> size. Then the number of transforms possible becomes
> (2**128)! this is a huge number compared to a small key
> of 256 bits which allows for only 2**256! possible transformations.
> so any block cipher using a 128 bit block and only a 256 bit key
> can not be very complex. And for a given method with a small
> key of 256 bits. It would not take very many pairs of cipher text
> to plain text to mathemtically have enough information to determine
> the key.
That is not necessarily true, and in fact can be proven to be completely
untrue in many circumstances, take a fairly simple one. Take a random
permutation of 2^128 elements, call this P1, swap 2 elements in that
permutation call that P2. Given k blocks of known pt/ct pairs (I'll assume
that each possible plaintext is equally probable) what are the odds of
determining which permutation was used? To determine which of P1/P2 was used
you need to have one of the swapped locations in the list, therefore on
average you will need 2^127 revealed elements to seperate the two
permutations. You seem to have forgotten a few assumptions.
> A place like the NSA would only need a few pairs to uniquely
> show which Rijndeal key was used.
This applies iff two things happen, 1) they can store and search every
permutation, 2) there are no near collisions in Rijndael (completely
unproven but for the sake of argument I will accept that there are no near
collisions). So where are they going to find 2^128*2^256*128 bits of memory
(I assume if they can find this much memory, they can perform the search)?
Of course if there are near collisions, or full collisions they can reduce
this, but that increases the other factor. Either way the type of search you
propose that they do is simply impossible.
> It would be foolish for them
> not to build custom hardware to do this.
It would be more foolish for them to attempt to build custom hardware to do
this. Based on the value above, and an assumption of a density of 1048576
(2^20) gigabytes (2^30) per cubic millimeter, the size of just the memory
would require a volume of ~4.4*10^109 cubic meters, considering that the
earth is less than 10^14 cubic meters in volume, I see a slight problem with
doing this.
[snip completely worthless side comments]
Joe
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: TC15 analysis (more)
Date: Thu, 17 May 2001 10:11:55 GMT
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > It seems with the Noekeon sbox there are no 1R attacks with less than
four
> > active sboxes... neato... time to make a new sbox for TC15.
>
> The various components in Noekeon, the detailed structures of the
> nonlinear layer gamma and the linear layer lambda to seem to support
> each other more than is required by the design criteria. To that
> extent, I think I'd say that they got lucky.
No doubt that Noekeon is a neat design and well thought out. However in my
brief paper (did you read it perchance? I am dying for feedback) I show how
an innocent change in the sbox is dangerous.
The advantages TC15 has over Noekeon is a simpler design, slightly faster
and a more developped key schedule. Noekeon main advanatage over TC15
(other than not having a nerdy kid-designer) is that it's a bit more compact
in hardware.
There are still some things I don't like about either. In TC15 there are 1R
differentials with prob 2^-12 which are very close to being usable (must be
higher than 2^-8) This means TC15 is resistant to diff analysis after 11
rounds and it only has 16 which means with the help of S.Fluhrer I broke 10
rounds of what looked like a hard to analyze cipher.
In Noekeon I don't like their Theta function, I bet any attack that comes
out will take advantage of the xor patterns and poor avalanche in that
function.
Tom
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Crypto web-page
Date: Thu, 10 May 2001 14:45:22 -0700
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > "Widespread use of the RSA public-key algorithm, when there are superior
> > alternatives. "
> >
> > Which is stupid since RSA has yet to be broken and RSA is far simpler
then
> > "surperior" algorithms
>
> The underlying theory is, admittedly, simple.[1] But there's lots of
> weird special cases and strange things you have to do with RSA --
> padding systems like PKCS#1 or OAEP or PSS, knowing what sizes of
> exponent to use, etc. So I dispute that RSA is actually `far' simpler
> than other algorithms.
I find these very simple, well at least raw OAEP and raw PSS. I have a
general dislike of anything beginning with PKCS, especially those ending in
DER though so I might agree with you there.
>
> Even elliptic curve crypto can be considered to be on the same level of
> complexity. You have to implement the maths, and it's a bit weird in
> places, but you have to implement the maths for RSA too (including
> strange things like sliding-window exponentiation and Montgomery
> reduction).
You don't have to implement those to get something that works. That's
exactly where the simplicity of the system comes into play. To describe ECC
you have to first explain Elliptic Curve math, where integer math is taught
in grade school. This makes RSA inherently simpler to the common man than
ECC.
> [1] I think that Diffie-Hellman (and hence ElGamal) is actually
> conceptually simpler, and that Diffie-Hellman is actually better in
> many protocols because it can provide perfect forward secrecy much
> more cheaply.
I definitely agree DH is the simplest, but I don't think ElGamal can be held
in the same regard, I believe it is more complex than RSA (at least for
encryption, for signing it's a tossup).
Joe
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: function decomposition
Date: Thu, 17 May 2001 10:21:38 GMT
"Ulrich Kuehn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >
> > In MISTY they decomposed the GF cubing operation into a set of gate
logic.
> > How do they do that? I have seen a few bitslicer programs (like those
for
> > DES) but often they are not elegant examples (i.e no source or poorly
> > written source).
> >
> > What are the logical steps? I was trying to decompose GF inversion with
a
> > 4-bit field on paper by just say "ok bits 1 and 3 are set and the output
bit
> > 1 is on so it must be a function of those two..." but often there are
> > conflicts...
> >
> > My goal is to decompose a GF inversion of eight bits that will lead to
> > hopefully a somewhat decent translation...
>
> You might want to do a literature search on Quine-McClusky.
thanks I will.
Tom
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: What Is the Quality of Randomness?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 17 May 2001 10:24:42 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> : I mean couldn't different such descriptive languages lead to quite
:> : different evaluations [...]
:>
:> Yes, that's right. Kolmogorov randomness and complexity are only defined
:> with respect to a specified descriptive language. [...]
: So with a number of languages one gets a corresponding
: number of measures of 'randomdomness' and 'complexity'
: without possiblility of conversion.
Yes, that pretty much describes the situation.
: Would these results be very useful/sensible?
No doubt that depends on what you're doing.
FWIW, some languages are more "fundamental" than others -
in the sense that they have more compact hardware representations.
If one were to use compactness of a hardware implementation
as a metric, then one might not see that many differences in
different people's estimation of the complexity of objects -
though doing this has a few problems of its own.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: TC15 analysis (more)
Date: 17 May 2001 10:40:34 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> No doubt that Noekeon is a neat design and well thought out. However
> in my brief paper (did you read it perchance? I am dying for
> feedback) I show how an innocent change in the sbox is dangerous.
No. I can't get anything from your web pages at all. My connections
just hang.
> In Noekeon I don't like their Theta function, I bet any attack that comes
> out will take advantage of the xor patterns and poor avalanche in that
> function.
I suspect you're right.
-- [mdw]
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: TC15 analysis (more)
Date: Thu, 17 May 2001 10:52:50 GMT
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > No doubt that Noekeon is a neat design and well thought out. However
> > in my brief paper (did you read it perchance? I am dying for
> > feedback) I show how an innocent change in the sbox is dangerous.
>
> No. I can't get anything from your web pages at all. My connections
> just hang.
I could email the papers and source etc... for the benefit of other
readers..
my Noekeon attack paper is at (real url)
http://24.112.8.23:8080/na.ps.gz
http://24.112.8.23:8080/na.pdf
my TC15 stuff
http://24.112.8.23:8080/tc15.c
http://24.112.8.23:8080/tc15_lta.c [linear transform analyzer for
avalanche]
http://24.112.8.23:8080/tc15_fd.c [ search for 1R differentials ]
http://24.112.8.23:8080/tc15_test.c [ test for avalanche ]
>
> > In Noekeon I don't like their Theta function, I bet any attack that
comes
> > out will take advantage of the xor patterns and poor avalanche in that
> > function.
>
> I suspect you're right.
My claim is kinda vague. More precisely because the original bits line up
(i.e in parallel) in theta (thanks do PI1 and PI2) I claim that someone will
take advantage of this (I have but in a modified copy). Also because if a
difference occurs between a1/a3 in Theta it will only change a0/a2 in that
round. That's a delayed avalanche of sorts...
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
******************************
