Cryptography-Digest Digest #714, Volume #9 Sun, 13 Jun 99 20:13:04 EDT
Contents:
sbox design ([EMAIL PROTECTED])
Re: "Breaking" a cipher ([EMAIL PROTECTED])
Re: OTP is it really ugly to use or not? ([EMAIL PROTECTED])
Re: Prime number generators... ([EMAIL PROTECTED])
Still musing about DH key exchanges :-) (Peter Gunn)
stream ciphers ("Maciej Maciejonek")
Re: Slide Attack on Scott19u.zip ([EMAIL PROTECTED])
Re: Cracking DES ([EMAIL PROTECTED])
Re: stream ciphers (James Pate Williams, Jr.)
Substituion methods (c a l a n d e)
Re: Looking for a password encryption algorithm (Bill Unruh)
Re: OTP is it really ugly to use or not? (Bill Unruh)
Re: Random numbers on a sphere (Bill Unruh)
Re: OTP is it really ugly to use or not? (Bill Unruh)
Re: "Breaking" a cipher
Re: RSA msg length... (Bill Unruh)
Re: OTP is it really ugly to use or not? (fungus)
Re: Substituion methods (fungus)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: sbox design
Date: Sun, 13 Jun 1999 18:15:13 GMT
I have been peering at the sboxes from CAST-128 (I used them in my
second simple cipher). And I would like to know about the criterion
used to make them. This is what I know.
1. They used bent functions on the inputs
2. There are four 8x32 sboxes
3. When used like in CAST it forms a 32x32 sbox
4. They are resitant to differential and linear analysis.
My questions are.
1. What is a bent function?
2. How is it resistant to the attacks?
I have seen a site a long time ago where Charlse talks about them, but
I lost the link. I would appreciate any links,urls,etc...
Thanks,
Tom
--
PGP key is at:
'http://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: "Breaking" a cipher
Date: Sun, 13 Jun 1999 17:58:42 GMT
> Every key-based system is "breakable". The only interesting data on
that
> is the "cost/time" curve.
Not true. Every system is solvable. A break is finding the key (or
the required information to forge/decrypt messages) faster then trying
all keys.
There are two types of advancements though. In things like RSA or DH
where it's a number problem the speed increase is roughly tied to the
evolvement of the algorithms used to solve. Note RSA had the QS then
the NFS etc...
In ciphers like DES (block ciphers, or symmetric key ciphers) the break
requires something occuring with a higher then equal probability. This
can suggest round keys or the entire key. The speed of a break is
normally tied towards the speed of the machine, we note that different
types of attacks (algorithms) may be faster. Most attacks against DES
are brute force with several ciphertexts...
Hope that helps.
--
PGP key is at:
'http://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: OTP is it really ugly to use or not?
Date: Sun, 13 Jun 1999 18:03:01 GMT
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
> Read the original post again...I never said RC4 was uncrackable,
> I gave it as an example of a pseudo-OTP.
Here is the clip from your post
>> I think it's more accurate to say that the absolute validity of the
>> mathematical proof that the OTP is secure depends on the true
>> randomness of the pad. It's perfectly possible to use a less
>> than perfect random number generator for your one time pad and
>> still have message security that can and will never be compromised.
>
>eg. RC4.
The last sentence suggests that RC4 cannot be compromised, but it can.
Tom
--
PGP key is at:
'http://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: Prime number generators...
Date: Sun, 13 Jun 1999 18:00:38 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (James Pate Williams, Jr.) wrote:
> >It seems that prime number generators of all numeric libraries
> >OCCASIONALY hang slower computers. Is that happening to
> >somebody else?
>
> When I had a Pentium I 90 MHz machine with 16 MB of RAM F-Secure SSH
> used to hang-up when I tried to generate a RSA key greater than
> 512-bits. Now that I have a Pentium II 450 MHz with 128 MB of RAM this
> does not occur.
There are three possibilities...
1) It did not hang. It was just way slower.
2) It requires too much ram, and crashed
3) Newer software.
I don't think the algorithm would just hang, so it most likely is #1.
Tom
--
PGP key is at:
'http://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: Peter Gunn <[EMAIL PROTECTED]>
Subject: Still musing about DH key exchanges :-)
Date: Sun, 13 Jun 1999 20:47:00 +0100
I havent given up thinking about DH key exchanges yet, and in
particular the
idea of using a prime mudulous that is determined by a shared secret...
U is Username
p is password (small shared secret)
X,Y,C1,C2 are random numbers (say 1024 bits)
g is a fixed generator (say 4)
f(p,U) is a function returning a large (1024 bit?) prime number derived
from p and U.
1) A->B: U, (g^X)%f(p,U), C2
2) B->A: (g^Y)%f(p,U), C1
3) A->B: E[(g^XY)%f(p,U)](C1)
(B disconnects if this doesnt match C1)
4) B->A: E[(g^XY)%f(p,U)](C2)
(A disconnects if this doesnt match C2).
Now, assuming this all works, the question is how to get a good
value out of f(p,U)...
Thomas Wu suggested seeding a pseudo number generator, generating
a random number, and finding the next larger prime. This sounds
promising, if computationally expensive, and would seem to require
that the resulting prime wasnt too small (<768bits?).
I suppose it could also be a composite number as long as it is
the product of two largeish primes, plus one. As this wouldnt seem
any easier to solve than using a large prime as a modulous.
So, my first idea (which is similar to my old SNAKE idea :-)...
Precaulculate a table of n large prime numbers, and use
f(p,U)=primes[H(p,U)%n] as the modulous. (where H() is
a suitable hash function).
Would this work? I know it is inefficient in terms of space for
storing the prime numbers, but if I used a limited table of say,
65536 or so, this would still be useable in PC applications
if not smartcards or other more limited devices.
If the prime table contained primes which were not "safe",
what problems would this cause?
All comments welcome :-)
tata
PG.
------------------------------
From: "Maciej Maciejonek" <[EMAIL PROTECTED]>
Subject: stream ciphers
Date: Sun, 13 Jun 1999 22:31:14 +0200
I look for any information about new (96-99) stream ciphers, which are easy
to hardware adapting
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Slide Attack on Scott19u.zip
Date: Sat, 12 Jun 1999 14:57:21 GMT
<snip>
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
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cracking DES
Date: Sun, 13 Jun 1999 20:14:50 GMT
Terry Ritter wrote:
> [EMAIL PROTECTED] wrote:
>
> >Terry Ritter wrote:
> >[...]
> >> So for n ciphers, we have n times the attack effort, and 1/n reward
> >> for any success, which makes the reward/effort ratio 1/n**2. This
is
> >> not linear, and that should make the attack business somewhat more
> >> discouraging.
> >
> >No. First the simple error: "n times the effort" is the
> >effort to attack all n ciphers; 1/n reward is for breaking
> >one of them (more on that below). We expect the number of
> >ciphers broken to increase with the number of ciphers
> >attacked, and thus the ratio stated is not the reward/effort
> >ratio.
>
> A reward/effort ratio of 1/n**2 is the ideal which we can only
> approach, assuming that cryptanalysts can identify our weak ciphers so
> we will not use those.
The presented ratio is an error. The reward for one thing
divided by the effort for a different thing does not define
the reward/effort ratio of anything.
> >Two other points indicate the assumptions are false. First,
> >the reward is proportional to the intelligence value of the
> >recovered plaintext and not the volume of plaintext. Five
> >percent of the traffic carries much more than five percent
> >of the value, since real traffic is redundant.
>
> Where does this come from? Cite please. Under what assumptions?
Under the assumption of traffic from a real-world enterprise
and project. Check any project management text, for example
the classic in software engineering /The Mythical Man-Month/.
They re-published the documentation every day. Also see page
75-76 (in the 20th anniversary edition) on the life of technical
prose, and how often the same information is repeated.
> The next time you want to read a 200-page book, rip it apart and
> reconstruct the writing from any random 10 pages. So now "reading a
> book" takes only 5% of the time it did. That should be a boon for
> busy executives everywhere!
Have you any clue how cryptography is used?
One might well want to keep the text of a book encrypted
until it goes to press. In the course of publishing a book,
revisions go to agents and editors, proof copies back to
authors and printers. Break any of them and we get the
whole book, though maybe a version that's not quite final.
> >Second, an
> >intelligent attacker would first try to determine what ciphers
> >his methods have a good chance of breaking, and concentrate
> >on those. Developing differential cryptanalysis took years;
> >determining whether it applies to a new cipher takes hours or
> >sometimes minutes.
>
> But even if an analysis technique "applies," it still must be applied.
Which no longer takes n times the effort. Since we know the
cipher applies, we're down to less than one times the effort.
--Bryan
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: stream ciphers
Date: Sun, 13 Jun 1999 20:39:16 GMT
On Sun, 13 Jun 1999 22:31:14 +0200, "Maciej Maciejonek"
<[EMAIL PROTECTED]> wrote:
>I look for any information about new (96-99) stream ciphers, which are easy
>to hardware adapting
>From 1993 SEAL (Software-Optimized Encryption Algorithm), see
_Handbook of Applied Cryptography_ Section 6.4.1 pages 213-216.
If you are a citizen of the United States of America, currently
residing in the U.S., then you can obtain a C implementation of
Algorithm 6.68 (SEAL 2.0) from the _Handbook..._ by writing me at the
following address requesting SEAL 2.0.
==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate
------------------------------
From: c a l a n d e <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Substituion methods
Date: Sun, 13 Jun 1999 14:39:04 -0700
I'm curious about the relative strengths of different forms of
substitution. Recently someone posted an inquiry about a two way table
such as follows:
ABCD EFGH IJK LMNOPQRS TUV WXYZ
WXYZ HGFE TUV SRQPONML IJK ABCD
Lets suppose that I construct a number of unique two way tables, each
that spans 0-255. The construction of the tables would be key dependent.
The same key would be used to construct a list of integers (0-225).
Assume the list is as long as the plaintext. The encryption algorithm
would be to use each element of the list to point to the table to use
for substitution of plaintext.
Is this type of substitution any better than simply exclusive or-ing the
plaintext with the list of integers? By better I mean would it be more
secure?
TIA
--
• Raymond P. Calande
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Looking for a password encryption algorithm
Date: 13 Jun 1999 23:20:24 GMT
In <[EMAIL PROTECTED]> Ari =?iso-8859-1?Q?V=E4h=E4=2DErkkil=E4?=
<[EMAIL PROTECTED]> writes:
>Paul Koning wrote:
>>
>> Try any good crypto hash (MD5, SHA-1, etc.)
>Any good trying to add crypt like salt to shuffle results around? If I have
>understood correctly, given the same input the various hashes will produce
>the same result.
The Unix crypt saltswere added because the des key was so short ( 8
characters) that dictionary attacks were seen as possible. The salt was
a way (not a terribly good way since it altered the encryption function
in a way which might make it weaker) or expanding the "key" space to try
to stop precompiled dictionary attacks. With any of the modern hash
functions you can achieve the same thing by simply padding the text with
a random string (stored withthe password as in the Unix case).
.....
>> > The communications medium
>> > cannot be considered secure, although non-authorized clients (or client
>> > programs) are not a problem.
>>
>> It's not secure but unauthorized clients aren't a risk? So what
>> ARE the risks?
>For example this: an administrative application produces a view to the
>error log of the system. As part of the elaborate error information, the
>transferred message is stored and shown. And when dealing with plaintext
>passwords... you guess the rest.
The unix approach will NOT help in this case. The password is
transmitted in the clear. Transmitting the hash is no better since the
attacker can simply send that hashed value directly without knowing the
original. You need an exchange mechanism. The server needs some short
term memory. EG, the user requests authentication. The server sends a
random string and writes that same random string to a temp file. The
user than requests password. The system looks for the temp file and
grabs the string, hashes it against the stored password (or hashed
password) and compares with the received string, and erases the temp
file. (still not ideal as effectively the password is still stored on
the server in the clear)
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: OTP is it really ugly to use or not?
Date: 13 Jun 1999 23:42:18 GMT
In <7jucp8$fv2$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>The pad must be random. If it can predicted then others can read the
>message.
Wel, no. If it is not random then others MAY be able to read the
plaintext. However it could be very hard to do. All of the stream
cyphers (eg RC4) are just ways of creating pseudo random streams to use
as a one time pad. They can still be very hard to break. But in theory
you know that there is a way to break them in a finite amount of time (
assuming that the message is longer than the key length)
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: sci.math.num-analysis
Subject: Re: Random numbers on a sphere
Date: 13 Jun 1999 23:30:40 GMT
In <7jpshf$nug$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Matthew Montchalin)
writes:
>Ed McBride wrote:
>>>What am I missing? I would use spherical coordinates, select theta
>>>randomly between 0,2pi then phi randomly between 0,pi set radius =1
>>>and I'm done.
>Pierre Asselin wrote:
>>Too many points near the poles. Try it and see.
Agreed, which is why you choose cos(phi) as uniformly distributed from
-1 to 1.
Ie, choose a random number r between 0 and 1 and set phi= arccos( 2*r-1)
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: OTP is it really ugly to use or not?
Date: 13 Jun 1999 23:37:29 GMT
In <[EMAIL PROTECTED]> Cyba Nonymous
<[EMAIL PROTECTED]> writes:
>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?
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.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: "Breaking" a cipher
Date: 13 Jun 99 23:14:26 GMT
Bernie Cosell ([EMAIL PROTECTED]) wrote:
: In my odd semantic world, "breaking" a cryptosystem means finding a
: weakness in the underlying algorithm that actually _decreases_the_work_ to
: decrypt [not merely making doing the same work faster or cheaper, which is
: just like checking the NYSE to get todays' value for one of your stocks,
Well, as far as RSA is concerned, some of what is happening could be
called "breaking", because faster techniques of factoring are found.
But even something like a DES brute-force search is useful if, when nobody
has actually done it, there is a controversy about where the datapoint
actually is given current technology. This applied to the EFF DES-cracker
machine, because people had been claiming DES was, even with current
technology, much too expensive to break.
Also, a cipher is regarded as "broken" if it is not secure enough to be
used, *whatever* the reason.
John Savard
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RSA msg length...
Date: 13 Jun 1999 23:44:39 GMT
In <[EMAIL PROTECTED]> "Particle" <[EMAIL PROTECTED]> writes:
>how big can a msg (block) be?
>for example: if p and q are each 512 bits, and n (which is
>p*q) is 1024 bits... then I would guess the msg has to be
>no more than 1024 bits long (since were doing a mod n )...
>(or does it have to be no more than 512 bits long?)
Bigger than 1024/e bits (where e is the public exponent) and smaller
than 1024 bits.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: OTP is it really ugly to use or not?
Date: Mon, 14 Jun 1999 01:27:20 +0200
[EMAIL PROTECTED] wrote:
>
> The last sentence suggests that RC4 cannot be compromised, but it can.
>
Want me to send you a message encrypted with 128 bit RC4?
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Substituion methods
Date: Mon, 14 Jun 1999 01:33:29 +0200
c a l a n d e wrote:
>
> Is this type of substitution any better than simply exclusive or-ing the
> plaintext with the list of integers? By better I mean would it be more
> secure?
No, it's *exactly* the same.
The entire xtrength of the process lies with the integer
generation function.
Imagine you incorporate the table substitution into the
algorithm which generates the integers and you'll see this.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
** 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
******************************
