Cryptography-Digest Digest #703, Volume #9 Sat, 12 Jun 99 13:13:03 EDT
Contents:
Re: LSX Encoder ? (" ")
Re: Slide Attack on Scott19u.zip (SCOTT19U.ZIP_GUY)
Re: I challenge thee :) (smoke_em)
Re: Slide Attack on Scott19u.zip (Horst Ossifrage)
Re: MD5 test data (Jim Gillogly)
PKCS#10 request (Tomislav Posavec)
Re: Slide Attack on Scott19u.zip (Geoff Thorpe)
Re: Does scott19u.zip make full use of it's large key size ? ([EMAIL PROTECTED])
Re: I challenge thee :) ([EMAIL PROTECTED])
Re: ATTN: Bruce Schneier - Street Performer Protocol ([EMAIL PROTECTED])
Re: Question from a neophyte ([EMAIL PROTECTED])
Re: cant have your cake and eat it too ([EMAIL PROTECTED])
Re: Slide Attack on Scott19u.zip ([EMAIL PROTECTED])
OTP is it really ugly to use or not? (Cyba Nonymous)
----------------------------------------------------------------------------
From: " " <[EMAIL PROTECTED]>
Subject: Re: LSX Encoder ?
Date: Sat, 12 Jun 1999 00:49:50 -0700
Hello,
Thank you for your help...and I don't know the name a such a program ! I will try your
advices.
Thank you.
--
On Mon, 07 Jun 1999 17:06:27 tomstdenis wrote:
>
>> Does anyone know how to encode pictures in a .lsx format ?
>> Bye.
>>
>
>What program makes .LSX files? Maybe I could track something down for
>you. BTW this may be off topic as algorithms normally do not specify
>file name extensions.
>
>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.
>
>
>>
>
--== 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 14:01:20 GMT
In article <7jromi$7h3$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
>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
--
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: smoke_em <[EMAIL PROTECTED]>
Subject: Re: I challenge thee :)
Date: Fri, 11 Jun 1999 23:53:25 +0200
Patrick Juola wrote:
> You can't 'practically eliminate' frequency analysis unless your
> codebook is so large that almost every message is a very few chunks
> and codebook entries aren't repeated.
Does this not apply to block ciphers as well or is it part of the
definition of a (serious) block cipher that ECB lookup is not deemed
practical?
The latter, about key, i am aware of. I.e. that i have to make sure that
all words of the key are unique, since there will be duplicate
dictionaries otherwise.
BUT, if i understand you correctly, that would not be enough? I'd have
to ensure that for all i<>j (0<=i<j<keywords_in_key) that
map[i][h]<>map[j][h] for all h, where h is a wordsized plaintext block?
> The problem is that I can calculate frequencies with almost arbitrary
> precision *based on conditions that I know to obtain about you and your
> messages.*
Point taken, though i guess that applies to an attack on any cipher in
varying degree - but can you also do it if i use CBC mode?
The bit of frequency analysis (simple byte frequency of ciphertext) that
i have done on a >600k ascii document shows that ECB mode does some
work, but the sorted frequency curve still shares some characteristics
with that of the plaintext. With CBC mode, the result was *a lot* closer
to even distribution of frequency - with my newbie eyes no similarities
came to mind.
------------------------------
From: Horst Ossifrage <[EMAIL PROTECTED]>
Subject: Re: Slide Attack on Scott19u.zip
Date: Sat, 12 Jun 1999 07:25:47 -1000
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>,
> Horst Ossifrage <[EMAIL PROTECTED]> 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
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: MD5 test data
Date: Fri, 11 Jun 1999 16:09:44 -0700
Tony Lezard wrote:
> I need to test the output of an MD5 implementation. Could someone with
> a known correct version of MD5 hash some strings and post/email them?
RFC 1321 has a test suite.
--
Jim Gillogly
Trewesday, 21 Forelithe S.R. 1999, 23:09
12.19.6.4.16, 13 Cib 4 Zotz, Sixth Lord of Night
------------------------------
From: Tomislav Posavec <[EMAIL PROTECTED]>
Subject: PKCS#10 request
Date: Sat, 12 Jun 1999 15:06:02 GMT
Looking for freeware source code to generate PKCS#10 cert requests.
Does anyone know if something like that is out there? Thanks.
-Tom
------------------------------
From: Geoff Thorpe <[EMAIL PROTECTED]>
Subject: Re: Slide Attack on Scott19u.zip
Date: Sat, 12 Jun 1999 16:18:06 +0100
Hi,
"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???
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Does scott19u.zip make full use of it's large key size ?
Date: Sat, 12 Jun 1999 15:06:53 GMT
> Due to the large key space it is possible to consturct a table such
> that 2 messages that differ from each other from each other by a bit
> to use completely different parts of the S-table so that the many
> internal passes look different but that the final output is slightly
> differrent however this is a very very rare case and to try to find
> one by trying various keys and inputs. Would require the time
> of the sun to burn out as people in this group like to point out.
> however if you write a small message it is easy to change the
> S-table on the last pass to make a ouput that is very similar to
> the first input.
Large or not similar messages are always possible. It is possible to
have C=E(P) and C'=E(P') where the hamming distance of (C, C') is less
then/greater then n/2 (n = bits per block). (hamming distance of (P,
P') is biased too). If this is not possible your cipher is bad.
(note: it may be improbable say one out of 2^128 messages will exhibit
strong chars like this(.
> For a given input message not all output messages are possible
> if one varyes the key except for short messages then all outputs of
> the same size are possible.
Then your cipher is bad. For any n bit input (2^n possible messages)
*ALL* 2^n outputs must be possible. This should be indepedant of the
key (note when the key is larger then n, some messages will share
mappings (from plain to cipher) but not for the entire set of messages).
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: I challenge thee :)
Date: Sat, 12 Jun 1999 15:27:29 GMT
> You can't 'practically eliminate' frequency analysis unless your
> codebook is so large that almost every message is a very few chunks
> and codebook entries aren't repeated.
Well you could have a 2^64 book with 2^3 bytes per block. That would
require 2^67 bytes of ram, but thwart analysis. Hey wait that already
exist (RC5-32, Blowfish, TEA, TEA-X, DES, CAST, etc...)
If any block is repeated even in large block scenes freq analysis can
work. If for example you are using 16 bit blocks for delta coded
samples the lower values are more common then the higher (aha!!).
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: ATTN: Bruce Schneier - Street Performer Protocol
Date: Sat, 12 Jun 1999 15:23:39 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bruce Schneier) wrote:
> I don't think so. Calling something non-scientific is not an attack.
> Most everything I hold dear in life isn't particuarly scientific. As
> far as I know, sci.crypt is a discussion list. Even
> sci.crypt.research, which we created to have more mathematical content
> than sci.crypt, isn't particularly scientific. There's nothing wrong
> with that; I skim both lists regularly.
And we enjoy your company (as in presence). BTW any news about
blowfish? Is it still the wickedly cool algorithm I believe it is?
Any variants using less memory?
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: Question from a neophyte
Date: Sat, 12 Jun 1999 15:20:30 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
Cool my links went to good use. I would read those papers and get
exposure. Read as much as you can. That's what I did, and by any
regard I am still a newbie. Getting a good knowledge base will aid you
in the field. If you focus on what aspect you may miss out (like
DaveScott is...).
The papers (TEA/RC5/Blowfish) are the best to start with. You will get
exposure to what a block cipher looks like and what they actually do.
Those papers are conceptually easy to read (which is why I started with
them). Just by writing random stuff you will not advance much unless
you understand the choices you made (and not by hairs on your ass,
sorry that's another DaveScott joke...). I did that alot and didn't
really get far. I had to work more seriously (i.e read the papers and
try to understand their choices).
Good luck and happy hunting.
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: cant have your cake and eat it too
Date: Sat, 12 Jun 1999 15:12:54 GMT
In article <7jru79$pr2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>
> The problem is yes it is possible in thery to consturct a cipher
> of 128 bits key that is do secure only a brute force search is
possible
> however how does one go about proving it is that secure. Far better to
> use a simler cipher with a longer key.
Who says a larger key is more secure? Consider a OTP with a 256bit
repeating key. That's large but is it secure?
Consider TEA with a 128 bit key, it was broken much faster then a brute
force. Consider DES with a 56 bit key it requires about that much
effort. Consider Blowfish/RC5 with a variable length key, there are no
attacks against those! The key in RC5 can be as small as 64 bits and
still be secure.
Large keys *do not* equal automatic security, sorry if this truth
hurts...
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 15:00:21 GMT
<insanely bad msg>
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 :)
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: 12 Jun 1999 17:06:02 -0000
From: Cyba Nonymous <[EMAIL PROTECTED]>
Subject: OTP is it really ugly to use or not?
I read in this group that the security of an OTP depends on the
pad being random. Really random and not just pseudo-random. OK so
let's say that I buy that for the moment.
I can see how OTP security works because any message can be
decoded into every possible message of its length using some
"key". So brute force can never work on an OTP because you
will get every possible message in the process and that gets you
nowhere.
Ok that brings me to my first question which is.... even if the pad
is not random it still seems to me that the message will decode
into just as many messages with just as many keys? Yes? No?
I'll assume that the answer is yes and that there is some mystery
math that can determine hey this was encrypted with a key that
was not random and therefore there must be only one message
and this is it! If the answer to that is yes then I don't believe it.
And, if it is true (which is possible because I am a dummy) then
why can't I exploit that and encrypt a (fake) message with a non random
key to get a stream of ciphered text and then derive another key that
gives me another message (the real one)? Now the mystery
math will give the cracker the "wrong" message..right? I could
go on and on but I think you experts will see the point I am trying to
make and point out the error of my thinking.
Oh, and yes I know that doing the above I now have created a
new pad right? And, I'd guess it is not random either. Is that
right? So does that mean that there are also n messages that can
be gained from using every possible non-random key too?
The other thing that pops into my mind is random versus repeating.
I guess I can see how a repeating key would be a problem. But , are all
random keys non-repeating? Are all repeating keys non-random?
If I have a pnr that repeats after a million numbers but I only use
the first 100 thousand is that not ok?
Next question. Ok I'll assume that I am wrong in my suggestion
above that an OTP can still be secure even with a non-random pad.
But, let's say I have a CD full of real random numbers for now and
a program that uses a math formula and a codeword to compile a
temporary pad for a particular message from that CD full of
random numbers. Is this not secure as long as I never use the same
codeword twice and the program will never generate the same pad
for another codeword? Also, can't I now send that codeword in the
clear? What's the advantage you say over just using the CD full of
randon numbers in the first place? Well, its because using this
method from one CD of real randon numbers you can generate an
infinite number of pads? Yes? No?
Perhaps this is all rubbish thinking to the experts but these things
have been nagging me for a long time and I would like to know
if I am all wet why I am.
Oh yeah and what if I took a video CD and scrambled it and then
if I took another video CD and scrambled it. And, then I scrambled
the two of them together. And, then I used that CD with the program
above to generate these temporary pads from codewords. How would
you rate the ability of someone to crack a particular message using this
OTP method? Easy, Moderate, Hard, Very Hard, Impossible ?
I am real curious to hear the feedback. Look, and I already know
I am a dummy so please temper your scorn. Thanks.
------------------------------
** 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
******************************
