Cryptography-Digest Digest #707, Volume #9 Sat, 12 Jun 99 18:13:04 EDT
Contents:
Re: Caotic function ([EMAIL PROTECTED])
Re: OTP is it really ugly to use or not? ([EMAIL PROTECTED])
Re: Slide Attack on Scott19u.zip ([EMAIL PROTECTED])
Yet another simplecipher (YASC) ([EMAIL PROTECTED])
Another free email? ([EMAIL PROTECTED])
Re: RSA example with small numbers ([EMAIL PROTECTED])
Re: RSA example with small numbers (James Pate Williams, Jr.)
Re: OTP is it really ugly to use or not? (Jerry Coffin)
Re: differential cryptanalysis ([EMAIL PROTECTED])
Re: Random numbers on a sphere (Virgil)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Caotic function
Date: Sat, 12 Jun 1999 20:29:05 GMT
Uhm...
most Chaotic functions use i ( i-Sqrt(-1) ), in imaginary no. ( or
rather i+n, a complex no), so are v.difficult to implement easily.
Take a starting point C_0 in the plane of coordinates u_0 and v_0.
Fron the coordinate of C_0 form a second point C_1, of coordinates
u_1=(u_0)^2 -(v_0)^2 + u_0 and v_1=2((u_0)(v_0))+v_0
etc
i.e.:
u_k=(u_k-1)^2 - (v_k-1)^2 +u_0
v_k=2((u_k-1)(v_k-1))+v_0
where x_n = x subscript n (ie the nth x), and x^n = x to the power n.
a point C of coordinates u and v - u+iv (where iv is the imaginary
number iv)
of course there are many other ways, but that should do for a paper at
college... if you need to _understand_, buy a good book, talk to
people cleverer than me,,,,,, etc etc...
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: OTP is it really ugly to use or not?
Date: Sat, 12 Jun 1999 19:35:04 GMT
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.
You should. If you can predict a OTP what's the point?
> 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.
If the key is truly random it doesn't matter of the plaintext.
> 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?
The pad must be random. If it can predicted then others can read 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)? 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.
With the OTP you could send all zeros as the ciphertext and have the
key as the message (which would be ironic). The security comes from
the fact that no plaintext is 'righter' then any other. In block
ciphers you can detect keys which work more often then others
(i.e 'righter'). In a OTP the key is used once.
> The other thing that pops into my mind is random versus repeating.
If it repeats it is not a OTP. for example 'abcabcabcabcabc' is
predictable thus not random. Random doesn't always equal random as
random numbers do not exist. If you cannot predict it with any means
faster then guessing it (brute force) then it's considered random.
> 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 ?
Well using video CDs is a bad idea. I could accidently buy one of them
and accidently crack your messages.
IF you made the video yourself hmm, ok... But usually there are headers
etc.. So I would avoid that.
> I am real curious to hear the feedback. Look, and I already know
> I am a dummy so please temper your scorn. Thanks.
Nope no problem.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Slide Attack on Scott19u.zip
Date: Sat, 12 Jun 1999 19:39:56 GMT
> 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!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Yet another simplecipher (YASC)
Date: Sat, 12 Jun 1999 19:46:40 GMT
Here is another simple cipher. It requires far less ram and is easier
to setup. It lacks a key schedule. It's a CAST variant with a 128-bit
block. It is really efficient in software, and is easy to program. It
uses round keys as to avoid slide attacks (hopefully). I used the
sboxes from cast (in the hope they are magically secure against diff
and linear attacks).
The code is at http://people.goplay.com/tomstdenis/simple2.c
Like http://people.goplay.com/tomstdenis/simple.c this is a toy
function. They appear to be sound, but I would not be surprised if
there is an attack against it.
I plan to write up the first one before continuing on the second. I
wrote the second just as a brain storm.
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: Another free email?
Date: Sat, 12 Jun 1999 19:43:06 GMT
I got a private email asking to have this posted...
---
Speaking of hushmail, has anyone heard of www.ynnmail.com? It's
supposed to be free encrypted web mail, but I was wondering how secure
it really is. I would appreciate any input on that from this forum.
---
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: RSA example with small numbers
Date: Sat, 12 Jun 1999 19:58:20 GMT
> I chose the number 10 as my plaintext and encrypted it:
> C=M^e mod n=10^5 mod 851=433
>
> Then I took the cyphertext 433 and decrypted it:
> M=C^d mod n=433^{317} mod 851=499
You did something wrong because
433**317 (mod 851) = 10 in the win98 calc.
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] (James Pate Williams, Jr.)
Subject: Re: RSA example with small numbers
Date: Sat, 12 Jun 1999 19:41:46 GMT
On 12 Jun 1999 18:46:10 GMT, [EMAIL PROTECTED] (Gergo Barany)
wrote:
>I chose the number 10 as my plaintext and encrypted it:
>C=M^e mod n=10^5 mod 851=433
>
>Then I took the cyphertext 433 and decrypted it:
>M=C^d mod n=433^{317} mod 851=499
Calculational error 433 ^ 317 mod 851 = 10.
Using freelip (see my homepage for a link):
zintoz(433, &za);
zintoz(317, &zb);
zintoz(851, &zc);
zexpmod(za, zb, zc, &zd);
printf("433 ^ 317 mod 851 = ");
zwriteln(zd);
==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: OTP is it really ugly to use or not?
Date: Sat, 12 Jun 1999 14:43:19 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> 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 and no. Yes, if you treat it as if it were random and attempt a
brute-force attack, you won't get very far. However, if you use (for
example) a pseudo-random number generator to produce your "pad", then
the real key isn't the bytes that come out of the generator: it's the
seed you used to start the generator, and possibly some of the other
generator parameters. The attacker doesn't attempt a brute-force
attack on the final output, but on the generator itself.
> 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.
It depends on how you're generating your pad. If you use something
like a linear-congruential random number generator, and send enough
data with it that you run through the full cycle of the generator, and
start to repeat it, then the attacker can start to find patterns.
Based on those, he can determine the length of the cycle. Having
found the length of the cycle, he can start to do statistical analysis
of the blocks, and determine the contents of individual blocks.
> 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.
To do this, you need to start by finding a way to generate this second
key that generates the message you're trying to keep secret. If
you're going to use an OTP-style system where you generate a key the
same size as the message, this is pretty simple to do, but completely
impractical to use: you start by encrypting the fake message, then you
create the real key based on the encrypted fake message. You transmit
the real key (which will be the same size as the real message) by a
secure channel. You can't send it ahead of time, because you don't
know what it'll be until you've created the message that needs to be
sent.
Since you now have a key that's as large as the message, and has to be
transmitted securely, you have a situation where your encryption
doesn't accomplish anything -- it would be just as easy to transmit
the message (without encryption) as the key.
Your other possibility is to try to produce a different random number
generator that produces the right output to decrypt your bytes to the
output you prefer.
I don't want to go on record as saying there's no possibility of ever
doing that, but I think it's safe to say that it is a FAR more
difficult problem than most current forms of encryption would
contemplate. Worse yet, it hasn't really improved your security much.
Based on the patterns, your attacker now has about equal likelihood of
decrypting your real message or your fake message. If they look for
all possible messages, they'll find both. They might find one or two
others that look semi-plausible as well. If they can narrow things
down to a half-dozen possible messages, they really know quite a bit
about what you transmitted.
> 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 there's repetition, that's a pattern that prevents the key from
being entirely random.
> If I have a pnr that repeats after a million numbers but I only use
> the first 100 thousand is that not ok?
Yes and no. If (for example) you use a linear-congruential generator,
you've got a couple of problems. First for all, even if you use only
a fraction of the generator's output, the attacker can know quite a
bit about what the generator can produce anyway. For example, if you
use the full-range of a full-cycle generator, then the attacker knows
that it can NEVER produce the same number for two successive outputs.
> 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?
Ultimately, no. If you use codewords to pick parts of the CD-ROM,
what you're basically doing is creating a pseudo-random number
generator that has roughly 650 MB of internal state. If you use it
long enough, it's going to repeat. That's enough internal state that
if you use things carefully at all, you can get a high level of
security for a long time. It's NOT, however, provably secure for an
infinite time like a true OTP is.
> 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 ?
It depends on the exact contents of the video CDs, and the exact
method you use of generating temporary pads from their contents. If
you're sufficiently careful, it would be very hard. OTOH, there are
LOTS of ways of producing ciphers that are extremely difficult to
break, and most of them are much more practical than this.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: differential cryptanalysis
Date: Sat, 12 Jun 1999 20:34:06 GMT
On 12 Jun 1999 01:06:53 GMT, Fauzan Mirza
<[EMAIL PROTECTED]> wrote:
Wow. I printed off your paper and am still working on it....
Thanks a lot.
ps. I know this is not the subject of sci.crypt, but where can I get a
prog to view .ps files under ugh.. win '95 (i know.. call me a fool
later ok.)?
------------------------------
From: [EMAIL PROTECTED] (Virgil)
Crossposted-To: sci.math.num-analysis,comp.sys.cbm
Subject: Re: Random numbers on a sphere
Date: Sat, 12 Jun 1999 15:33:25 -0600
In article <7jsv6f$lb8$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Matthew Montchalin) wrote:
>Dave Seaman wrote:
>|>| The idea was to produce points that are uniformly distributed with
>|>| respect to the area of a sphere.
Use spherical polar coordinates to determine the point <rho,theta,phi> on
the sphere rho = 1.
Rho = 1.
Theta is uniformly distributed on [0,2*pi).
Phi is distributed on [0,pi] with weight proportional to sin(phi).
--
Virgil
[EMAIL PROTECTED]
------------------------------
** 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
******************************
