Cryptography-Digest Digest #717, Volume #9 Mon, 14 Jun 99 10:13:03 EDT
Contents:
Re: Slide Attack on Scott19u.zip ([EMAIL PROTECTED])
Re: OTP is it really ugly to use or not? ([EMAIL PROTECTED])
Re: Export restrictions question ([EMAIL PROTECTED])
Re: encrypt using ASCII 33 to 126 only? ("Kenneth N Macpherson")
Re: encrypt using ASCII 33 to 126 only? (James Pate Williams, Jr.)
Re: Random numbers on a sphere (Dave Seaman)
Re: Slide Attack on Scott19u.zip ([EMAIL PROTECTED])
Prime number generators... (Krunoslav Leljak)
Re: encrypt using ASCII 33 to 126 only? ("Kenneth N Macpherson")
Re: OTP is it really ugly to use or not? (Mok-Kong Shen)
IDEA in "aplied cryptography" BRUCE SCHNEIER (chciago)
Re: Slide Attack on Scott19u.zip ([EMAIL PROTECTED])
Re: OTP is it really ugly to use or not? ([EMAIL PROTECTED])
Re: PKCS#10 request ([EMAIL PROTECTED])
Re: OTP is it really ugly to use or not? (Patrick Juola)
Re: encrypt using ASCII 33 to 126 only? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Slide Attack on Scott19u.zip
Date: Sun, 13 Jun 1999 14:23:42 GMT
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> 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)
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: OTP is it really ugly to use or not?
Date: Sun, 13 Jun 1999 14:26:08 GMT
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
> eg. RC4.
Wrong a RC4 encrypted message can be compromised. A OTP cannot be
compromised because there is no one right key. In pseudo-random
systems you could detect whether the key was right by the entropy of
the output (i.e it will most likely be alphanumerics, with the top bit
zero, etc...)
You cannot crack a OTP because all plaintexts are equal probable. You
can turn any ciphertext to *any* plaintext of equal length. You can't
do this with RC4.
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: Export restrictions question
Date: Mon, 14 Jun 1999 11:36:02 GMT
Thanks for the reply. Sorry for being so ignorant, but what is the "key
space" vs. key length?
Do you have any experience with applying for review? E.g., how long it
takes? Any "gotchas"?
Thanks.
Robert
_____________________________________
> In article <[EMAIL PROTECTED]>,
> fungus <[EMAIL PROTECTED]> wrote:
>
> All programs have to go through an export review process where
> the algorithms, etc. are documented.
>
> Nothing is garanteed to get through (you can play games with
> small keys to get good security), 56 bits is the maximum for
> a good cipher.
>
> In the case of a bad cipher like yours it's hard to say what
> would happen. It all depends on your definitions: The key is 64
> bits in size, but the keyspace isn't anywhere near 64 bits.
>
> It's a crap shoot.
>
> > [EMAIL PROTECTED] wrote:
> >
> > Can anyone provide some clarification for the encryption export
> > restrictions. Let's say my key length is 64 bits (8 bytes).
However
> > all I'm doing is performing an XOR on each 8-byte block in the file
from
> > beginning to end. It is obviously not any of the fancy algorithms.
> > Does that require export approval?
> >
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Kenneth N Macpherson" <[EMAIL PROTECTED]>
Subject: Re: encrypt using ASCII 33 to 126 only?
Date: Mon, 14 Jun 1999 13:33:41 +0100
>
>>I am trying to find code (vb) that will take a string (all chars in range
33
>>to 126 ASCII) and encrypt it again using chars in range 33 to 126.
>>
>>Reason for range is so users can type in the encrypted string from the
>>keyboard.
>
>About the best you can do is polyalphabetic substitution since it maps
>the code alphabet to the code alphabet.
>
Errr... I should maybe say now that I am NOT a cryptographer and have NO
idea what you mean.
Sorry. I can follow an algorithm but I am not up with crypto terminology -
well not much of it anyway. ;-)
Any help in simple language would be great!
Thanks,
Ken
------------------------------
From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: encrypt using ASCII 33 to 126 only?
Date: Mon, 14 Jun 1999 11:27:52 GMT
On Mon, 14 Jun 1999 11:47:36 +0100, "Kenneth N Macpherson"
<[EMAIL PROTECTED]> wrote:
>I am trying to find code (vb) that will take a string (all chars in range 33
>to 126 ASCII) and encrypt it again using chars in range 33 to 126.
>
>Reason for range is so users can type in the encrypted string from the
>keyboard.
About the best you can do is polyalphabetic substitution since it maps
the code alphabet to the code alphabet.
==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate
------------------------------
From: [EMAIL PROTECTED] (Dave Seaman)
Crossposted-To: sci.math.num-analysis,comp.sys.cbm
Subject: Re: Random numbers on a sphere
Date: 14 Jun 1999 07:59:45 -0500
In article <[EMAIL PROTECTED]>,
Anders Holtsberg <[EMAIL PROTECTED]> wrote:
>Virgil wrote:
>> Rho = 1.
>> Theta is uniformly distributed on [0,2*pi).
>> Phi is distributed on [0,pi] with weight proportional to sin(phi).
>The following is simpler
>1) Generate x y z uniformly on [-1,1] independently.
>2) If x^2+y^2+z^2 > 1 then goto 1 ("This is called rejection sampling").
>3) Set [x y z] = [x y z] / sqrt(x^2+y^2+z^2)
Those are two of the four methods I described in my earlier posting.
The method Virgil described (which I called the "trig method") is
indeed faster than the rejection technique by a significant margin in
tests that I ran. See my long posting earlier in the thread for the
details.
--
Dave Seaman [EMAIL PROTECTED]
Pennsylvania Supreme Court Denies Fair Trial for Mumia Abu-Jamal
<http://mojo.calyx.net/~refuse/altindex.html>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Slide Attack on Scott19u.zip
Date: Sun, 13 Jun 1999 14:46:53 GMT
In article <7k0c8k$21im$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>
> 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.
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?
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: Krunoslav Leljak <[EMAIL PROTECTED]>
Subject: Prime number generators...
Date: 13 Jun 1999 15:39:27 GMT
Hi,
It seems that prime number generators of all numeric libraries
OCCASIONALY hang slower computers. Is that happening to
somebody else?
Kruno.
------------------------------
From: "Kenneth N Macpherson" <[EMAIL PROTECTED]>
Subject: Re: encrypt using ASCII 33 to 126 only?
Date: Mon, 14 Jun 1999 14:31:39 +0100
>Are you talking about mangling or actually encrypting? What I would do
>is convert the 33-126 range (it's actually 32-127 btw...) to 0-95 range
>and perform some sort of truncated stream cipher.
A damn good idea. I will try this.
I was avoiding 127 as it is not a good char for users to type in as part of
a code.
>
>Why not binhex/uuencode the encrypted 8 bit chars?
What?
>
>Try RC4 encoding then binhex the output.
Now there is a question - I have an RC4 dll which will encode using
"keyboard" chars only but I am not sure if I can use it commercially or
not - can someone set me straight?
Thanks for all of the prompt replies - I like this group! :-)
Ken
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP is it really ugly to use or not?
Date: Mon, 14 Jun 1999 12:34:16 +0200
Bill Unruh wrote:
>
>
> >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?
>
> Yes, but when you decode the message, you also get the key for free. You
> can then test that key tosee if it has the requisite non-random
> properties. If it does not, then you know you got the wrong message. Ie,
> you do not determine that the message is right by looking at the
> message, you do it by looking at the key.
Maybe I have misunderstood the discussions so far, but I guess that
one point that remains to be treated is the following:
Given a keystream K and n plausible messages M_1, M_2, .... M_n and
one real message M_r. If we XOR all of them together to form the
ciphertext C, what chance has the analyst to find M_r, even if K is
not ideally random as required by the definition of OTP?
M. K. Shen
------------------------------
From: chciago <"gabriel. nock"@siemens.de>
Subject: IDEA in "aplied cryptography" BRUCE SCHNEIER
Date: Mon, 14 Jun 1999 14:31:52 +0200
hey, i wanted to implement the IDEA-algorythm by the sources in bruce
schneiers book....
is there a fault in this codes, or am i only too silly, to copy code
from a book, but : "it doesn't work"
or where can I find sources of IDEA which are working, I only want to
use it for myself, not in a commercial way..
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Slide Attack on Scott19u.zip
Date: Mon, 14 Jun 1999 12:16:03 GMT
<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.
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
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: OTP is it really ugly to use or not?
Date: Mon, 14 Jun 1999 12:18:47 GMT
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
> Sure I will. I'll just go roud to your house and start
> snipping little pieces off you and put aftershave in the
> holes. The message will soon be compromised...
I will just forget the key, the message and the point.
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PKCS#10 request
Date: 14 Jun 1999 12:37:50 GMT
Tomislav Posavec <[EMAIL PROTECTED]> wrote:
> Looking for freeware source code to generate PKCS#10 cert requests.
> Does anyone know if something like that is out there? Thanks.
> -Tom
Try the openssl package, http://www.openssl.org
it does pkcs#10 and a lot more! :)
regards
robert
--
Robert Guerra <[EMAIL PROTECTED]>
WWW Page <http://www.interlog.com/~rguerra/www>
PGP Keys <http://www.geocities.com/CapitolHill/3378/pgpkeys.html>
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: OTP is it really ugly to use or not?
Date: 14 Jun 1999 09:42:41 -0400
In article <[EMAIL PROTECTED]>,
Cyba Nonymous <[EMAIL PROTECTED]> wrote:
>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.
Well, your belief isn't required for the attack to work.
But I think that I can demonstrate it fairly easily, if you'll permit
me to assume a *REALLY* stupid keypad generator.
Specifically, 90% of the bits are zeros, and 10% of the bits are ones.
And I'll also make the starting assumption that your message is in
ASCII (so the high bit of the characters in your message are always zero).
The first thing I notice, when I receive your cyphertext, is that only
10% of the high bits are set and 90% are clear. ``That's funny,'' I
think to myself. ``If it were a good keypad, they should be split 50/50.
I wonder if I'm dealing with a biased generator.'' And I immediately
clear all the high bits because your message is ASCII.
So then I look at all the letters with an eye to the possible transpositions.
Specifically, if the cyphertext character is 'A' and the 90/10 bias, I
can calculate the probability that the plaintext letter really was an
'A', or the probability that it was a 'B' (10% chance of that bit being
flipped), 'C', 'D', &c. And it turns out to be much more likely to be
an 'A' than an 'F'. Using these stream probabilities and my knowledge of
English, it's not too hard to reconstruct the message.
>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)?
You could -- but you'd then have to transmit the other key to the
recipient, over a space in which you could just have easily have
transmitted the message.
>I guess I can see how a repeating key would be a problem. But , are all
>random keys non-repeating?
Yes.
Are all repeating keys non-random?
Yes.
>If I have a pnr that repeats after a million numbers but I only use
>the first 100 thousand is that not ok?
Probably not; 100 thousand numbers is large enough to be a representative
sample of the stream.
>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?
No. If I can guess what codeword you're using and reconstruct the CD,
then I can guess a different codeword and read your messages.
>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 ?
What sort of codewords are you using? What sort of scrambling are you
doing? This could be potentially very very hard -- or potentially near
trivial.
-kitten
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: encrypt using ASCII 33 to 126 only?
Date: Mon, 14 Jun 1999 13:10:50 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (James Pate Williams, Jr.) wrote:
> About the best you can do is polyalphabetic substitution since it maps
> the code alphabet to the code alphabet.
That's not very secure. I would suggest to be more creative then that.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
