Slide Attack on Scott19u.zip
Horst Ossifrage
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. The authors were Alex Biryukov and David
Wagner at the Fast Software Encryption Workshop #6. You
can read a Postscript version of the paper here:
http://www.cs.berkeley.edu/~daw/papers/
The Slide Attack is done
using known plaintexts and known ciphertexts. Below, two
encryptions are put side by side, with a one round offset.
F is the round function:
P0
F
P1 P0'
F F
P2 P1'
F F
P3 P2'
F F
P4 P3'
F F
C P4'
F
C'
Pj is a plaintext in round j, C is a ciphertext.
The analyst does not have access to the inner workings
of hardware with the key nor software with the key.
The analyst has, for an m bit key, more than 2^m/2
matching plaintexts and ciphertexts. The cryptanalyst
can check whether it is possible that F(P0)=P0'. This
checking requires that a round is "weak" so that
logic will rule out many candidate P, C pairs. The check is
made feasible by knowing that F(P0)=P0' AND F(C)=C'
simultaneously for the same key.
The documentation for the Scott19u.zip algorithm is at:
http://members.xoom.com/ecil/page2.htm#Dec
The encryption and decryption use the following
round function:
Encryption: Cn = S{(Cn-1 XOR Pn) + Pn+1}
decryption: Pn = Cn-1 XOR (SI{Cn} - Pn+1)
Here, n is the word number in a variable block size, S
is the S-Box and SI is the inverse S-Box.
Keep in mind the overlaying offset shown next:
Plain0 Plain1 Plain2 Plain3
Cifer0 Cifer1 Cifer2 Cif
er3
That describes the 19 bit words kept in memory, with the
result of the encryption equation being written back to
the memory, but offset a few bits. On the next round, the
offset word boundaries are ignored and the first boundaries
are used on the bits in memory. Since the cipher uses a
variable block size, we can choose any number of bits or
words in a block. It is temping to use a 2 bit plaintext
block, but for today, a 2 word block is used (38 bits).
Next, we need to find a "slid pair" from chosen plaintexts
and ciphertexts. A slid pair is 4 blocks. A block can be
any size for Scott19u.zip so we will use a 2 word block of
38 bits. The goal is to find the key made 19*2^19 bits,
usually, but for Scott19u.zip we only need to find the
S-Box, since the key is only used to create an S-Box.
Because of the Birthday Paradox, randomly chosen plaintexts
will create a "first round ciphertext"
that has the same value as another
plaintext after 2^19 guesses. Similarly for the chosen
ciphertext, after 2^19 guesses, we may find a ciphertext that
has the same value as an intermediate value one round before
the end.
The round function is a "weak function" as described the the FSE
paper. In other words, once a plaintext and a matching first round
result are found, some key bits can be determined. The key discovery
is validated by showing that the same key bits are consistent with
the ciphertext pair and plaintext pair (which together constitute
a Slid Pair). Instead of key bits, we used S-Box bits.
By making the block as small as 38 bits as we have done, it makes
the Birthday Paradox become advantageous, but it increases the
number of Slid Pairs needed to reveal the whole S-Box. If one
Slid Pair reveals 2 S-Box words, then 2^18 Slid Pairs are needed
to get the whole S-Box. So about 2^37 calculations are needed,
(2^18 * 2^19). Each calculation may be lengthy. Please feel
free to recalculate this yourself and correct it.
But a complication occurs because the S-Box entries usually are
not the same for the first round pair and the last round pair.
This, apparently, is why the Slide Attack fails for Scott19u.zip.
The cryptanalyst knows that there will be no key bits shared
by the first round pair and the last round pair which together
would have formed a Slid Pair. The only Slid Pairs using the
same 2 S-Box entries for the first round and last round are pairs
which have the same values: That Only Happens If The Final
Ciphertext Is Equal To The First Round Result!
This concludes today's installment. In the FSE 6 paper, round
key bits were in common between the first round and the last round.
That is how consistency is shown. Scott19u.zip does not have
predetermined round keys, causing the Slid Attack to become more
difficult, perhaps squaring the amount of work needed to succeed.
2^74 calculations may be needed. We can try a smaller block size
tomorrow, after you post your comments.
Horst Ossifrage
SCOTT19U.ZIP_GUY
This is interesting in that you seem to need 2^37 entries
but ther are exactly 2^38 possible combinations. If one could
mode the code to use 38 bits then just store the 2^38 pair
combinations and if the enemy uses a moded program that only
has 38 bits allowed this would allow all future messages with
the same exact key to be broken. However the program does not
work at all for less then 64 bits.
> But a complication occurs because the S-Box entries usually are
> not the same for the first round pair and the last round pair.
> This, apparently, is why the Slide Attack fails for Scott19u.zip.
> The cryptanalyst knows that there will be no key bits shared
> by the first round pair and the last round pair which together
> would have formed a Slid Pair. The only Slid Pairs using the
> same 2 S-Box entries for the first round and last round are pairs
> which have the same values: That Only Happens If The Final
> Ciphertext Is Equal To The First Round Result!
>
> This concludes today's installment. In the FSE 6 paper, round
> key bits were in common between the first round and the last round.
> That is how consistency is shown. Scott19u.zip does not have
> predetermined round keys, causing the Slid Attack to become more
> difficult, perhaps squaring the amount of work needed to succeed.
> 2^74 calculations may be needed. We can try a smaller block size
> tomorrow, after you post your comments.
>
> Horst Ossifrage
>
Keep me posted and does any one now where to get a free
post script reader since the papers is writtien in that format.
Or is there an ascii version of the paper so poor people can
read it?
--
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
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
David Wagner
It seems to me your attack can be substantially improved.
The slide attack _does_ work, and it is very efficient.
I conclude that Scott's cipher seems to be thoroughly broken.
1. A too-pessimistic estimate. You state that, for a 38-bit block, you
need 2^37 known texts to get 2^18 slid pairs. I think this is too high.
The correct number should be sqrt(2 * 2^18 * 2^38) = 2^{28.5} known texts.
(Check: with 2^{28.5} texts, you get 2^{28.5}*(2^{28.5} - 1)/2 = 2^56
pairs, so 2^56/2^38 = 2^18 of them should be slid pairs.)
2. A missed opportunity for optimization. If you can make chosen-plaintext
queries, the complexity can be substantially reduced. You can get 2^18
slid pairs with about 2^{19.5} chosen plaintexts, if I am not mistaken.
See the slide attack paper for the technique (an adaptation of a neat
trick due to Eli Biham).
3. Application to other block sizes. The chosen-plaintext attack applies to
any and all block sizes, with no increase in complexity. (In contrast,
the complexity of the known plaintext attack goes up with the square root
of the size of the blockspace, since it requires a birthday collision.)
4. A mistake. You claim that the slide attack doesn't work because usually
different S-box entries are used in the first and last round (``no key
bits shared'', in your terminology). This is wrong.
In particular, you can detect a slid pair by the fact that the plaintexts
agree in all but 19 bits (except for a rotation), and similarly for the
ciphertexts. It doesn't matter that different S-box entries are used.
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.
By the way, for the history buffs, you might be interested to read
http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=232236643&fmt=text
where I posted an early warning (> 2 years ago) that Scott's cipher looks
potentially vulnerable to slide-style attacks.
However, I didn't try to work out all the details; I'm glad you've decided to.
Of course, this was back when I thought David Scott might actually listen
to reason, rather than just reply with gratuitous personal insults. Given
that David Scott doesn't seem interested in learning, I don't think I will
devote any more time to this. I'll let you work out all the details.
SCOTT19U.ZIP_GUY
>Nice observations.
>
>It seems to me your attack can be substantially improved.
>The slide attack _does_ work, and it is very efficient.
>
>I conclude that Scott's cipher seems to be thoroughly broken.
Yes you would conclude that it could be broken with a hand
wave and yet I think your full of shit. You make that statement up
here at the top of the paper and then go on to say you have never
looked at the code or even bothered to test it out. I think that you
have tested it and could not break it with your TOY attack. At least
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.
>
>1. A too-pessimistic estimate. You state that, for a 38-bit block, you
> need 2^37 known texts to get 2^18 slid pairs. I think this is too high.
> The correct number should be sqrt(2 * 2^18 * 2^38) = 2^{28.5} known texts.
> (Check: with 2^{28.5} texts, you get 2^{28.5}*(2^{28.5} - 1)/2 = 2^56
> pairs, so 2^56/2^38 = 2^18 of them should be slid pairs.)
If anything he was looking at a reduced version. The smallest file the
method can handle is 64 bits. But then you have never bothered to really
look at that have you?
>
>2. A missed opportunity for optimization. If you can make chosen-plaintext
> queries, the complexity can be substantially reduced. You can get 2^18
> slid pairs with about 2^{19.5} chosen plaintexts, if I am not mistaken.
> See the slide attack paper for the technique (an adaptation of a neat
> trick due to Eli Biham).
>
>3. Application to other block sizes. The chosen-plaintext attack applies to
> any and all block sizes, with no increase in complexity. (In contrast,
> the complexity of the known plaintext attack goes up with the square root
> of the size of the blockspace, since it requires a birthday collision.)
>
>4. A mistake. You claim that the slide attack doesn't work because usually
> different S-box entries are used in the first and last round (``no key
> bits shared'', in your terminology). This is wrong.
> In particular, you can detect a slid pair by the fact that the plaintexts
> agree in all but 19 bits (except for a rotation), and similarly for the
> ciphertexts. It doesn't matter that different S-box entries are used.
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.
>
>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
who would not read from the top down ot this point. I believe your hatred for
me is so great that you would try to misled people. You mostly have tried your
toy attack on my code and it fails. I have a feeling Paul Onions has a much
better understading of such methods than your slide attack I am just not sure
he goes to confereneces to get the credit he desires. I am not sure he is part
of this phony intellectial club that needs to pat itself on the back every day
or two.
>
>
>By the way, for the history buffs, you might be interested to read
> http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=232236643&fmt=text
>where I posted an early warning (> 2 years ago) that Scott's cipher looks
>potentially vulnerable to slide-style attacks.
>However, I didn't try to work out all the details; I'm glad you've decided to.
>
So you have been looking at scott19u for over 2 years and can bad mouth
it all this time but still can't break it.
>Of course, this was back when I thought David Scott might actually listen
>to reason, rather than just reply with gratuitous personal insults. Given
>that David Scott doesn't seem interested in learning, I don't think I will
>devote any more time to this. I'll let you work out all the details.
Yes just pornounce it dead with out testing. The typical advice of a false
crypto god. Again if you had the balls to pronouce it dead it least show it or
run your attack on it. Your have the courage to pornounce it dead over two
years ago but have never run your Toy Slide thing against my admitted
ametuer code becasue that would hurt your inflated ego. Again I say have
the honesty to run the attack on scott19u to show a real break. Or is
honesty to much to expect from one like you. I am sure with the large
key space that my method uses that you should be able to make a special
case key that would allow such a toy attack but in general I don't think you
can break it. You like Bruce have to make a slap at it every year or so. ANd
then say you don't have time to really look at it because theer are so many
other methods to look at. So why can you two alwasy claim that it is obvious
very weak and dead but never seem to find the time to break it. I have heard
from others that you guys hate me ( I like that) and can't break it. Is that
true.
David A. Scott
tomst...@my-deja.com
Really that quick? Geez... Well David you seem to be knowledgeable
about the attack (you invented it...) I would like to break my simple
cipher. It has no round dependant keys which is why I think a slide
attack will work.
It's at http://people.goplay.com/tomstdenis/simple.c
I will have to read your paper again and see how I would start it.
Tom
tomst...@my-deja.com
Dave Scott: Shut the fuck up.
Sorry for the bad lang, but really give it a rest. I think that Horst
or David Wagner should clean up their attack so that the rest of us can
understand it. If they clean it up and explain how they mounted the
attack (what style) I think we can all rest calmly tonight :)
Horst Ossifrage
>
> In article <376151...@utah.net>,
> Horst Ossifrage <pai...@utah.net> wrote:
> > Attempted Slide Attack on Scott19u.zip
> >
> > 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. The authors were Alex Biryukov and David
> > Wagner at the Fast Software Encryption Workshop #6. You
> > can read a Postscript version of the paper here:
> >
> > http://www.cs.berkeley.edu/~daw/papers/
> >
> Keep me posted and does any one now where to get a free
> post script reader since the papers is writtien in that format.
> Or is there an ascii version of the paper so poor people can
> read it?
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> http://members.xoom.com/ecil/index.htm
Dear Mr. Scott, you can download the Ghostscript Viewer at:
http://www.cs.wisc.edu/~ghost/aladdin/get550.html
Then you can 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. 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.
That is why I will re-read the paper, and post more on this tomorrow.
I want to thank David and David for participating in this fun.
Horst Ossifrage
Geoff Thorpe
"SCOTT19U.ZIP_GUY" wrote:
[snip]
> Yes you would conclude that it could be broken with a hand
> wave and yet I think your full of shit. You make that statement up
> here at the top of the paper and then go on to say you have never
> looked at the code or even bothered to test it out. I think that you
> have tested it and could not break it with your TOY attack. At least
> 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.
and ...
[snip]
> So you have been looking at scott19u for over 2 years and can bad mouth
> it all this time but still can't break it.
[snip]
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).
And if you check the post, he looked at it over 2 years ago and made
comments then, he never said he'd been looking at it for over 2 years
(who would have such perserverance??). You're lucky people look at it as
far as they do - you are highly unresponsive on giving people the
information they need to really launch a proper examination on your
stuff ... I think you're scared that if it was described in a
straight-forward fashion, it would get beaten up rather too quickly for
your ego - at least that's the only reasonable interpretation that can
be made of your statements and conduct.
It's unusable until it has withstood some real cryptanalytic
stress-testing, and it won't get that until you cut through the crap and
just bring the algorithm to the forum in a form ready for it. C code,
even if it WAS well written (documented, not littered with inexplicable
macros, uses meaningful variable names, etc) is not what people need to
conduct a real test. It's YOU that wants respect for your work, then
it's about time you came forth with the goods. You haven't, and should
be extremely grateful that it's had as much comment as it has given what
people have to work with.
And is it possible to discuss the issues without such vitriolic abusive
nonsense? The guy simply made comments about attacks on the algorithm
... agree or disagree as you wish - but it doesn't imply "hatred" for
you, nor is it justified to start saying people are talking out their
ass, saying they're stupid or lying, etc etc etc. Hell, do you want
people to talk about your algorithms or not???
David Wagner
SCOTT19U.ZIP_GUY <dsc...@networkusa.net> wrote:
> In article <7jromi$7h3$1...@blowfish.isaac.cs.berkeley.edu>, d...@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote:
> >I conclude that Scott's cipher seems to be thoroughly broken.
>
> Yes you would conclude that it could be broken with a hand
> wave and yet I think your full of shit. You make that statement up
> here at the top of the paper and then go on to say you have never
> looked at the code or even bothered to test it out. I think that you
> have tested it and could not break it with your TOY attack. At least
> 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.
Fair enough. Ok, to be more precise, I should have said
``From what I've seen so far, I am led to the conclusion that
Scott's cipher appears to be broken.''
Sorry about that. Is that better?
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.)
David Wagner
> I would like to break my simple
> cipher. It has no round dependant keys which is why I think a slide
> attack will work.
>
> It's at http://people.goplay.com/tomstdenis/simple.c
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.
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).
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.
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.
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.
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). 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.)
fungus
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?
--
<\___/>
/ O O \
\_____/ FTB.
fungus
tomst...@my-deja.com wrote:
>
> If they clean it up and explain how they mounted the
> attack (what style) I think we can all rest calmly tonight :)
>
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.
David Wagner
> While Mr. Wagner says that attack breaks Scott19u.zip
> I will study it for two more days to confirm or refute his
> 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.
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.
The primary equation is C[i] = S{(P[i] + P[i+1]) xor C[i-1]},
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?
tomst...@my-deja.com
fungus <fun...@egg.chips.and.spam.com> 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!
tomst...@my-deja.com
d...@blowfish.isaac.cs.berkeley.edu (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.
tomst...@my-deja.com
d...@blowfish.isaac.cs.berkeley.edu (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).
David Wagner
> 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.)
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.
tomst...@my-deja.com
> 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;
Not to be picky but it's (&7) not (&8).
>
> 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.
>
Between rounds or adajcent plaintexts?
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!
Horst Ossifrage
Thank you for spending some more time on this. I am preparing
a long post for tomorrow, but for now, I just want to point out
a possible misunderstanding on your part of the nomenclature:
David Wagner wrote:
> The primary equation is C[i] = S{(P[i] + P[i+1]) xor C[i-1]},
> 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.
i is not the Round number, it is the word address in a Block.
A block with 76 bits has four 19 bit words:
Plaintext Block = P[0]P[1]P[2]P[3] concatenated.
> 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?
Your approach is educational for me. It helps to suppliment
the Paper. I expect that the Slide Attack will work, I am just
trying to write a perfectly clear document of how it is used
to break Scott19u.zip. I'll be back.
Horst Ossifrage, San Jose, California
SCOTT19U.ZIP_GUY
>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?
Jim...@postmaster.co.uk
(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...).
ps No offence mate!
SCOTT19U.ZIP_GUY
>In article <376298...@utah.net>, Horst Ossifrage <pai...@utah.net> 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_GUY
>In article <376298...@utah.net>, Horst Ossifrage <pai...@utah.net> 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 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.
>
>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_GUY
>
>
>Horst Ossifrage wrote:
>>
>> SCOTT19U.ZIP_GUY wrote:
>> >
>> > > against the Scott19u.zip cryptographic algorism. The
>> > > attack was introduced at the FSE-6 Conference in March,
>> > > 1999, Rome.
>> >
>>
>> read Mr. Wagner's paper about the Slide Attack.
>> It is an easy way to attack some ciphers with simple round
>> I will study it for two more days to confirm or refute his
>> claim.
>
>
>
>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
Tim Redburn
(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.
tomst...@my-deja.com
dsc...@networkusa.net (SCOTT19U.ZIP_GUY) wrote:
> 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.
Let's review. [sci] dot [crypt]. If we take the words alone we find
that this group is a scientific (or suppose to be) geared towards
cryptography. Personally I wuldn't mind a little non-scientific
posting, but you are way off.
BTW learn how to spell. My grammar might be bad, but I can spell at
least.
Stop posting nonce, it's not worth it. Really.
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!
tomst...@my-deja.com
dsc...@networkusa.net (SCOTT19U.ZIP_GUY) wrote:
> 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.
That's ironic considering you boast a cipher that requires 1.18MB
keys... :)
Get GSVIEW and ADOBE, if you want to read real papers you will most
likely need it (note that blowfish is a txt only paper...)
> Maybe yes or maybe not at this this isn't as pompous as your first
boast.
Maybe he is human? He probably shouldn't boast figures unless he can
substantiate them, but I trust him because well he knows more then me.
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!
tomst...@my-deja.com
dsc...@networkusa.net (SCOTT19U.ZIP_GUY) wrote:
> Actually it is rather well documented. It complies and runs on a PC
what
> more to you want?
>
We note that 'complies' should have been 'compiles'. Replace PC with
dos box under DJGPP. Note: Ciphers SHOULD NOT be language dependant.
It should be written as closely as possible to mathematically notation
first. Then ported to computer langs...
Besides a good cipher should run on PC's, in hardware and in smartcards
(what cpu is a good question). It should run in 2/3 of the targets at
least (say in hardware and pcs...)
SCOTT19U.ZIP_GUY
>On Sat, 12 Jun 1999 20:33:23 GMT, dsc...@networkusa.net
>(SCOTT19U.ZIP_GUY) wrote:
>
>
>> Actually it is rather well documented. It complies and runs on a PC what
>>more to you want?
>>
>
>
>The compiler complains that it can't find keys.h or pc.h, neither of
>which are included in the scott19u.zip file.
THe guy in germany was able to comple in visual C with out any problem.
(At least he had no problems with scott16u)
drop pc.h and key.h and change the access() to what every your system use
also change make more room for the arrays rt ft bt as I described in past
posts. This should allow you to compile. Put I don't have your system so
I can't tell exactly what is needed.
>
>-Tim.
David Wagner
SCOTT19U.ZIP_GUY <dsc...@networkusa.net> wrote:
> 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?
I'm not suggesting to attack a reduced version.
I'm referring to the earlier comment that the same S-box entry
will not be used in the first and last round, since in all likelihood
the 19-bit input to the S-box will be different.
This fact was claimed to make slide attacks impossible.
I was suggesting that this fact might not be so bad (for the attacker)
as it seems; that you can still make slide attacks work, even though
different S-box entries are used.
> >
> >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.
Oops, serves me right for not looking it up. Anyhow my point below it
is still valid (I think), you just have to change the equations slightly.
> 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.
Ok, I have to admit you lost me here. Sorry.
tomst...@my-deja.com
I added the round keys like we agreed on. The new copy is at
http://people.goplay.com/tomstdenis/simple.c
BTW if the code is not clear enough I could be motivated to document it
(I probably will anyways...)
Anyways I would like to break the following variations
1. No permutations (final/initial), no round keys
2. No permutations, with round keys
3. permutations, no round keys
4. Full thing.
I am willing to take the initial steps into the first one, but would
appreciate some newbie tips. I will have to get back to the group if I
can actually document an attack on #1.
#1, a one round attack could retrieve the entire table in 2^13 blocks.
This is a naive attack though. One two rounds I would try to find
patterns like (x, y, x, y) -> (a, b, a, b). I don't know how to
exploit this though. This would mean that the input to the sboxes for
the first and third was equal and likewise for the second and fourth.
I think it would require a lot of chosen plaintext since you would have
to cycle... I don't know. This is what I mean. I have the idea in my
head but I don't know how to push it.
You know that the output was
(x, y, x, y)
You know the last inputs must have been (a, b, a, b) From this you can
calc that the outputs of the first table was
a' = a - b
b' = 2b - a
c' = c - d
d' = 2d - c
If I am not mistaken. We still don't know a' .. d' though. Would this
be an example of soling using linear expressions? (I.e build a huge
matrix with all the expressions and try to plug in the s-box values
which make all the statements true?, this would be faster then
searching the entire key space as many solutions can be eliminated at
first glance)...
Geez... I am really lost.
Tom
SCOTT19U.ZIP_GUY
>In article <7jue3a$2ci0$1...@news.gate.net>,
>SCOTT19U.ZIP_GUY <dsc...@networkusa.net> wrote:
>> 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?
>
>I'm not suggesting to attack a reduced version.
Then you have to face the fact of the two other passes
front and back and also the fact that 8 bytes is the smallest
file. so there can be no attack less than 64 bits.
>
>I'm referring to the earlier comment that the same S-box entry
>will not be used in the first and last round, since in all likelihood
>the 19-bit input to the S-box will be different.
>This fact was claimed to make slide attacks impossible.
>
>I was suggesting that this fact might not be so bad (for the attacker)
>as it seems; that you can still make slide attacks work, even though
>different S-box entries are used.
>
>> >
>> >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.
>
>Oops, serves me right for not looking it up. Anyhow my point below it
>is still valid (I think), you just have to change the equations slightly.
>
>> 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.
>
>Ok, I have to admit you lost me here. Sorry.
Then lets do one pass of these 23 repeated center passes for scott19u.zip
You lay the file out in memory so you have 64 bits.
then define the last 19 bits is C[-1] then one you
do C[0]= S{ (C[-1] xor P[0] ) + P[1]}
know copy the contents of C[0] to the bottom of the file
you know have 83 bits.
note P[0] the first 19 bits P[1] the next 19 bits.
know comes the hard part replace the top 10 bits of P[0]
with the last 10 bits of C[0]. We have just calculated
the first 10 bits out for the pass.
Do C[1]= S{(C[0] xor P[1]) + P[2]} place C[1] right after the
loction in memory where C[0] is. That way know all of P[0]
is rewritten this pass and the first 10 bits of P[1]
Do C[2]= S{(C[1] xor P[2])+ P[3]) place C[2] right after C[1]
you know have from the top replaced 10 + 19 + 19 for 48 bits
at this point P[3] has 7 bits of itself and the top 12 bits of C[0]
Since 48 + 19 = 67 is greater than 64 the original lenght of
file you are done this pass calling the main equatiion
but there is 64-48 16 bits left
so you shift up the file from the bottom so that P[3] is placed next
to C[2] This is a 9 bit shfit. Notice that when you calulated C[0]
at front of pass and added this to bottom of file. You end up having
the nine bits lost from the first C[0] now at the bottom. This means
that for the 64 bit file only 3*19 57 bits are replaced so that 7 bits
are not changed this pass but are rotated in the file up 9 bit positions.
this means that those 7 bits which have not changed get changed
during the next pass since they are part of P[2] on the next pass.
tomst...@my-deja.com
> You lay the file out in memory so you have 64 bits.
> then define the last 19 bits is C[-1] then one you
> do C[0]= S{ (C[-1] xor P[0] ) + P[1]}
> know copy the contents of C[0] to the bottom of the file
> you know have 83 bits.
> note P[0] the first 19 bits P[1] the next 19 bits.
I am not attacking you but as a suggestion, lets review a more orthdox
cipher first. Will you entertain the notion of reviewing scottu16? If
it doesn't have the wierd bit field manipulations (well bit vectors is
ok...) then I think we can just review the operations. Anything we
come up with will most likely apply to scottu19 proportionally.
BTW splitting bits (10 bits here, 9 bits there) is not hard to program
(shift and mask), it is however slow in software.
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!
SCOTT19U.ZIP_GUY
>
>> You lay the file out in memory so you have 64 bits.
>> then define the last 19 bits is C[-1] then one you
>> do C[0]= S{ (C[-1] xor P[0] ) + P[1]}
>> know copy the contents of C[0] to the bottom of the file
>> you know have 83 bits.
>> note P[0] the first 19 bits P[1] the next 19 bits.
>
>I am not attacking you but as a suggestion, lets review a more orthdox
>cipher first. Will you entertain the notion of reviewing scottu16? If
I don't have a method called scottu16 could you have meant scott16u
>it doesn't have the wierd bit field manipulations (well bit vectors is
>ok...) then I think we can just review the operations. Anything we
>come up with will most likely apply to scottu19 proportionally.
>
>BTW splitting bits (10 bits here, 9 bits there) is not hard to program
>(shift and mask), it is however slow in software.
One could use shift and mask or one could use marcos in C with
the proper structures which is what I choose to do.
You could look at the scott16u version if you wish. I assume it would
be much easier to examin however it is a much older product.
but it is what the 1000 dollar contest that I have running is all about.
You could even win the money if your first to solve it for the changes
that I have. But time is running out you only have till Nov 11 1999
>
>Tom
Horst Ossifrage
>
> In article <7jumfq$b1m$1...@blowfish.isaac.cs.berkeley.edu>, d...@blowfish.isaac.cs.berkeley.edu (David Wagner) wrote:
> >In article <7jue3a$2ci0$1...@news.gate.net>,
> >SCOTT19U.ZIP_GUY <dsc...@networkusa.net> wrote:
> >> 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?
> >
> >I'm not suggesting to attack a reduced version.
>
> Then you have to face the fact of the two other passes
> front and back
Slide Attack Attempt Against Scott19u.zip
The cipher is immune to the Slide Attack because it uses
a non-periodic round structure. In the paper on the Slide
Attack, on page 2, paragraph 2 it says that the attack is
"easy to prevent by destroying self-similarity of an
iterative process".
The Scott19u.zip algorism has 25 rounds: the first one
and last one are the "Paul" function, and the middle
23 rounds are the ones described in the documentation
in great detail. I forgot to put mention of the Paul
function in the documentation, and I hope that David
Scott will edit that page on xoom.com to describe those
rounds. Here is part of the C program for encryption.
(It is made non-functional for export limitations).
Notice that it uses Paul(a, i19) before and after the
loop for the 23 middle rounds:
#define EPE (23)
void
doEnce(p19 * a, un32 x)
{
/* encrypts a file using 19 bit words */
un32 iz, izz;
un32 i, j, ip, ipp, k;
un32 i19, i19s, jj;
p19 *pp19;
po19 *ppo19;
void *v;
if (x < 8) {
printf(" this method for 8 or more characters only \n");
exit(1);
}
jj = ((x%19)*8+18)/19;
i19s = ((x%19)*8)/19;
i19 = ( x/19)*8 + jj; /* length of file in 19 bit units to cover it
all*/
i19s = ( x/19)*8 + i19s; /* length of file in full use 19 bit units */
v = a;
pp19 = a;
/* snipped to make non-functional to foil export usability 6/13/99 */
pf19 = v + x;
pb19 = v + x - 8;
Paul(a, i19);
if( i19 != i19s){
pf19->a00 = 0x7ffff;
iz = geto19(ppo19, i19-1);
pf19->a00 = 0;
izz = geto19(ppo19, i19-1);
i19s += 0 == ( iz ^ izz);
;}
for (i = 0; i < EPE; i++) {
k = pb19->a00;
ip = get19(a, 0);
ipp = get19(a, 1);
k = get19( ft, 0x7ffff &(( k ^ ip) + ipp) );
puto19(k, ppo19, 0);
pf19->a00 = k;
ip = ipp;
ipp = get19( a, 2);
/* snipped to make non-functional to foil export usability 6/13/99 */
puto19(k, ppo19, 1);
pf19->a01 = k;
for( j = 2; j < i19s; j++ ){
ip = ipp;
ipp = get19( a, j+1);
k = get19( ft, 0x7ffff &(( k ^ ip) + ipp) );
puto19(k, ppo19, j);
}
ip = get19( a, j+1);
puto19(ipp, ppo19,j);
puto19(ip, ppo19,j+1);
}
Paul(a, i19);
}
In conclusion, the cryptographic algorithm Scott19u.zip
is immune to the basic Slide Attack because the rounds
are not all the same. The first round is different from
the next 23 rounds. The last round is like the first round.
Thanks to David, David, Paul, Tom, Tim, and others for
participating in this discussion. Good bye.
fungus
tomst...@my-deja.com wrote:
>
> In article <3762AA10...@egg.chips.and.spam.com>,
> fungus <fun...@egg.chips.and.spam.com> 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.
>
One thing is when a person is willing to discuss algorithms and
methods.
Another thing is when somebody goes on and on about a program with
no published algorithms, methodology, or reasoning behind it, just
a big pile of messy C code for us to inspect if we can be bothered.
D. Scott has been pushing scott19 for about a year now. He claims
it's the answer to the NSA and that things like PGP shouldn't
be trusted. Then, as soon as somebody looks at it seriously it
falls apart.
It happened with scott16u, the result was scott19u. It happened with
scott19u and I have a horrible feeling that the "answer" will be
scott20u. The process will start all over again.
SCOTT19U.ZIP_GUY
Thanks Horst
For looking at the Slide Attack. I am glad you have analyzed it
deeply enough to find that it is immune to the basic Slife Attack.
I took Choosen Plain Text Attacks more seriously after Paul Onions
convinced me that it should be immune if possible to a single choosen
Plaintext attack. I have not read the full article yet of Wagners attack
but on the surface it sounds very similar to the work of Paul Onions
who desires a lot of credit. It was thoughts of him while consuming
vast quanties of my favorite german beer ( better than english beer sorry)
that lead to this first and last round function called the Paul function.
Yes I will add a write up in your section describing the routine.
But wish you would edit the english sense your better at it.
However I still feel that thousands of "total choosen plain text attack
files" Is not a realistic way to break any method. Since it would require
the enemy to send thousands of nonsense messages of the exact size
however I feel that it is a partial measure of securtiy just like the fact
that if you use any of the AES candidates and the blessed chainning
methods. An enemy needs on a small portion of you file to have enough
information to break your method. It is far better when sending complete
messages to use a "all or nothing encryption" method like scott19u.zip
The Paul routine was my first attempt to defeat plain text attacks and
my code should be analyzed in the mode where the encrypted file is
the same exact lenght as the input file. This is hard to achive with the
NSA approved chainning methods. But in reality to get a boost of security
beyond my basic approach I would encourage the mode where a random
pad is added to the front of file. Espeially useful for short messages.
If one has a good compler you can also add in my h2com.exe routine
if one is using files that are generally compressable with an adaptive
huffman compress.( I will add this in menu for next release). This is far
better than the way compression done in PGP. The compressed file has
no headers what so ever and unlike most compression routines was designed
to be used with encryption. In there are no headers in any file that an
attacker would stumble upon if guessing a key has the property that if
any file uncompress by my method it would recompress back to the same file. Do
not confuse this with the property shared by other compressors that any
compressed file uncompress back to the orginal file. If any one knows of any
other compression methods like this please let me know.
Thanks Again Horst
tomst...@my-deja.com
fungus <fun...@egg.chips.and.spam.com> wrote:
> One thing is when a person is willing to discuss algorithms and
> methods.
>
> Another thing is when somebody goes on and on about a program with
> no published algorithms, methodology, or reasoning behind it, just
> a big pile of messy C code for us to inspect if we can be bothered.
>
> D. Scott has been pushing scott19 for about a year now. He claims
> it's the answer to the NSA and that things like PGP shouldn't
> be trusted. Then, as soon as somebody looks at it seriously it
> falls apart.
>
> It happened with scott16u, the result was scott19u. It happened with
> scott19u and I have a horrible feeling that the "answer" will be
> scott20u. The process will start all over again.
Well I learnt. I wrote the first simple cipher. I didn't like it,
plus david wagner broke it (without round keys). So I wrote the newer
simple cipher. It requires far less ram and has a better design. The
thing is I understand why the first one was broken, I didn't just re-
invent the wheel (or problem in this case).
I actually understood the problem with the PHTs... maybe Dave Scott can
learn about efficient algorithm design? Maybe he will learn, I think
we should grant him a little patience. He thinks he is the be-all in
the world. Let him mature a bit and maybe he could contribute
usefullness.
My new cipher is at http://mypage.goplay.com/tomstdenis/simple2.c
As I said it's much easier to follow then my first. It's basically a
UFN but has diffusion in both directions. It relies on mixing add/xor
and the sboxes from CAST-128 for security. It includes a variable
length key schedule as well.
It probably could be broken but I hope to learn something (like I did
with the first) from it.
(BTW I gave up writing papers as most of my ideas are lessons not
actual ciphers that could be used. The C code is clean and easy to
follow so most people can analyze it fairly quickly)
SCOTT19U.ZIP_GUY
>>
>> In article <3762AA10...@egg.chips.and.spam.com>,
>> fungus <fun...@egg.chips.and.spam.com> 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.
>>
>
>methods.
>
>Another thing is when somebody goes on and on about a program with
>no published algorithms, methodology, or reasoning behind it, just
>a big pile of messy C code for us to inspect if we can be bothered.
>
>D. Scott has been pushing scott19 for about a year now. He claims
>it's the answer to the NSA and that things like PGP shouldn't
>be trusted. Then, as soon as somebody looks at it seriously it
>falls apart.
>
>It happened with scott16u, the result was scott19u. It happened with
>scott19u and I have a horrible feeling that the "answer" will be
>scott20u. The process will start all over again.
>
>
Actually you are lying it never happened with scott16u. I made scott19u
since it was the largest size that could have a key that could cover any
possible single cycle S-table of 19 bits. Why do you have to ly and if you
read Horst's last comment he says it does not fall apart under the basic
Slide Attack. Yet assholes like you keep remembering the partial comments
of the spammer mr BS and David Wagner who consider it dead yet don't
have the time to look at it.
I am not a kiss ass false crypto god that is afraid some ametuer is going
to shoe them up. When can ass holes like you get that through your thick
head. Again for you 'SCOTT16U" was never broken and I have a contest
for it with a thousand dollars that expires on Nov 11 this year. Last year
one of the crypto gods called the contest a joke since it was a short time
the asshole went in to say not enough time. I had to write the asshole to
explain that it didn't expire to NOV 11 1999 needless to say the asshole
never correct his error. They like to make sweeping statements to mislead
but seldom clean up the mis truths they spread. And assholes like you
continue to spread there lies.
tomst...@my-deja.com
You still don't get it do you? Too bad. You think the whole point of
this is to have some super duper encryption algorithm. I think it is a
means to advance cryptography. I am by no means a leader here. I have
lots to learn, but I am. You profess that your algorithm is super
duper strong, perhaps it is, but really what is so good about it?
Many ciphers are practically secure (i.e require over 2^128 work to
crack etc...) and are much easier to use then yours. The point of
cryptography in my eyes is to prevent (or deter) fraud. I really don't
care what you had for lunch yesterday, neither does the NSA. If your
algorithm cannot be mass produced in any way, shape or form then what
is the point?
I can build a secure block cipher too, just give me 2^67 bytes of ram
and 2^64 time and I will be with you. But that's not the point. The
idea is to take 2^10 bytes of ram and 2^5 time... etc...
So get off your high horse and realize that you don't know everything.
Neither does David Wagner, the infamous Bruce and even me. If you can
learn (or appreciate other peoples views) something from your
experiences then well I would be more then happy to tag along and help
out. But you are so set in your ways that I don't know why people
(including me) even respond to you.
BTW a single message is not much of a contest. What if I found a break
(just hear me out) that requires 2^30 chosen plaintexts. It's still a
break but I cannot use that to crack your one message. I would put the
1000$ towards the first person to break your cipher. and how do we
know that the 'ciphertext' is really not just random bytes thrown
together?
Horst Ossifrage
>
> In article <3763AA...@utah.net>, Horst Ossifrage <pai...@utah.net> wrote:
> >Slide Attack Attempt Against Scott19u.zip
> >
> >The cipher is immune to the Slide Attack because it uses
> >a non-periodic round structure.
> Thanks Horst
> For looking at the Slide Attack. I am glad you have analyzed it
> deeply enough to find that it is immune to the basic Slife Attack.
> Yes I will add a write up in your section describing the routine.
> But wish you would edit the english sense your better at it.
> David A. Scott
Yes David,I will edit your documentation page, again. You
have my phone number and true e-mail address, so let's start
writing a couple of paragraphs on it tomorrow. My machine
will contact your machine.
Horst Ossifrage (not)
----------------------------
Download Scott19u.zip today! Expect nothing, get everything!
SCOTT19U.ZIP_GUY
>In article <37634F7C...@egg.chips.and.spam.com>,
> fungus <fun...@egg.chips.and.spam.com> wrote:
>> One thing is when a person is willing to discuss algorithms and
>> methods.
>>
>> Another thing is when somebody goes on and on about a program with
>> no published algorithms, methodology, or reasoning behind it, just
>> a big pile of messy C code for us to inspect if we can be bothered.
>>
>> D. Scott has been pushing scott19 for about a year now. He claims
>> it's the answer to the NSA and that things like PGP shouldn't
>> be trusted. Then, as soon as somebody looks at it seriously it
>> falls apart.
>>
>> It happened with scott16u, the result was scott19u. It happened with
>> scott19u and I have a horrible feeling that the "answer" will be
>> scott20u. The process will start all over again.
>
>plus david wagner broke it (without round keys). So I wrote the newer
>simple cipher. It requires far less ram and has a better design. The
>thing is I understand why the first one was broken, I didn't just re-
>invent the wheel (or problem in this case).
>
>I actually understood the problem with the PHTs... maybe Dave Scott can
>learn about efficient algorithm design? Maybe he will learn, I think
>we should grant him a little patience. He thinks he is the be-all in
>the world. Let him mature a bit and maybe he could contribute
>usefullness.
>
>My new cipher is at http://mypage.goplay.com/tomstdenis/simple2.c
>
>As I said it's much easier to follow then my first. It's basically a
>UFN but has diffusion in both directions. It relies on mixing add/xor
>and the sboxes from CAST-128 for security. It includes a variable
>length key schedule as well.
>
>It probably could be broken but I hope to learn something (like I did
>with the first) from it.
>
>(BTW I gave up writing papers as most of my ideas are lessons not
>actual ciphers that could be used. The C code is clean and easy to
>follow so most people can analyze it fairly quickly)
>
>Tom
Tom you are don't seem to understand that I do learn. You are jumping
in on this thread as a jhonny come lately. Mr BS and Mr Wagner have
a large hatred for people that are not in the crypto click. I have done
everything possible to help these individuals with my code. They have
the time to say its broken. But never the time to do an honest evaluation.
They only comment on ameture stuff that they can easily break. Hang
around this group for a few years and you will see.
As for my style it is my style and the source code is inculded if you
would get off your high horse even a newcomer that you could follow the
code but you have to think and use your brain a little. So give it a try.
SCOTT19U.ZIP_GUY
The idea for me any way is to write something that so not to slow
that should run on a PC and give people the maximun secrity in the
encrypted result and not to see how close I can skate to making the
key short. What you don't understand is that once one has a keyenc.key
file you can use your short pass phrase as the key much as in PGP
I hope the consept it not over your head.
>So get off your high horse and realize that you don't know everything.
>Neither does David Wagner, the infamous Bruce and even me. If you can
If you read the "infamous Bruce" posts you can see the stuff he writes.
He clains ametuers can't write or come up with good encryption methods
he is the one on the high horse. Yet he critizes other with out looking
because of his ego he thinks he knows all. ALso if you bother to read his
posts he had a comment that it is much harder to design an emcryption
method with a large key so maybe you can't do it. But I feel that maybe
you can. As far as the "Slide Attack" goes there was a post about Blowfish
and this attack. I don't know if the post was true. But if it was how could
the great cypto god design such a poor cipher. The reason I doubt if it was
true is becasue both guys are in the club and need to pat each other on
the back know and then so I doubt if the break is true. Because if it was
true they would most likely hid the facts or at least down play the
significance of it.
>learn (or appreciate other peoples views) something from your
>experiences then well I would be more then happy to tag along and help
>out. But you are so set in your ways that I don't know why people
>(including me) even respond to you.
>
>BTW a single message is not much of a contest. What if I found a break
>(just hear me out) that requires 2^30 chosen plaintexts. It's still a
This contest is more fair than the IDEA contest run awhile back if
you bother to take a look. But then your new to this game and
don't know much. But you catch on quick when it comes to trying
to look good but you don't know enough yet. Sice you are still wet
behind the ears.
>break but I cannot use that to crack your one message. I would put the
>1000$ towards the first person to break your cipher. and how do we
>know that the 'ciphertext' is really not just random bytes thrown
>together?
>
>Tom
Tom do you have a 1000 dollars that you can put towards a contest.
Do you think it is ethical to run a contest and offer a prise with out
having that much spare cash. I don't think that would be ethical but
maybe you ethical level is lower than mine.
Also you don't know if the contest is random jiberish but the
last ones where not. I have been posting for years I am not
about to run a contest and not have the solution file. However
your new with no history you might run such a contest.
fungus
tomst...@my-deja.com wrote:
>
> maybe Dave Scott can
> learn about efficient algorithm design? Maybe he will learn, I think
> we should grant him a little patience. He thinks he is the be-all in
> the world. Let him mature a bit and maybe he could contribute
> usefullness.
>
"Mature a bit"?
In my experience he gets worse as time passes.
tomst...@my-deja.com
dsc...@networkusa.net (SCOTT19U.ZIP_GUY) wrote:
> Tom you are don't seem to understand that I do learn. You are
jumping
> in on this thread as a jhonny come lately. Mr BS and Mr Wagner have
> a large hatred for people that are not in the crypto click. I have
done
> everything possible to help these individuals with my code. They have
> the time to say its broken. But never the time to do an honest
evaluation.
> They only comment on ameture stuff that they can easily break. Hang
> around this group for a few years and you will see.
> As for my style it is my style and the source code is inculded if
you
> would get off your high horse even a newcomer that you could follow
the
> code but you have to think and use your brain a little. So give it a
try.
Really? You learn. Yeah right. That's why all of your ciphers are of
the same design? I don't think you are a dolt. You have some brains
and you know how to use them. But you have to be more receptive of
comments. Your code is really messy, sorry but it's the truth. I
don't mean to gloat but if you look at my code it's too the point and
cut/clean. When you do examples they are not suppose to be highly
optimized, they are suppose to be clean (or pedagothic, I think that's
what it said...).
I don't think you have ever sent an email to Mr. Wagner befor have
you? He is a really nice person and smart too. I have written to him
before in private email and found him to be helpful. Maybe it's your
attitude towards anyone who isn't you? Other people like Bruce S. have
better things todo then comment on us low newbies. I think it's mean
but that's life.
Tom
--
PGP key is at:
'http://http://mypage.goplay.com/tomstdenis/key.pgp'.
tomst...@my-deja.com
dsc...@networkusa.net (SCOTT19U.ZIP_GUY) wrote:
> The idea for me any way is to write something that so not to slow
> that should run on a PC and give people the maximun secrity in the
> encrypted result and not to see how close I can skate to making the
> key short. What you don't understand is that once one has a keyenc.key
> file you can use your short pass phrase as the key much as in PGP
> I hope the consept it not over your head.
Geez let me see if I can understand. Sloppy + Slow = Good ?
> If you read the "infamous Bruce" posts you can see the stuff he
writes.
> He clains ametuers can't write or come up with good encryption methods
> he is the one on the high horse. Yet he critizes other with out
looking
> because of his ego he thinks he knows all. ALso if you bother to read
his
> posts he had a comment that it is much harder to design an emcryption
> method with a large key so maybe you can't do it. But I feel that
maybe
> you can. As far as the "Slide Attack" goes there was a post about
Blowfish
> and this attack. I don't know if the post was true. But if it was how
could
> the great cypto god design such a poor cipher. The reason I doubt if
it was
> true is becasue both guys are in the club and need to pat each other
on
> the back know and then so I doubt if the break is true. Because if it
was
> true they would most likely hid the facts or at least down play the
> significance of it.
The break on blowfish was against a variant which had the round keys
removed. Of course you would know that if you read the paper, you know
nothing waste of space. (Revenge is bittersweet...)
> This contest is more fair than the IDEA contest run awhile back if
> you bother to take a look. But then your new to this game and
> don't know much. But you catch on quick when it comes to trying
> to look good but you don't know enough yet. Sice you are still wet
> behind the ears.
Well I just got out of the shower, how did you know that? Most
contests have a purpose. The DES challenge was to show that the key
could be searched really quickly. The Twofish team put $10000 dollars
where their math is. They put the money towards the first person to
break the cipher, not a message. You could do the same.
> Tom do you have a 1000 dollars that you can put towards a contest.
> Do you think it is ethical to run a contest and offer a prise with out
> having that much spare cash. I don't think that would be ethical but
> maybe you ethical level is lower than mine.
> Also you don't know if the contest is random jiberish but the
> last ones where not. I have been posting for years I am not
> about to run a contest and not have the solution file. However
> your new with no history you might run such a contest.
I don't need to pay people to talk to me. If I want to break my own
algorithm I will ask for comments and work it out myself. Unlike you I
ask for help and am receptive. David helped point out a method of
breaking my simpler cipher (the first one without round keys), now I
can see why round keys are very important. etc...
I think you should really just calm down. This is suppose to be about
cryptography and not who you can attack next. We all have tried to
help you, and you insist on being a mean bitter person. I maybe the
youngest poster here but I am no fool. Good day to you sir.
David Wagner
> The cipher is immune to the Slide Attack because it uses
> Attack, on page 2, paragraph 2 it says that the attack is
> "easy to prevent by destroying self-similarity of an
> iterative process".
>
> The Scott19u.zip algorism has 25 rounds: the first one
> and last one are the "Paul" function, and the middle
> 23 rounds are the ones described in the documentation
> in great detail. I forgot to put mention of the Paul
> function in the documentation, and I hope that David
> Scott will edit that page on xoom.com to describe those
> rounds.
Ahh, there's a special first and last round!
I agree: that should make a slide attack a lot harder (maybe impossible).
Thanks for posting the information.
David Wagner
I followed the information that I found on the web page (which didn't
describe the special first and last rounds). Even that was hard to read.
In general, if you wrote a concise, descriptive article describing the
algorithm, it would greatly increase your chances of having good people
look at it seriously. Right now the barrier is much too high.
Remember, the experts will not even consider spending time on cryptanalysis
ciphers posted on the net, no matter whether they are well described.
For fun, I sometimes look at net-ciphers, but I'm no expert.
SCOTT19U.ZIP_GUY
>
>Well I just got out of the shower, how did you know that? Most
>contests have a purpose. The DES challenge was to show that the key
>could be searched really quickly. The Twofish team put $10000 dollars
>where their math is. They put the money towards the first person to
>break the cipher, not a message. You could do the same.
>
Actually Tom your wrong the break that this phony contest is willing
to pay for is not black and white. Its for a paper attack that Mr B.S. thinks
is worth rewarding. If some one like me solved it I would get zero. I think
even if Paul Onions came up with a decent break he would get nothing.
But later when one of the crypto clubers writes up Pauls attack the other
crypto god would get the money if it is deemed good enough by the crypto
gods.
I offer a contest that is black and white it is either solved or not.
His is like as essay contest. Some people good at BSing are good
at those kind of tests. I guess I am more a multiply chioce kind of guy.
Also the kind of contest the crypto gods run limits the hacker types
from bothering to look. They are scared to death to run a real contest
becasue some nobody could post a solution here. But a nobody who
write an honest attack that was not skilled in the narrow vocabulary that
they use would have zero chance to win.
Look at what I have. Code that the crypto gods both of them said was
dead. Think about Dave Wagner said scott19u was dead years ago. Of
course he will say that was the one Paul Onion solved. Since he has to
make up something. But the truth of the matter is Crypto Gods don't ever
want to say good about a cipher unless your in the Club. Yes I expected
Mr BS and or Dave W. to say things like the Slide Attack makes it dead but
they know better. How about trying to get some honest anwsers from them
about scott19u. You will not other than them saying the key that can be used
is to big or they personally consider it to slow. But is there a weakness in
how it encrypts. You can beat your ass that if they had one they would
mention it but they don't. Sorry that it is to strong for the toy break so
much for the slide attack.
Tom the main reason the Crypto Gods Slide Attack failed is that they are
only use to very narrow ideas in crypto. There minds are closed to the other
ways of doing things. Kind of like the Swiss watch makers when the Japanese
came out with quartz watches. The Swiss where slow to change becase they
thought they new all about watches. The crypto gods are the same way. But
they may know a little more than the Swiss it is just they think they can
control the course of crypto in the world so that through contests like the
AES the NSA will still be able to read your encrypted mail.
SCOTT19U.ZIP_GUY
Dave it is nothing NEW I even stated that before. Why are you pretending
this is new. THere is only one version of scott19u.zip and only one version
of scott16u.zip You so proudly delared them dead. But as usually you really
don't bother to look because I am not a kiss ass crypto god. But I would
welcome you or anyone else to test it out. It is there source code and all.
Sorry if you lack the skills to read C but there is a PC executable also.
But why do you types alwasy delcare something busted and boast so much
with out really looking at it. Is it common that if your a crypto god you can
just put stuff down with out every trying it. Yes I know I follow a different
drum but the "all or nothing fearuers" found in my code should be in any
modern cipher that is for file and message transfer. But then you may
not understand what I am talking about the concept could be over your
pardigma.
SCOTT19U.ZIP_GUY
>I don't have time to dig through pages and pages of hard-to-read code.
>I followed the information that I found on the web page (which didn't
>describe the special first and last rounds). Even that was hard to read.
Yeah I see you couldn't even copy a one line equation correctly
>
>In general, if you wrote a concise, descriptive article describing the
>algorithm, it would greatly increase your chances of having good people
>look at it seriously. Right now the barrier is much too high.
>
However that barrier does not seem to high for you and a few other
crypto gods to declare that the cipher was dead. I sure the germans
did not give the engish (polish) something at least as well as I am
giving you. Rember I give code that would compile and run. Also I
offered to enter the AES contest but was turned down since ps
format was required. If they ever run a open honest contest allowing
ascii or something like HTML I might enter.
I frankly find it amussing that you think the crypto experts are worth
being catered to. The barrier is only high if you to dam lazy to look at
it. It was declared dead by you by your slide attack and that was
wrong. I hope to be a pain in the ass to false crypto gods for years
to come. My daughter went to your school she changed majors and
still got out in three years. Berkeley is vastly overated. The dorms
are full of pot and the graduates have an ego that doesn't quit.
The brightest one seem drop out maybe they feel cheated after
seeing what berkeley is really like.
>Remember, the experts will not even consider spending time on cryptanalysis
>ciphers posted on the net, no matter whether they are well described.
>For fun, I sometimes look at net-ciphers, but I'm no expert.
I can see you are no expert. Since you know the S-table is the only thing
that counts after it is built one needs to only look at the last 4 routines in
scott19u to get an idea of how the code works. Again it is not pages and
pages in that section. The macros are self explanatory. But I don't expect
you to read it like I said I am not a Crypto God. Maybe next time you can
come up with an attack on some toy cipher as good as Paul Onions.
And the so called experts are only the phony ones in your crypto club
I write code so the common user can encrypt his files so ivory tower
types like you and the NSA can not break it. Short of a gun at your
throat or a nsa virus on your machine or camera in your house this
is not the kind of toy code you guys bless for the ignorant masses to
use. This is much better than that. I could give a shit if the boasting
sounds like snake oil. At least it is not a false modesty that people
like you use. Yes it is easy to say its broken and then when you fail
blame it on the fact you can't read it.
Face the facts your highly praised slide attack does work on real
world stuff that an ametur can come up with. Yes I guess you did
find some toy ones to break. I am sure you have tried to break mine
at least via the grape vine I hear so called fasle crypto gods have
looked and they can't break it yet. Yes I am a pain in the ass
aren't I.
tomst...@my-deja.com
Look, no one is going to use your cipher unless you document it. Plus
it's slow and requires to much ram. I would rather use another
symmetrical cipher that requires much less ram and has a higher output.
Why not work on trying to improve your cipher instead of jumping on
everyone. You know what needs to be corrected, so why not do yourself
a favor and correct it.
I still find it ironic you boast a cipher with 1.2MB keys and don't
have enough space for a postscript printer driver. You whine about not
getting into AES? Geez I wonder why.. hmm
1. 128-bit BLOCK CIPHER
2. 128, 192, 256-bit KEYS
3. Fast (software)
4. Low memory (smartcards/hardware)
You fail to meet 3 of the 4.
Tom
SCOTT19U.ZIP_GUY
tomst...@my-deja.com wrote:
> <snip insane rambling comments>
>
> Look, no one is going to use your cipher unless you document it. Plus
> it's slow and requires to much ram. I would rather use another
> symmetrical cipher that requires much less ram and has a higher
output.
>
> Why not work on trying to improve your cipher instead of jumping on
> everyone. You know what needs to be corrected, so why not do yourself
> a favor and correct it.
>
Tell you what you have the source code and have some
spare time and claim you want to learn something. If you
add the bug fix for the arrays I already supplied that
so it could be done on other machines. I will give you
50 dollars if you can write in a form that Wagner and Mr
BS himself would say that it is documented well enough
for them to follow. The fact is you can't write it that
well becasue they are to dam lazy to use there brains.
You don't get it. The cipher is to tough for them.
I have worked with there types before. You can get any
expert to write it and they will bitch because they don't
want to try to crack anything very hard. I am offering
50 dollars to you. May some others would throw in some
extra cash to make it worth your while. But your yonng
yet you don't understand the tatics the phony crypto
gods use. You yourself could never write this method
in a form that runs and that they would admit to publicly
understanding. It is kind of like the president arguing
that he was never alone with Monica. He has never admitted
that while every knows he was.
> I still find it ironic you boast a cipher with 1.2MB keys and don't
> have enough space for a postscript printer driver. You whine about
not
I read ps when the http adress was given and it
worked. Yes I have about 20 megs of harddrive space
the executable for the read was 3 megs unexpanded
I didn't risk crashing my system. I don't even have
space to compile the bug fix for scott19u but did
test the fix in scott16u and the contest solution
with final keyenc.key file and password works the
same in both. ALso i think you missing something
I really only have one key that is 1.2MB if you use
the keyraw.key file you can make it as short as 1 byte
howeve I would recommend a slightly longer one but you
can use the full 1.2 megs if you want too.
> getting into AES? Geez I wonder why.. hmm
>
> 1. 128-bit BLOCK CIPHER
> 2. 128, 192, 256-bit KEYS
> 3. Fast (software)
> 4. Low memory (smartcards/hardware)
>
> You fail to meet 3 of the 4.
Yes scott19u was not the one meant for the
AES contest. scott19u was meant to encrypt files
to a much higher level of security than the
short keyed version required by the AES. Yes
I wanted to enter but it would not have been the
scott19u entry but nice try.
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>
--
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
tomst...@my-deja.com
On purpose?
<snip>
Tell you what. No. I might be able to read your code and fix it. Or
I could sit and do something else. hmm. Your right though. Your code
is tough, tough to read that is. I mean just because people don't
understand your code doesn't make it superior. Blowfish is easy to
understand and provides a high level of security, or did you miss
that? By trying to make your code legible will help others read your
cipher. You love text files so much why not write it up? You claim
the algorithm is really simple, prove it.
Let me guess though, you are going to respond with nonce ramblings...I
will tell you this. If you don't clean up your act there are going to
be many people putting your email in a kill file. You will get no
attention and people will just stop caring.
BTW stop saying AES ciphers are weak, not all of them have been proven
weak. (yet). Neither has yours (yet). Can you break any AES cipher
with your superior knowledge?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.