Cryptography-Digest Digest #975, Volume #11 Thu, 8 Jun 00 12:13:00 EDT
Contents:
Re: Primitive element ("Jesper Stocholm")
Re: 3DES performance (Eric Young)
Re: questions on TEA (Dave Hazelwood)
Re: 3DES performance (=?ISO-8859-1?Q?H=E4m=E4l=E4inen?= Panu)
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (Geoff Lane)
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (jungle)
Re: Thoughts on an encryption protocol? (John Myre)
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (Mark Wooding)
Re: Question about recommended keysizes (768 bit RSA) (Paul Koning)
Re: Enigma Variations (Paul Koning)
Re: do you need unrestricted FREE S/MIME certificate ? than read message ...
(Lincoln Yeoh)
Re: Observer 4/6/2000: "Your privacy ends here" (Mok-Kong Shen)
Re: Observer 4/6/2000: "Your privacy ends here" (Mok-Kong Shen)
Re: DES question (Frank Gifford)
Re: Comfort csybrandy ! (Was: Attack on SC6a (sci.crypt cipher)) (Simon Johnson)
Re: Question about recommended keysizes (768 bit RSA) (John Myre)
Re: testing non linearity of arithmetic-logic combinations (Tim Tyler)
Re: Comfort csybrandy ! (Was: Attack on SC6a (sci.crypt cipher)) (tomstd)
Re: equation involving xor and mod 2^32 operations (Simon Johnson)
Re: Primitive element (tomstd)
Re: DES question (tomstd)
Re: DES question (Paul Koning)
----------------------------------------------------------------------------
From: "Jesper Stocholm" <[EMAIL PROTECTED]>
Subject: Re: Primitive element
Date: Thu, 8 Jun 2000 13:11:16 +0200
"Eric Hambuch" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Jesper Stocholm wrote:
> >
> > you might have a point here. The material I have with me (HAC +
> > Stinson) does not describe the selection of the generator of the
group -
> > at least as far as I can see. The generator alpha of the
multiplicative
> > group Z(p) has order (p-1), so the question is how to find this - as
you
> > correctly say. I was not aware of the test in Knuth - even though I
> > browsed thru it to find some help ... but I'll give it another shot
> > later.
>
> The "Handbook of Applied Crytography" contains an algorithm to find a
> prime p and a generator g: try algorithm 4.86.
>
in other words - it is more or less an exhaustic search with a randomly
chosen alpha.
thanks,
Jesper
------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: 3DES performance
Date: Thu, 08 Jun 2000 12:25:33 GMT
H�m�l�inen Panu wrote:
> Can someone tell me where I could find some
> performance measurements/comparisons of Triple-DES
> or DES (software) on different technologies? So far
> I have only found results on Pentium by
> Antoon Bosselaers.
Some old numbers I have for software, all for Triple DES
in CBC mode. What is interesting is the difference between
the two MIPS CPUs at the same clock speed.
(k/sec == 1000s of bytes per second)
1990k/sec Alpha EV5.6 (21164A) 400mhz (Jun-1997) (C code)
161k/sec 486 66mhz (Jul-1996) (C code)
741k/sec Pentium 100 (Sep-1997) (ASM code)
1570k/sec Pentium Pro 200 (May-1997) (ASM code)
1340k/sec MIPS R10000 195mhz (Dec-1996) (C code)
657k/sec MIPS R4400 200mhz (Dec-1996) (C code)
2890k/sec Pentium II 350mhz (Jun-2000) (ASM code)
710k/sec StrongARM 275mhz (Jun-2000) (C code)
eric (who has not been keeping numbers recently.....)
------------------------------
From: Dave Hazelwood <[EMAIL PROTECTED]>
Subject: Re: questions on TEA
Date: Thu, 08 Jun 2000 20:44:30 +0800
Yup the original TEA was found to have weaknesses and thus gave birth
to XTEA. I forget the details though but it was all here in this group
so try searching dejanews.
Dido Sevilla <[EMAIL PROTECTED]> wrote:
>
>This post has to do with the Tiny Encryption Algorithm (TEA) described
>by Wheeler and Needham (http://www.cl.cam.ac.uk/ftp/users/djw3/tea.ps
>and http://www.cl.cam.uk/ftp/users/djw3/xtea.ps). Has anyone tried to
>use this block cipher? From what I see, the algorithm is really quite
>simple and looks pretty easy to code, even in most forms of assembly
>language. It doesn't go through quite as many contortions as the more
>sophisticated algorithms do, but it runs a fairly simple core through a
>lot of rounds (32 to be exact). Does it have any weaknesses which the
>authors have not described in their papers yet?
------------------------------
From: =?ISO-8859-1?Q?H=E4m=E4l=E4inen?= Panu <[EMAIL PROTECTED]>
Subject: Re: 3DES performance
Date: 8 Jun 2000 13:09:00 GMT
: Some old numbers I have for software, all for Triple DES
: in CBC mode. What is interesting is the difference between
: the two MIPS CPUs at the same clock speed.
: (k/sec == 1000s of bytes per second)
: 1990k/sec Alpha EV5.6 (21164A) 400mhz (Jun-1997) (C code)
: 161k/sec 486 66mhz (Jul-1996) (C code)
: 741k/sec Pentium 100 (Sep-1997) (ASM code)
: 1570k/sec Pentium Pro 200 (May-1997) (ASM code)
: 1340k/sec MIPS R10000 195mhz (Dec-1996) (C code)
: 657k/sec MIPS R4400 200mhz (Dec-1996) (C code)
: 2890k/sec Pentium II 350mhz (Jun-2000) (ASM code)
: 710k/sec StrongARM 275mhz (Jun-2000) (C code)
Thanks. You wouldn't happen to have any reference on these,
i.e. where the results are from, would you?
Panu
------------------------------
From: [EMAIL PROTECTED] (Geoff Lane)
Crossposted-To: uk.media.newspapers,uk.legal,alt.security.pgp
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: Thu, 8 Jun 2000 14:15:09 +0100
In article <[EMAIL PROTECTED]>,
"Scotty" <[EMAIL PROTECTED]> writes:
> Nice try but it doesn't work. To quote from the bill:
>
> "key", in relation to any electronic data, means any code, password,
> algorithm, key or other data the use of which (with or without other
> keys)-
> (a) allows access to the electronic data, or
> (b) facilitates the putting of the data into an intelligible form;
If I'm using ssh, I know my key, but I don't and can never know the session
keys that the ssh protocol actually uses to encrypt the data. The
authorities would have to capture the entire data stream and obtain both my
private and public keys that related to the particular datastream before
being able to decode the information.
--
/\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\
He's dead, Jim ... Kick him of you don't believe me
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: uk.media.newspapers,uk.legal,alt.security.pgp
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: Thu, 08 Jun 2000 09:50:36 -0400
they will ...
Geoff Lane wrote:
>
> In article <[EMAIL PROTECTED]>,
> "Scotty" <[EMAIL PROTECTED]> writes:
> > Nice try but it doesn't work. To quote from the bill:
> >
> > "key", in relation to any electronic data, means any code, password,
> > algorithm, key or other data the use of which (with or without other
> > keys)-
> > (a) allows access to the electronic data, or
> > (b) facilitates the putting of the data into an intelligible form;
>
> If I'm using ssh, I know my key, but I don't and can never know the session
> keys that the ssh protocol actually uses to encrypt the data. The
> authorities would have to capture the entire data stream and obtain both my
> private and public keys that related to the particular datastream before
> being able to decode the information.
they will ...
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Thoughts on an encryption protocol?
Date: Thu, 08 Jun 2000 08:42:26 -0600
"David A. Wagner" wrote:
>
<snip>
> But, if not, here's a summary of the problem. Suppose the sender takes
> his message M, appends an unkeyed hash H(M), and encrypts the concatenation
> M||H(M) to obtain a ciphertext C. The attack goes like this. Pick a
> message M' you want to fool the receiver into thinking was sent. Compute
> M := M' || H(M') || X, where X can be anything you like. Convince the
> sender to send the message M; he'll compute M || H(M), encrypt it, and
> send the result C. Now suppose your encryption algorithm has the property
> that the prefix of the encryption is the same as the encryption of the
> prefix. Then we may truncate the transmitted ciphertext at the point
> right before the "X", and the result will be the encryption of M' || H(M').
> When the receiver decrypts, the hash will look ok, and the receiver will
> think the sender intended to send M', even though the sender never actually
> ok'ed this. This is a message authentication failure.
Not to disagree with the conclusion ("use a proper MAC"), but in
the above scenario, if we can convince the sender to send M, why
can't we convince him to send M' in the first place? Then it
doesn't matter *what* protocol is being used...
John M
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Crossposted-To: uk.media.newspapers,uk.legal,alt.security.pgp
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: 8 Jun 2000 15:01:11 GMT
jungle <[EMAIL PROTECTED]> wrote:
> Geoff Lane wrote:
>
> > If I'm using ssh, I know my key, but I don't and can never know the
> > session keys that the ssh protocol actually uses to encrypt the
> > data. The authorities would have to capture the entire data stream
> > and obtain both my private and public keys that related to the
> > particular datastream before being able to decode the information.
>
> they will ...
They'd better be quick, then. Look at the SSH protocol (I'll assume
version 1).
The client generates the session key and sends it to the server. The
client's long-term key is used for signing only, and is therefore can't
be demanded by Plod[1]. Knowing the client's key doesn't help decrypt the
data stream.
The server has a long-term key and a short-term key (regenerated every
hour, by default). The secret, generated by the client, is encrypted
under *both* of the server's keys. Thus, to recover the session, Plod
needs to demand both the server's long-term key and the private key
corresponding to the short-term key which was active at the time.
Catch: the SSH server destroys the short-term key when it expires, and
there's no way of getting it back.
The SSH protocol is already fairly RIP-resistant. SSH2 understands
authenticated ephemeral Diffie-Hellman, which is an even better way of
ensuring that past sessions can't be reconstructed.
[1] In theory. There is specific protection for signing keys in the
Bill, but the issue of keys protected by passphrases is fuzzy.
Whether the passphrase can be demanded is unknown. This might be
clarified in the Code of Conduct, but that doesn't exist.
-- [mdw]
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Subject: Re: Question about recommended keysizes (768 bit RSA)
Date: Thu, 08 Jun 2000 10:15:43 -0400
Jerry Coffin wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
> [ ... the Cyber 175 ]
>
> > It did run the worst designed timesharing system I've ever
> > used. (Then again, I never did get to use RAX...)
>
> Out of curiousity, which was that? Scope and NOS were both pretty
> awful, but if there was something even worse, it'd be interesting to
> know what it was...
NOS. Designed as a batch system and fit only for that.
(RAX was a "timesharing" system for IBM 360s...)
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Enigma Variations
Date: Thu, 08 Jun 2000 11:05:04 -0400
Jim wrote:
> ...
> Read Kahn, 'The Codebreakers' the non-abridged version if possible,
I would put it more strongly. The paperback version is
utterly worthless. I once made the mistake of buying it,
and actually threw it into the trash -- which is a very
rare event indeed for a bookworm like me.
paul
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Crossposted-To:
alt.privacy,alt.security.pgp,alt.security.scramdisk,alt.privacy.anon-server
Subject: Re: do you need unrestricted FREE S/MIME certificate ? than read message ...
Date: Thu, 08 Jun 2000 15:15:30 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 05 Jun 2000 11:34:18 -0400, jungle <[EMAIL PROTECTED]> wrote:
>do you need unrestricted FREE S/MIME certificate ? than read message ...
>--
>To protect privacy, use encryption ALL the time. Free S/MIME & PGP at:
>https://secure.openca.org/ http://web.mit.edu/network/pgp.html
>
>
Somehow the certificate is invalid on my Netscape 3 browser.
Anyway, I create my own certs using openssl.
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Wed, 07 Jun 2000 17:23:08 +0200
U Sewell-Detritus schrieb:
> In <[EMAIL PROTECTED]>, Paul Shirley
> <[EMAIL PROTECTED]> wrote:
> >
> >Or better yet: construct a program to create random messages wrapped to
> >look like ciphertext based on a key. You can safely tell the plods
> >there's no key... (or even give them it: it won't decode anything;) yet
> >prove to a court the 'message' is random by regenerating it.
>
> How could you regenerate the random message unless you had
> stored the seed which itself would become a key.
See my response to a post of Paul Shirley.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Tue, 06 Jun 2000 17:20:23 +0200
Paul Shirley schrieb:
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen <mok-
> [EMAIL PROTECTED]> writes
> >Much better: Include several lines of random hex digits that look like
> >the ciphertext of some top secrets. I posted this scheme sometime
> >back in sci.crypt.
>
> Or better yet: construct a program to create random messages wrapped to
> look like ciphertext based on a key. You can safely tell the plods
> there's no key... (or even give them it: it won't decode anything;) yet
> prove to a court the 'message' is random by regenerating it.
Yes. In fact your proposal coincides with the details of an
implementation I had in mind, which takes cares of all
eventualities, including a possible black-out of oneself. One uses
a pseudo-random generator to create a hex stream to xor with a
(constant or seldom changing -- for convenience) text from a book
and one puts the (session dependent, arbitrary) seed used for the
generator, also in hex, at the front or the back of that.. When the
law enforcement asks for the key, pull out the code of the generator
and laconically tell them that the fervently wished-for key is already
there in those mysterious looking lines.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: DES question
Date: 8 Jun 2000 11:23:31 -0400
In article <X%F%4.105071$[EMAIL PROTECTED]>,
Paul Pires <[EMAIL PROTECTED]> wrote:
>Has any work been done on a DES variation with a 64 bit key? It seems like
>you could change the key shifts per round and have them effect all 64 bits
>vrs the 56 presently treated and leave the compression permutation alone and
>everything else for that matter. All 64 key bits would still get used over
>the 16 rounds.
>
>It seems that the advantage would be the disadvantage. It would still be
>DES-ish. Would it be essentially DES with a key better than 56 bits?
>
>Am I missing something obvious?
You should check out Biham and Shamir's book, "Differential Cryptanalysis
of DES". It turns out that 56 bits is the upper limit for that particular
cipher. Having more bits in a key would allow for more key bits to fall
through during the differential cryptanalys. So having more bits still
keeps your security around 2^56...
-Giff
--
Too busy for a .sig
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Comfort csybrandy ! (Was: Attack on SC6a (sci.crypt cipher))
Date: Thu, 08 Jun 2000 15:30:13 GMT
In article <8hj6hd$573$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Well, I tried. I guess I should have analyzed it more, however I
> simply do not have the time to learn. Since my algorithm has been
> declared as crap in it's current version, does anyone have suggestions
> on how to fix it? Also, what aspects of it do people like?
>
> csybrandy
>
> In article <[EMAIL PROTECTED]>,
> Runu Knips <[EMAIL PROTECTED]> wrote:
> > tomstd wrote:
> > > [...]
> >
> > Oooops. Before I've even recognized there is a new cipher there is
> > already an attack !
> >
> > Comfort to the author of SC6a ! It really hurts to get one's cipher
> > broken so fast.
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
>From what a i can work out, from this attack, it is based on the fact
that
A.) Your algorithm is highly linear
B.) It doesn't comply with the Strict-Avalanche-Criteria; part of
problem (A) (SAC)
There is a simple quick fix to this:
1.) Generate a non-linear, SAC S-Box. (someone has a program to do this
is think)
2.) After each Xor operation, run the output through that s-box.
And: Put 'Key & Text' dependent Bit-wise shifts in. This step should
add a bit more confusion & diffusion:
A=key, B=Plain-text block, n = block size in bits.
b = (b Xor a) >>> ((a + b) mod n)
This should act as a futher non-linear step. (similar to RC5)
I hope this modifaction total destroys the proposed attack.
Am i correct?
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Question about recommended keysizes (768 bit RSA)
Date: Thu, 08 Jun 2000 09:33:32 -0600
"David A. Wagner" wrote:
>
> In article <8hiv9l$vcp$[EMAIL PROTECTED]>,
> Bob Silverman <[EMAIL PROTECTED]> wrote:
<snip>
> > We have real-world benchmarks!!! These are not "theoretical estimates".
>
> Yes, now. But wouldn't you say that people have been studying
> "theoretical estimates" for advanced algorithms longer (or more
> intensely, if one looks back in time a bit) than they have been
> studying "real-world benchmarks"?
<snip>
For some reason, I am reminded of Richard Feynman. Didn't he say
that the final test of any theory is experiment? Ok, I know, in
this case the experiment is the behavior of programs that *we* wrote,
and doesn't necessarily mean anything for what *new* programs will
do. Still - I think it would be an error to try to reduce the
problem by picking the estimating method that we "trust" more.
Haven't you ever read a newspaper story that quoted an "expert"
giving only part of the story?
John M
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: testing non linearity of arithmetic-logic combinations
Reply-To: [EMAIL PROTECTED]
Date: Thu, 8 Jun 2000 14:29:34 GMT
cranky cransky <[EMAIL PROTECTED]> wrote:
: Terry Ritter <[EMAIL PROTECTED]> wrote in message
:> Articles have been published on this, but no arithmetic-level function
:> is very nonlinear. [...]
: my idea was to test the relative non linearity (if those words can be
: used ) of various combinations of simple chip level operations ( << , >> ,
: xor, and, bit-complement, +, - ...etc )on 32 and 64 bit ints, in an effort
: to make systematic the process of choosing functions for the simulation of
: 32 bit or 64 bit substitution table. rather than just randonly combining a
: few.
Of those you mention only + and - have any non-linearity at all.
AND and OR are normally considered non-linear operations, but destroy
information and do not immediately offer invertability.
Feistel constructs allow their use - and there are other approaches to
preserving invertability while using non-linear operations.
: so my aim is to discover the most nonlinear combination of operands for
: mixing, that creates the greatest avalanche (perhaps avalanche is not a
: function of non linearity, i dont know).
In many block cyphers, linear XOR-style operations are often those used
to promote avalanche. If avalanche is diffusion, non-linearity is
confusion.
: 2: a = c - b; b = c ^ a; c = a + b;
: 3: a = b + c; b = a - c; c = a ^ b;
:
: rotate through the combinations , then replace the = with +=, -=, ^=, etc...
: then you could add more levels of complexity...
:
: a = (b + c) ^ ( (b << 17) - (c >> 5) );
: or a = (b + c) ^ ( (b << i ) - (c >> j) ); where i, and j are iterated.
This is all probably too linear to be useful for generating confusion,
unless *many* iterations are used.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
------------------------------
Subject: Re: Comfort csybrandy ! (Was: Attack on SC6a (sci.crypt cipher))
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 08 Jun 2000 08:54:58 -0700
In article <8hoe5d$2r5$[EMAIL PROTECTED]>, Simon Johnson
<[EMAIL PROTECTED]> wrote:
>In article <8hj6hd$573$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> Well, I tried. I guess I should have analyzed it more,
however I
>> simply do not have the time to learn. Since my algorithm has
been
>> declared as crap in it's current version, does anyone have
suggestions
>> on how to fix it? Also, what aspects of it do people like?
>>
>> csybrandy
>>
>> In article <[EMAIL PROTECTED]>,
>> Runu Knips <[EMAIL PROTECTED]> wrote:
>> > tomstd wrote:
>> > > [...]
>> >
>> > Oooops. Before I've even recognized there is a new cipher
there is
>> > already an attack !
>> >
>> > Comfort to the author of SC6a ! It really hurts to get
one's cipher
>> > broken so fast.
>> >
>>
>> Sent via Deja.com http://www.deja.com/
>> Before you buy.
>>
>
>From what a i can work out, from this attack, it is based on
the fact
>that
>
>A.) Your algorithm is highly linear
>B.) It doesn't comply with the Strict-Avalanche-Criteria; part
of
>problem (A) (SAC)
>
>There is a simple quick fix to this:
>
>1.) Generate a non-linear, SAC S-Box. (someone has a program to
do this
>is think)
>
You can't just throw sboxes at a cipher and make it secure...
>2.) After each Xor operation, run the output through that s-box.
Similarly...
>And: Put 'Key & Text' dependent Bit-wise shifts in. This step
should
>add a bit more confusion & diffusion:
>
>A=key, B=Plain-text block, n = block size in bits.
>
>b = (b Xor a) >>> ((a + b) mod n)
Note that key dependant rotations are hardly any more secure
then data dependant rotations. Also note that only the lower
bits of a and b will determine the rotation.
>This should act as a futher non-linear step. (similar to RC5)
>I hope this modifaction total destroys the proposed attack.
>Am i correct?
It depends on how exactly these are used.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: equation involving xor and mod 2^32 operations
Date: Thu, 08 Jun 2000 15:51:42 GMT
In article <8hnbrp$1av$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David A. Wagner) wrote:
> In article <[EMAIL PROTECTED]>,
> Anton Stiglic <[EMAIL PROTECTED]> wrote:
> [ Solve (a+x) xor (b+x) = c for x; a,b,c are known. ]
>
> Work bit-by-bit, starting with the least significant bit of x
> and working your way up. Once you know (all possibilities for)
> the low n bits of x, you can try extending each of them with a
> 0 bit and a 1 bit in the n+1-th position, and checking whether
> the equation holds mod 2^{n+1} to filter out the wrong ones.
> Cook until done.
>
I know Addition and Xor don't commute (exactly what that means i would
like to know.). Is this statement relavent to this problem?
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Primitive element
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 08 Jun 2000 08:58:32 -0700
In article <8hnv0u$j3f$[EMAIL PROTECTED]>, "Jesper Stocholm"
<[EMAIL PROTECTED]> wrote:
>
>"Eric Hambuch" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Jesper Stocholm wrote:
>> >
>> > you might have a point here. The material I have with me
(HAC +
>> > Stinson) does not describe the selection of the generator
of the
>group -
>> > at least as far as I can see. The generator alpha of the
>multiplicative
>> > group Z(p) has order (p-1), so the question is how to find
this - as
>you
>> > correctly say. I was not aware of the test in Knuth - even
though I
>> > browsed thru it to find some help ... but I'll give it
another shot
>> > later.
>>
>> The "Handbook of Applied Crytography" contains an algorithm
to find a
>> prime p and a generator g: try algorithm 4.86.
>>
>
>in other words - it is more or less an exhaustic search with a
randomly
>chosen alpha.
it's rather quite simple of an algorithm.
Given P a prime and p[] the set of prime factors of p-1 do the
following (np is the number of factors)
g = 1
do {
g = g + 1
for i = 1 to np do
if g^((p-1)/p[i]) mod p = 1, then g is not a generator
} while g is not a generator
If for all of p[1..np] the output is not '1' then you know it
must be primitive iff g^p-1 mod p = 1.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: DES question
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 08 Jun 2000 09:02:56 -0700
In article <8hodpj$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Frank Gifford) wrote:
>In article <X%F%4.105071$[EMAIL PROTECTED]>,
>Paul Pires <[EMAIL PROTECTED]> wrote:
>>Has any work been done on a DES variation with a 64 bit key?
It seems like
>>you could change the key shifts per round and have them effect
all 64 bits
>>vrs the 56 presently treated and leave the compression
permutation alone and
>>everything else for that matter. All 64 key bits would still
get used over
>>the 16 rounds.
>>
>>It seems that the advantage would be the disadvantage. It
would still be
>>DES-ish. Would it be essentially DES with a key better than 56
bits?
>>
>>Am I missing something obvious?
>
>You should check out Biham and Shamir's book, "Differential
Cryptanalysis
>of DES". It turns out that 56 bits is the upper limit for that
particular
>cipher. Having more bits in a key would allow for more key
bits to fall
>through during the differential cryptanalys. So having more
bits still
>keeps your security around 2^56...
This is a bunch of BS and you should know better.
For starters linear cryptanalysis can break DES faster then
differential cryptanalysis, so even if your line of thinking
*were* right (which it isn't) you are still wrong.
The problem with saying 'DES can only provide O(2^56)
resistance' is that you are assuming that differential
cryptanalysis can always be performed, when in reality it
normally can't. Which means the attack won't work.
So in reality if you choose independant round keys, you can have
upto 768-bit single-DES keys.
If you wan't to argue this point (which I suggest you don't) why
don't you consider the brute force search of the RC5 challenge
which has a 64 bit key. RC5 with 12 rounds can be broken with O
(2^53) effort yet *brute force* is what is being used. This is
because only a handfull of ciphertexts are available.
So your point is not valid, and please don't spread such lies.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: DES question
Date: Thu, 08 Jun 2000 11:10:02 -0400
Paul Pires wrote:
>
> Has any work been done on a DES variation with a 64 bit key? It seems like
> you could change the key shifts per round and have them effect all 64 bits
> vrs the 56 presently treated and leave the compression permutation alone and
> everything else for that matter. All 64 key bits would still get used over
> the 16 rounds.
>
> It seems that the advantage would be the disadvantage. It would still be
> DES-ish. Would it be essentially DES with a key better than 56 bits?
>
> Am I missing something obvious?
It's not exactly obvious, but doing what you describe may not
be a good thing at all. Read the work of Biham and Shamir
(differential cryptanalysis of DES-like ciphers). It appears
that DES is amazingly fragile -- just about any slight tweak
you might consider making to it will weaken it, often very
severely.
If you're not going to use DES as is -- which is wise -- then
just substitute another well-analyzed cipher with a decent
key size. 64 isn't enough to be worth it even considering
the other issues. 3DES will do nicely; for high speed software
crypto, Blowfish or IDEA (give or take some patent licensing
issues) are reasonable choices. Or CAST, I suppose. That one
tends not to get mentioned when the other two are, I'm not
sure why not. Less marketing?
paul
------------------------------
** 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
******************************
