Cryptography-Digest Digest #706, Volume #9 Sat, 12 Jun 99 17:13:02 EDT
Contents:
Re: Cracking DES (Terry Ritter)
Re: Cracking DES (Terry Ritter)
Re: Slide Attack on Scott19u.zip (SCOTT19U.ZIP_GUY)
Re: Slide Attack on Scott19u.zip ([EMAIL PROTECTED])
Re: Slide Attack on Scott19u.zip (SCOTT19U.ZIP_GUY)
Re: Cracking DES (Terry Ritter)
Re: Slide Attack on Scott19u.zip (SCOTT19U.ZIP_GUY)
Re: Cracking DES (Terry Ritter)
Re: Caotic function ([EMAIL PROTECTED])
Re: Slide Attack on Scott19u.zip (SCOTT19U.ZIP_GUY)
Re: Slide Attack on Scott19u.zip (Tim Redburn)
Re: Slide Attack on Scott19u.zip ([EMAIL PROTECTED])
Re: Slide Attack on Scott19u.zip ([EMAIL PROTECTED])
Re: Slide Attack on Scott19u.zip ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Cracking DES
Date: Sat, 12 Jun 1999 19:52:11 GMT
On 11 Jun 1999 12:46:28 -0700, in
<7jrp2k$7hn$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>> >Two other points indicate the assumptions are false. First,
>> >the reward is proportional to the intelligence value of the
>> >recovered plaintext and not the volume of plaintext. Five
>> >percent of the traffic carries much more than five percent
>> >of the value, since real traffic is redundant.
>>
>> Where does this come from? Cite please. Under what assumptions?
>>
>> The next time you want to read a 200-page book, rip it apart and
>> reconstruct the writing from any random 10 pages. So now "reading a
>> book" takes only 5% of the time it did. That should be a boon for
>> busy executives everywhere!
>[...]
>I claim that any five consecutive pages from Biham and Shamir's classic
>book on differential cryptanalysis would probably be enough to reproduce
>most of the ideas, with a bit of work. (Any one of their umpteen pictures
>of differential characteristics would likely be enough to give away the
>whole game.)
*If* we *assume* that an entire book is concerned with a single
secret, such that any page can reveal it, *then* we will find, to our
great surprise, that any page can reveal it. Now let's try making
more realistic assumptions.
For example, what percentage of all books fall into such a category?
What percentage of all crypto message traffic fall into such a
category?
And if 5% of the traffic can expose everything, why is it that anyone
ever bothers to send the other 95%?
>[...]
>I don't think this is a particularly contrived example. Is this what
>you were asking for?
I asked for a citation to the literature where somebody has made such
a statement, identified their assumptions, explained their reasoning,
and backed it up with evidence.
Anybody can handwave that only 5% of the traffic is essentially as
good as 100%, but that does not make it true. In special cases it may
be true. For the most part, I doubt it is. To imply that it is true
is to some extent implying that everyone else (!!!) in the world
operates in a haze, repeating everything they say 20 times.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Cracking DES
Date: Sat, 12 Jun 1999 19:52:19 GMT
On Fri, 11 Jun 1999 20:22:21 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>
>>>I know Terry Ritter disagrees, but I find that as the number
>>>of ciphers an enterprise uses increases, the attackers
>>>reward/effort ratio goes _up_. He picks off the low hanging
>>>fruit. I grant that the ratio goes down if the attacker needs
>>>all the encrypted information, but gaining a significant
>>>portion of the intelligence value gets easier.
>
>>Cite it.
>
>Subject to certain assumptions - which it has already been established
>are not true for your proposal - this is a sufficiently obvious result
>that it can be demonstrated again.
But if those assumptions are *not* true, why do we even bother
continuing on this line of reasoning?
>If each message is enciphered in only one of the n ciphers,
I have proposed that we triple-encipher using different
automatically-selected ciphers. For this analysis we can handwave any
such "cipher stack" as "a cipher." But note that the cipher stack is
inherently as strong as the strongest cipher in the stack (provided we
use independent keys). We can, as a sop to critics, fix one of the
stack positions to use the cipher people would otherwise use, and then
we have n**2 different cipher stacks, each of which is almost
guaranteed (probably as well as anything else in cryptography) to be
at least as strong as the favored cipher.
>and each
>message clearly identifies, without encryption, which one of the n
>ciphers was used with it,
No system should ever identify the cipher in plaintext headers. I
have been campaigning against this for literally years. But I note
that if only one cipher is involved, the mere use of the system
identifies the cipher just as clearly.
>then one could choose one cipher at random,
>and reproduce the one-cipher case, except for the fact that you
>wouldn't be able to read all the messages, just a fraction. The
>opportunity to choose which cipher to attack is a bonus.
>
>And note that if the ciphers are all very similar, research to find an
>attack on one will help in attacking them all: if they're all very
>different, it is likely that they will also be different in strength.
Look around: Are all ciphers the same, or are they different?
>As for the fact that a law of diminishing returns applies when an
>attacker goes from communications intelligence to reading a few
>messages to reading them all, this is borne out by a great deal of the
>historical literature on cryptanalysis, including David Kahn's The
>Codebreakers. However, I will admit that this is not a law of nature;
>it depends on the kind of communications being attacked, and for some
>types of transaction-based systems, the value of the intelligence can
>indeed come close to being proportional to the number of messages
>read.
If your goal is to protect the very existence of a military campaign,
and such existence is disclosed in every message, then only one
message need be exposed. Clearly, this is not a good situation.
To my recollection, very well known descriptions of WWII military
cryptography indicate that major effort was invested to prevent such a
thing. This is one of the older functions of code clerks. There are
comments that messages should be paraphrased so the same information
occurs in different ways in different messages. And military
communications do try to limit the scope of every message to just the
information needed. Nattering is dangerous, and this is why.
But not all uses of cryptography are involved with hiding a major
military operation.
>An oversimplified model can be constructed as follows:
>
>Let there be N messages, of which M messages contain a specific item
>of information that an attacker is interested in.
>
>If one can read all N messages, the probability is 1 that one will
>find that information. However, if the number of messages that one can
>read is small, the probability is now M/N, rather than 1/N, times the
>number of messages you can read that you will learn what you seek.
I think this *is* oversimplified, and here is why: For one thing, I
deny that it makes sense, in the abstract, for any particular cipher,
to talk about a probability of weakness. In general, there is no
probability of a unique thing, because there is nothing we can compare
it to. It either is or is not: we can talk about the two cases, but
we cannot assign probabilities to them, and we cannot talk about an
"expectation" of revealed information.
IF WE HAVE one cipher, it may either be broken in secret, or not.
If it is broken in secret, we lose all, and everyone else loses all as
well.
If it is not broken in secret, we are OK.
BUT IF WE HAVE multiple ciphers, each of them may either be broken in
secret or not.
If some of our ciphers are broken, then some of the messages will be
exposed. Presumably, the better-informed users will use the better
ciphers and will have less of their data exposed.
>So the proportionality law is still linear, except for a factor
>depending on how widely mentioned the data you seek is.
It may be that I over-spoke myself in proposing a multiple-cipher
square law. But I think that common assumption of linearity in this
is false as well. It may be that part of the difference has to do
with ultimate limits on funding, people, and other resources:
Linearity is not possible if the resources are not available.
Linearity also assumes that working on many divergent ciphers will be
as effective as a concentrated effort on a single cipher or system,
which I think is false. Not having a square law does not imply that
the correct answer is "linear."
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Slide Attack on Scott19u.zip
Date: Sat, 12 Jun 1999 20:33:23 GMT
In article <[EMAIL PROTECTED]>, Geoff Thorpe <[EMAIL PROTECTED]> wrote:
>Hi,
>Wise up foul-mouth ... despite your repeated failures to bring your
>"technique" to the table in a form where it can be laid bare for
>examination, you seem peeved because some people actually took enough
>time to bleed some information out the code, see that what they DO find
>looks weak and uninteresting, and say "nah, I've got much better things
>to do than muck around with this". Hey, nobody has to accept your code
>as strong unless they themselves can prove it weak ... especially when
>it is mind-numbingly poorly written, highly non-portable, and virtually
>undocumented (for cryptanalytic purposes).
Actually it is rather well documented. It complies and runs on a PC what
more to you want?
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Slide Attack on Scott19u.zip
Date: Sat, 12 Jun 1999 19:57:54 GMT
On Sat, 12 Jun 1999 14:01:20 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> Yes you would conclude that it could be broken with a hand
>wave and yet I think your full of shit.
Way to make an intelligent response, idiot.
>have the decency to run an attack on it. Instead of pulling statements
>that it is broken out of your ass with out even trying to test it.
Hey, David; Check out my cool cipher;
C=(P*AAA45B_H)-85AA_H
No key, but it's real secure! Someone said he could break it, but he
didn't have the decency to run an attack on it, just said it was weak,
so i ignored him.
Ahem. Sorry, but it makes a point; if something is shown to be
theoreticaly vulnerable, there is no real need to _try_ it, especially
if you are just posting to a newsgroup with a theoretical point.
> Are you really that stupid. You have not shown this for the scoutt19u
>method. Again you shoot you mouth off because of your hatred for me.
>Again if this is true show it. Or do you like to make a practive of lying.
Yeah, real stupid; i bet he writes questions without question marks,
huh?
>>I could be mistaken. You certainly understand the scott* algorithms
>>better than I do. But based on your comments to sci.crypt, it appears as
>>though the slide attack does actually work, and work quite well.
>
> Here you finally tell the truth. At top you conclude my method is broken.
>But here it the bottom you put an out. This shows you tried to misled people
uh.... as _I_ read it, he said it probably _does_ work, but it might
not....
>who would not read from the top down ot this point.
ahhh... so we only read the top part of posts.... You expect us to
respect you enough to try to break your cipher, without (at first)
even telling us how the damn thing works, yet you call us stupid, and
even suggest we are a "phony intellectual" ng. Hmmmmm...
Please oh please don't insult me; ill waste half a day trying to
figure out your english (which is as clear as your coding...).
[EMAIL PROTECTED]
ps No offence mate!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Slide Attack on Scott19u.zip
Date: Sat, 12 Jun 1999 21:05:26 GMT
In article <7ju8fu$90r$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Horst Ossifrage <[EMAIL PROTECTED]> wrote:
>> In the DES example in the paper
>> the subkeys in those two rounds have SHARED KEY BITS regardless
>> of the data. In Scott19u.zip usually, those 2 rounds do not use
>> the same S-Box entry, so they do not indicate any common Key bits.
>
>Ahh, I thought of a maybe-better way to explain how I was thinking to
>bypass this difficulty.
>
>Consider a variant of Treyfer where one eliminates the key[] array and
>uses a key-dependent S-box. (Treyfer is described in the slide paper.)
>
If they write the dam paper in HTML or ascii I would read it.
the ghost view is 3megs unexpanded way to large for n my harddrive.
Is it to much to ask for a HTML or C version of this.
>We can think of this as a cipher with 32 rounds, with 8 S-box lookups
>per round. Or, we can think of this as a cipher with 32*8 = 256
>"mini-rounds", with one S-box lookup per mini-round. I suggest to
>view it as the latter. Note that there is no round dependence in the
>mini-rounds (for the variant we're looking at). Thus, the cipher is
> for (j=0; j<256; j++)
> text[(j+1)&8] = (text[(j+1)&8] + Sbox[text[j&8]]) <<< 1;
>
>I claim that there is a slide attack that needs just 256 chosen plaintexts
>or so. (Do you see it?) The same idea seems to apply to scott19u.
Maybe yes or maybe not at this this isn't as pompous as your first boast.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Cracking DES
Date: Sat, 12 Jun 1999 19:52:36 GMT
On Fri, 11 Jun 1999 15:34:05 -0500, in <[EMAIL PROTECTED]>,
in sci.crypt Eric Norman <[EMAIL PROTECTED]> wrote:
>> [...]
>> The next time you want to read a 200-page book, rip it apart and
>> reconstruct the writing from any random 10 pages. So now "reading a
>> book" takes only 5% of the time it did. That should be a boon for
>> busy executives everywhere!
>
>The argument I hear from Bryan would be closer to this: assume
>we have 1000 different 200 page textbooks about American history.
>If we ripped them apart and only looked at a random sample of
>10000 pages, we would probably know more about American history
>than if we only did this with one.
Since I am unable to get beyond the assumption, I am unable to find
any logical basis for considering the result to be valid.
>
>The actual magnitude of the numbers is speculative, methinks.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Slide Attack on Scott19u.zip
Date: Sat, 12 Jun 1999 20:57:37 GMT
In article <7ju7go$907$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Horst Ossifrage <[EMAIL PROTECTED]> wrote:
>> While Mr. Wagner says that attack breaks Scott19u.zip
>> I will study it for two more days to confirm or refute his
>> claim. In particular, I am studying closely how his paper
>> uses KEY BITS in the first round and the last round to confirm that
>> the Slid Pair is a correct one. In the DES example in the paper
>> the subkeys in those two rounds have SHARED KEY BITS regardless
>> of the data. In Scott19u.zip usually, those 2 rounds do not use
>> the same S-Box entry, so they do not indicate any common Key bits.
>> Without that common clue, Scott19u.zip is different than DES.
>
>You might be right; maybe the attack I was thinking of doesn't
>work. You certainly understand scott19u far better than I.
>
Wow finally a more honest anwser!!!!!!
>Why don't I explain in more detail the technique I was thinking
>of to bypass the fact that scott19u uses a different S-box entry
>in the first and last rounds? You can tell me whether you
>think it will work, since you understand the cipher.
Just what do you mean bypass the fact the first and last round
are different. DO you mean your attacking a reduced version
of Scott19u. I think that reduced version attack was kind of what
Paul Onions did a long time ago?
>
>The primary equation is C[i] = S{(P[i] + P[i+1]) xor C[i-1]},
Actually in your notation it is C[i]=S{(C[i-1] xor P[i]) + P[i+1]
where if the first 19 bits of Pass call P[0] then C[-1] is the last
nineteen bits used in the file. The min file length is 64 bits.
THe complete file is rotated 9 bits up so the the top 9 bits of C[0] go to
bottom of the file. Also there is a first and last round the Paul function
that is different from the 23 rounds that are represented by the
equations above. When one gets to the end of file it borrows for the top
of file rest of C[0] and C[1] so that the most C[m] is such that parts of the
last P[n] and P[n+1] could be using parts od C[0] and C[1] The Paul function
named after Paul Onions is very short and you can see the code to see
how that interacts with things.
>or something like that. I was thinking of looking at a pair of
>plaintexts P[] and P'[] that satisfy
>(*) P'[i] = P[i+1].
>If I understand correctly, this should imply that
> C'[i] = S{(P'[i] + P'[i+1]) xor C'[i-1]}
> = S{(P[i+1] + P[i+2]) xor C[i]} = C[i+1],
>if you let C'[] represent the encryption of P'[] by a round.
>In other words,
>(**) C'[i] = C[i+1].
>Repeating this for multiple rounds, we see that (**) for round
>j => (*) for round j+1, so you should get a slid pair, when the
>(*) is satisfied by the plaintexts (except possibly for 19 bits
>at the boundary, but if you just try enough pairs you should get
>that to match too by dumb luck, I think). Slid pairs can be
>recognized by the fact that the ciphertext satisfies (**) -- thus,
>the two ciphertexts you get agree in all but about 19 bits (if
>you rotate one by 19 bits).
>
>Ok, that was the approach I had in mind. Comments?
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Cracking DES
Date: Sat, 12 Jun 1999 19:52:52 GMT
On 11 Jun 1999 12:54:31 -0700, in
<7jrphn$7id$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David Wagner) wrote:
>Note that experienced cryptanalysts seem able to make a pretty decent guess
>at which ciphers are most likely to break far before they can actually produce
>the full attack which confirms their guess.
>
>Therefore, if I have n ciphers to analyze and I just want to break one of
>them (it doesn't matter which one), I won't devote equal amounts of time to
>all of them -- instead, I'll focus my attention on the few which look most
>likely to break under deep study.
But it *does* matter which one you break; it matters that you cannot
break *all* of them.
This idea that -- in general -- we are almost as well off with only 5%
of the traffic as we would be with 100% of the traffic, seems very,
very, fishy to me. In general, it is probably quite false. If not,
one might well ask why the other 95% of data are even sent.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Caotic function
Date: Sat, 12 Jun 1999 19:12:19 GMT
> I'm looking for documentation about caotic funcions. I 'm a student
and
> can't begin my work without it. Anyone can help me with some links ?
A chaotic function is anything that 'lives'. Think of conways game of
life. Basically in cryptography the environment is the key. The trick
is to make a set of rules which are non-degenerative (if you follow the
game of life it will settle into a pattern...)
I hope that helps...
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Slide Attack on Scott19u.zip
Date: Sat, 12 Jun 1999 21:13:15 GMT
In article <[EMAIL PROTECTED]>, fungus
<[EMAIL PROTECTED]> wrote:
>
>
>Horst Ossifrage wrote:
>>
>> SCOTT19U.ZIP_GUY wrote:
>> >
>> > > During the next 3 days, a Slide Attack will be discussed
>> > > against the Scott19u.zip cryptographic algorism. The
>> > > attack was introduced at the FSE-6 Conference in March,
>> > > 1999, Rome.
>> >
>> > Keep me posted...
>>
>> read Mr. Wagner's paper about the Slide Attack.
>> It is an easy way to attack some ciphers with simple round
>> functions. While Mr. Wagner says that attack breaks Scott19u.zip
>> I will study it for two more days to confirm or refute his
>> claim.
>
>Oh, no....
>
>
>Does this mean we now have to start all over again with scott20?
>
Not yet since Mr Wagner has never really looked at the method
he is just assuming his superior brain is so much better than an ametuer
that he can pornounce it dead with out ever trying it. For example the
minimiu file szie is 64 bits. And there are 2 types of rounds. Mr Wagner
apearrs quick and is highly praised but if he was half as good as he thinks
he is he would be working for the NSA. He is not beacuase they don't let
secret attacks out. Besides the NSA recruiter are so straight they would
have trouble walking around the Berkeley dorms do to the overpowering
smell of the pot that many students there find more interesting than the
topics of study. I don't work for the NSA for different reasons. I don't like
to kiss management ass.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: Slide Attack on Scott19u.zip
Date: Sat, 12 Jun 1999 20:33:42 GMT
On Sat, 12 Jun 1999 20:33:23 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> Actually it is rather well documented. It complies and runs on a PC what
>more to you want?
>
How do I compile it on my Linux PC - an Intel Pentium using gcc 2.8.1?
The compiler complains that it can't find keys.h or pc.h, neither of
which are included in the scott19u.zip file.
-Tim.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Slide Attack on Scott19u.zip
Date: Sat, 12 Jun 1999 19:14:33 GMT
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
>
> Dream on.
>
> DS is no doubt planning scott20 as we speak...he's like (worse
> than!) Freddy Kruger, he just won't give it a rest.
Ok well why not break my cipher? I think it can be done and I really
want to try (I am just not good at things like this). I hate thinking
that my cipher is 'really strong' which means I don't know enough yet.
Hmm I think I better just sit down read some papers and do some deep
thinking. I have to try this to learn. (Maybe I procrasintate to
much?)
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Slide Attack on Scott19u.zip
Date: Sat, 12 Jun 1999 19:15:55 GMT
In article <7ju5ct$8uj$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> It's certainly not conclusive, but it's enough for me to to conclude
> that it's not worth any more of my time, unless some new information
> becomes available. (Hint: You can be the one to provide that new
> information, by posting a concise analysis of the attack and why you
> think it can or cannot be made to work.)
Hmm I wouldn't count on it. Maybe he is just hurt because someone
understood his cipher.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Slide Attack on Scott19u.zip
Date: Sat, 12 Jun 1999 19:27:57 GMT
In article <7ju6h6$8va$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> I took a quick look, and it looks as though the initial and final xor
> with the "permutation" will make the slide attack somewhat more
difficult.
> Also, the 128-bit block width means that the known plaintext attacks
will
> need 2^64 texts or so.
I understand this much :)
>
> Another complication is the key-dependent S-boxes and the fact that
each
> round modifies all of the block (unless Feistel ciphers, which only
modify
> half of the block; this makes slide attacks easier).
It's easier on n/2 ciphers or n ciphers (half or whole block)?
>
> Therefore, this might be a bit of a difficult cipher for your first
attempt
> at building a slide attack, because there are a lot of details to
juggle.
> It might be easier going if you pick a different cipher without some
of the
> complicating factors.
This being true (complicated cipher + kid = trouble). I may not want
to do this then.
> But if you do want to play with this particular cipher, I suggest
that you
> omit the "permutation" xors, at least at first -- I think it will
make your
> life much easier.
But I put those so you cannot easily control the inputs... But yeah I
should try it without (see what benefits I can extract from the
permutations).
>
> Just for reference, the best slide attack I see on the cipher without
the
> "permutation" xors takes something like 512 chosen plaintexts. In
comparison,
> it's not at all clear to me (off the top of my head) how to build an
attack
> on the full cipher: I think you can do it with 2^66 chosen plaintexts
or so,
> but I'm not entirely sure.
How? Or just the jist of it. On one round the cipher can easily be
cracked. In two rounds it's a little harder, it would require finding
blocks which match something like
(0, 0, 0, 0, 0, 0, 0, 0, a) -> (0, 0, 0, 0, 0, 0, 0, b)
(Where 0 = zero, a = input, b = output). I am not to sure about this
though.
>
> P.S. Note that if table[0] = 0, then if (a,b,..,h) = (0,0,..,0) after
the
> initial xor, then (a,b,..,h) = (0,0,..,0) after all the rounds
(before the
> final xor).
But the chances of this occuring is 1/65536 also this reveals only one
entry which is not a break (since the key may only be 256 bits, and you
have reduced the complexity to 65535!).
>A similar property holds if table[0] = 128 or if table[128] = 0
> or 128. Also, in the 64-bit cipher, if a=c and b=d after the initial
xor,
> then these equations still hold after all the rounds (before the
final xor).
> (You should check all of those, in case I made a mistake.)
Well here is a PHT op as above.
(a, b, c, d) = (1, 2, 1, 2)
a += b += a; -> b = 3, a = 4;
c += d += c; -> d = 3; c = 4;
d += a += d; -> a = 7; d = 10
b += c += b; -> c = 7; b = 10
Which indicates that any pattern like
(a, b, c, d) = (x, y, x, y)
Will result in the output of (x', y', x', y'). This indicates short
cycles in the round function. This could be used to control the values
inside the cipher (?) but permutation should hinder this because if you
give (a, b, c, d) as (x, y, x, y) you will end up with
(x^a1,y^a2,x^a3,y^a4). A fix for this would be a 'phase' shift in each
table lookup (or would this push it to (a, b, c, d) -> (x, y+n, x+2n,
y+3n) where n is shift step).
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
