Cryptography-Digest Digest #574, Volume #14 Sat, 9 Jun 01 12:13:01 EDT
Contents:
Re: National Security Nightmare? (Tim Tyler)
Re: National Security Nightmare? (Tim Tyler)
Re: Uniciyt distance and compression for AES ([EMAIL PROTECTED])
Re: Uniciyt distance and compression for AES ([EMAIL PROTECTED])
Re: Uniciyt distance and compression for AES ([EMAIL PROTECTED])
Re: cubing modulo 2^w - 1 as a design primitive? ("Peter L. Montgomery")
Re: cubing modulo 2^w - 1 as a design primitive? ("Tom St Denis")
Re: Uniciyt distance and compression for AES (SCOTT19U.ZIP_GUY)
Re: Uniciyt distance and compression for AES (SCOTT19U.ZIP_GUY)
Re: Uniciyt distance and compression for AES (SCOTT19U.ZIP_GUY)
Re: Brute-forcing RC4 (Charles Lyttle)
Re: OTP WAS BROKEN!!! (Charles Lyttle)
Re: Uniciyt distance and compression for AES ([EMAIL PROTECTED])
Re: Uniciyt distance and compression for AES ([EMAIL PROTECTED])
Re: Uniciyt distance and compression for AES ("Tom St Denis")
Re: cubing modulo 2^w - 1 as a design primitive? (Mika R S Kojo)
Re: cubing modulo 2^w - 1 as a design primitive? ("Tom St Denis")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 9 Jun 2001 13:05:09 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
: In particular, I couldn't find any prohibition against the "GCHQ
: backdoor", i.e., a gentleman's agreement between the NSA and GCHQ to
: spy on each other's citizens and swap intercepts. If it is the
: policy of the NSA that such conduct is forbidden, how can I tell?
I believe GCHQ does not need to go to any such lengths if it wants to
spy on UK citizens.
The NSA gets other things (besides info on US citizens) from the UK -
things like the MenWith Hill Station - from which they can conveniently
spy on the rest of Europe.
No doubt the UK gets something out of it all. It seems likely that the
NSA has various desirable bargaining chips to play with.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 9 Jun 2001 13:16:02 GMT
JPeschel <[EMAIL PROTECTED]> wrote:
: John Myre [EMAIL PROTECTED] writes:
:>JPeschel wrote:
:>> No, Phil, the English of Americans and the British is one language.
:>Barely.
: Barely? How so?
There are at least a few irritating differences. These irk me whenever I
use programming languages written by Americans - because they don't seem
to know how to spell things like "colour" properly ;-)
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
Subject: Re: Uniciyt distance and compression for AES
From: [EMAIL PROTECTED]
Date: 09 Jun 2001 09:49:17 -0400
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
>
> Actaully your quite wrong there is not needed to reject meaningless
> messages by compression. What compression does is to make a large
> set of files smaller.
Actually, it makes a *tiny* set of files smaller--so tiny as to be
practically nonexistent. It makes a similarly tiny set of files *much*
larger. The vast majority of files are barely changed in size--they may
stay the same, get slightly larger, or get slightly smaller.
> Yes if it redues redunacy in messages yes many meaningless ones will
> be resduced to. So what. But the very fact of reducing it in your
> target set increase the density of those messages.
>From practically zero to practically zero. It may ``increase'' the
density, but not enough to make a difference. (Unless extremely careful
effort is devoted to exactly that outcome.)
Len.
--
Frugal Tip #58:
Make people give you money at gunpoint. But do it in a nice way so they
won't feel bad about the experience overall.
------------------------------
Subject: Re: Uniciyt distance and compression for AES
From: [EMAIL PROTECTED]
Date: 09 Jun 2001 09:55:23 -0400
"Tom St Denis" <[EMAIL PROTECTED]> writes:
>
> Typically random ASCII messages will not compress much if any at all.
One would expect them to compress by about 12.5% at least, since every
eighth bit is known to be zero. Which isn't ``hardly any'', but is still
quite a bit less than English text.
> What I don't get is why do you think brute force is [impossible] or [very
> hard]? I can still guess the key, I can still try to decompress and I can
> still check for proper ASCII and english digrams.
Bingo! For messages of realistic (and still very small) size, the
likelihood of a false positive is essentially zero--unless some
specific property of the codec ensures otherwise. Which requires
proof.
> For example if I see "PQ" or "MZ" etc in the plaintext I can be sure I've
> most likely guessed the key wrong.
Note that random padding can help defeat such statistical analysis--but
all that does is increase the work. It changes the test from ``IS
English'' to ``contains SOME English''.
Len.
--
The moment you run that, a local attacker can take over your machine.
Isn't security fun?
-- Dan Bernstein
------------------------------
Subject: Re: Uniciyt distance and compression for AES
From: [EMAIL PROTECTED]
Date: 09 Jun 2001 09:56:33 -0400
Andreas Gunnarsson <[EMAIL PROTECTED]> writes:
>
> Compression increases unicity distance by making probable messages shorter
> and making improbable messages longer. This increases the number of
> probable messages for a given length of the compressed data.
True--but ``more probable'' might still mean ``practically impossible''.
One needs to prove otherwise before making some specific security claim.
Len.
--
Stocks heavily owned and constantly monitored by institutions have often
been among the most inappropriately valued.
-- Warren Buffett, 1985
------------------------------
From: "Peter L. Montgomery" <[EMAIL PROTECTED]>
Subject: Re: cubing modulo 2^w - 1 as a design primitive?
Date: Sat, 9 Jun 2001 13:57:13 GMT
In article <H5eU6.62238$[EMAIL PROTECTED]>
"Tom St Denis" <[EMAIL PROTECTED]> writes:
>I was wondering if anyone ever considered cubing modulo 2^w - 1 as a design
>primitive?
>It is a bijection since 3 does not divide the order for w=32 or w=64.
The prime 6700417 divides 2^32 + 1. This prime is 1 modulo 3,
so cubing is not a bijection modulo 2^64 - 1.
--
The 21st century is starting after 20 centuries complete,
but we say someone is age 21 after 21 years (plus fetus-hood) complete.
[EMAIL PROTECTED] Home: San Rafael, California
Microsoft Research and CWI
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: cubing modulo 2^w - 1 as a design primitive?
Date: Sat, 09 Jun 2001 14:04:29 GMT
"Peter L. Montgomery" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <H5eU6.62238$[EMAIL PROTECTED]>
> "Tom St Denis" <[EMAIL PROTECTED]> writes:
> >I was wondering if anyone ever considered cubing modulo 2^w - 1 as a
design
> >primitive?
>
> >It is a bijection since 3 does not divide the order for w=32 or w=64.
>
> The prime 6700417 divides 2^32 + 1. This prime is 1 modulo 3,
> so cubing is not a bijection modulo 2^64 - 1.
Hmm? What I am missing? The inverse exponent of 3 modulo 2^64 -1 is
6148914691236517205. Hence you get
(g^3)^6148914691236517205 mod (2^64 - 1) = g as an identity
I thought as long as 3 doesn't divide phi(p) it forms a bijection since
there is an inverse exponent which will form the identity g^(x/x) mod p = g.
Tom
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Uniciyt distance and compression for AES
Date: 9 Jun 2001 14:21:07 GMT
[EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>
>
>From practically zero to practically zero. It may ``increase'' the
>density, but not enough to make a difference. (Unless extremely careful
>effort is devoted to exactly that outcome.)
>
Well that is why Shannon came up with the formula for Unicity
distance. So that the effect could be meausred. Using his
formulas one can easiy see a factor of 2 compression for a target
set of files. More than doubles the amount of Plain text needed
to be recovered in order for a possible break to exist. It may
be beyond your ability to understand but those are the facts.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Uniciyt distance and compression for AES
Date: 9 Jun 2001 14:30:52 GMT
[EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>Andreas Gunnarsson <[EMAIL PROTECTED]> writes:
>>
>> Compression increases unicity distance by making probable messages
>> shorter and making improbable messages longer. This increases the
>> number of probable messages for a given length of the compressed data.
>
>True--but ``more probable'' might still mean ``practically impossible''.
>One needs to prove otherwise before making some specific security claim.
>
Actaully it has been proven. If your target set is compressed you
get more security. If your not smart enough to know that to bad.
If you think bijecitve compressors so bad. Write a message of at least
100 english words. And if I can't compress it so that is at least
20 % smaller than the DOS text file to write it I would belive you.
But your can't.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Uniciyt distance and compression for AES
Date: 9 Jun 2001 14:26:31 GMT
[EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>"Tom St Denis" <[EMAIL PROTECTED]> writes:
>>
>> Typically random ASCII messages will not compress much if any at all.
>
>One would expect them to compress by about 12.5% at least, since every
>eighth bit is known to be zero. Which isn't ``hardly any'', but is still
>quite a bit less than English text.
>
Yes your correct if the random file is 7 but ascii the eigth
bit would be determined. So what. If your interested in english
text I think you will find compressors like BICOM do a far better
job of saving space.
>> What I don't get is why do you think brute force is [impossible] or
>> [very hard]? I can still guess the key, I can still try to decompress
>> and I can still check for proper ASCII and english digrams.
>
>Bingo! For messages of realistic (and still very small) size, the
>likelihood of a false positive is essentially zero--unless some
>specific property of the codec ensures otherwise. Which requires
>proof.
Well if your not smart enough to read what Shannon did then
the heck with you. You haven't the foggest notion of what you talk.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: Charles Lyttle <[EMAIL PROTECTED]>
Subject: Re: Brute-forcing RC4
Date: Sat, 09 Jun 2001 14:40:59 GMT
Joseph Ashwood wrote:
>
> There was a mention a year and a half ago on this group of using a small
> beowolf cluster of overclocked celerons (at the time this would bring it to
> approximately the 500MHz mark), and being able to brute force RC4-40 in a
> few days for $1200, with proper optimization I think it could be lowered.
>
> Let's see
> Load takes L1 clocks
> Store takes S1 clocks
>
> In each iteration of the key schedule there are 3 loads, and 2 stores. the 2
> of the 3 loads can be done simultaneously, and parellelized highly, so the
> throughput there can be reduced to say 1.5 cache clocks per value. The
> stores are fully async on modern cpus, so those will take only 1 clock each.
>
> You've got about 6.5 clocks for each iteration of the RC4 key schedule.
> There are 256 iterations for the entire key schedule so that's 1664 clocks
> for initialization. RC4 can generate a byte in 4 clocks so we'll just assume
> that, the likelihood of having to go beyond 2 bytes is negligible and
> certainly doesn't compare to the key setup, so we'll pretend we only have to
> generate 2 bytes, that's 8 clocks. The value for comparison can be stored in
> a register so we don't have to load it, RC4 output will be to a register, so
> we simply compare them, that's an additional 1 clock. So we've got a total
> of 1664+8+1 clocks for each key. That's 1673 clocks, or 299,000/sec, 3.6
> million seconds per key (worst case), that's 42 days. Normally it would
> finish in 21 days, 3 systems could be parrelellized on this to finish in a
> week on average. This is assuming a very carefully optimized RC4
> implementation by someone who is exceptionally good at writing assembly,
> with a reasonable assembly coder, you're looking at twice as long, minimum,
> and a compiler using pure C would probably offer better results.
> Joe
>
> "S Degen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> > Howmuch time would it take to brute-force a 40 bit RC4 key? (Ofcourse
> > depending on the processor-speed, but lets say a PIII 500)
> >
> > This is the case:
> > You have a 128 bit (ASCII) text, and the encyphered version of it. This
> > version is encyphered with a 64 bit secret key, but of those 64 bits, 24
> > bits are known. (Leaving 40 unkown bits)
> >
> > I would like to know how long it would approximately take to calculate
> > the 40 bit secret key.
> >
> > (Worst case scenario)
> >
> >
> > Thank you if you can help me.
Given the information for the specific attack, I think today one could
build a small FPGA specific purpose machine that could easily do 2 bytes
in one clock (expensive, perhaps 10^3 FPGA) or 256 clocks (lots cheaper,
10-20 FPGA and easier to hide). The one-clock machine would solve the
problem in about 7 milliseconds and the 256 clock machine in about 2-3
seconds. Specific purpose machines are orders of magnitude faster at
their task than general purpose machines. I haven't done this, but I did
look a preliminary study of building the "Cracking DES" machine in FPGA.
--
Russ Lyttle
"World Domination through Penguin Power"
The Universal Automotive Testset Project at
<http://home.earthlink.net/~lyttlec>
------------------------------
From: Charles Lyttle <[EMAIL PROTECTED]>
Subject: Re: OTP WAS BROKEN!!!
Date: Sat, 09 Jun 2001 14:51:51 GMT
Al wrote:
>
> Interesting...
> Your replies seem to suggest that you think there is some merit in
> what newbie says...
> OTP is indistinguishable from completely randomly generated numbers,
> even seemingly random typing of the upper row of numbers. This could
> be any message shifted out mod 26, thats the point of this OTP thread.
> Do you guys get out much?
But your message wasn't completely randomly generated numbers, as Paul
demonstrated. The second biggest problem with OTP is that it is very
difficult to get a large quantity of true random numbers. Thanks to the
high redundancy in human languages and bad random number generators, it
is often possible to read _enough_ of an OTPed messages.
--
Russ Lyttle
"World Domination through Penguin Power"
The Universal Automotive Testset Project at
<http://home.earthlink.net/~lyttlec>
------------------------------
Subject: Re: Uniciyt distance and compression for AES
From: [EMAIL PROTECTED]
Date: 09 Jun 2001 11:01:00 -0400
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
> [EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>>
>> From practically zero to practically zero. It may ``increase'' the
>> density, but not enough to make a difference. (Unless extremely careful
>> effort is devoted to exactly that outcome.)
>
> Using [Shannon's] formulas one can easiy see...More than doubles the
> amount of Plain text needed to be recovered in order for a possible
> break to exist. It may be beyond your ability to understand but those
> are the facts.
I understand just fine--now you need about 64 bytes, instead of about
32 bytes. Whoop-de-doo. That has no effect on people who communicate
in messages of about 1-4 kilobytes, which is the size of almost all
email (for example).
So your 64-byte messages are now secret. As long as you discard the key
after each use, that is: ``perfect secrecy'' falls off exponentially as
messages increase in size.
Len.
--
Local-time support is a bad idea. Let's scrap all this tz junk. A user
who wants to know what time it is can go buy a sundial.
-- Dan Bernstein
------------------------------
Subject: Re: Uniciyt distance and compression for AES
From: [EMAIL PROTECTED]
Date: 09 Jun 2001 11:03:12 -0400
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
> [EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>>
>> Bingo! For messages of realistic (and still very small) size, the
>> likelihood of a false positive is essentially zero...
>
> Well if your not smart enough to read what Shannon did then the heck
> with you. You haven't the foggest notion of what you talk.
``Realistic but still very small'' means ~1000 bytes. I freely confess
that if you can keep it to 64 bytes or so, and use a new key for each
message, then you might even have perfect secrecy. (But in that case,
you should be using a OTP.)
Len.
--
I'm sorry if the facts don't fit your view of the universe, but UNIX
resource limits have been widely available for a decade.
-- Dan Bernstein
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Uniciyt distance and compression for AES
Date: Sat, 09 Jun 2001 15:30:21 GMT
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
> > [EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
> >>
> >> Bingo! For messages of realistic (and still very small) size, the
> >> likelihood of a false positive is essentially zero...
> >
> > Well if your not smart enough to read what Shannon did then the heck
> > with you. You haven't the foggest notion of what you talk.
>
> ``Realistic but still very small'' means ~1000 bytes. I freely confess
> that if you can keep it to 64 bytes or so, and use a new key for each
> message, then you might even have perfect secrecy. (But in that case,
> you should be using a OTP.)
I wouldn't bother arguing with him Len. He's the type that doesn't see the
bigger picture. Perhaps his methods are "more secure" (against what I have
no clue) but they are hardly practical for real use deployment. He's the
type that thinks only 80486's with 32MB of ram are used to encrypt FILES
only. He fails (or ignores) to respect the entire scene which includes
multimedia distribution (not the CSS type but real secure channels), the
whole e-commerce crap, debit machines, etc... Often crypto is done on a cpu
with only 256 bytes of ram and a 4Mhz clock!
Once again I must stress there is far more to "computer security" then some
stupid block cipher. We could have dropped all ciphers at 3DES and we would
be ok. From what we know 3DES is a perfectly secure block cipher (i.e no
attack faster than brute force in the theoretical model). Newer ciphers
should either be more convenient (i.e flexible key/block size) or more
efficient (i.e faster and/or smaller). Just proposing new ciphers because
they "more secure" is a waste since there are no breaks on 3DES.
Another flaw of David's warped little mind is that he fails to see the
distinction between a cryptosystem and a cipher. A cipher is a just a
transform. We analyze them in a "theoretical" model where we assume the key
is random and the implementation leads to no side channel analysis. A
cryptosystem is a program that makes use of a cipher. PGP for example is a
cryptosystem while RSA is a cipher. We break cryptosystems by looking at
flaws in the cipher AS WELL AS flaws in the system (i.e bad PRNG, side
channel info).
He often clumps things together and says "oh RC5 in CBC mode is for the weak
minded". But RC5 in CBC mode is a cipher not a cryptosystem! So from the
theoretical analysis RC5-32 with 20 rounds in CBC mode with a message size
under 2^32 blocks is in fact perfectly secure (as the key mind you).
However, RC5-32 with 20 rounds in CBC in a program which uses rand() to make
the key is not secure....this is a cryptosystem!
Also to drag the dead around (like he does to David Wagner) he once said he
found a short cut attack on RC5 that would reduce the keyspace to nothing.
I wonder what came of that? He hasn't won the RC5 64 challenge yet so I
guess he's a BS'ing liar (as he would put it).
Tom
------------------------------
From: Mika R S Kojo <[EMAIL PROTECTED]>
Subject: Re: cubing modulo 2^w - 1 as a design primitive?
Date: 09 Jun 2001 18:42:29 +0300
"Tom St Denis" <[EMAIL PROTECTED]> writes:
> "Peter L. Montgomery" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > In article <H5eU6.62238$[EMAIL PROTECTED]>
> > "Tom St Denis" <[EMAIL PROTECTED]> writes:
> > >I was wondering if anyone ever considered cubing modulo 2^w - 1 as a
> design
> > >primitive?
> >
> > >It is a bijection since 3 does not divide the order for w=32 or w=64.
> >
> > The prime 6700417 divides 2^32 + 1. This prime is 1 modulo 3,
> > so cubing is not a bijection modulo 2^64 - 1.
>
> Hmm? What I am missing? The inverse exponent of 3 modulo 2^64 -1 is
> 6148914691236517205. Hence you get
>
> (g^3)^6148914691236517205 mod (2^64 - 1) = g as an identity
>
> I thought as long as 3 doesn't divide phi(p) it forms a bijection since
> there is an inverse exponent which will form the identity g^(x/x) mod p = g.
You thought right, but your calculations are incorrect. Looking at
phi(2^64-1) = 9208981628670443520 = 2^45.3.5.17449,
suggests that 3 cannot be invertible. Peter Montgomery's comment is a
fancier way of saying the same thing.
Mika
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: cubing modulo 2^w - 1 as a design primitive?
Date: Sat, 09 Jun 2001 16:05:43 GMT
"Mika R S Kojo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> writes:
> > "Peter L. Montgomery" <[EMAIL PROTECTED]> wrote in
message
> > news:[EMAIL PROTECTED]...
> > > In article <H5eU6.62238$[EMAIL PROTECTED]>
> > > "Tom St Denis" <[EMAIL PROTECTED]> writes:
> > > >I was wondering if anyone ever considered cubing modulo 2^w - 1 as a
> > design
> > > >primitive?
> > >
> > > >It is a bijection since 3 does not divide the order for w=32 or w=64.
> > >
> > > The prime 6700417 divides 2^32 + 1. This prime is 1 modulo 3,
> > > so cubing is not a bijection modulo 2^64 - 1.
> >
> > Hmm? What I am missing? The inverse exponent of 3 modulo 2^64 -1 is
> > 6148914691236517205. Hence you get
> >
> > (g^3)^6148914691236517205 mod (2^64 - 1) = g as an identity
> >
> > I thought as long as 3 doesn't divide phi(p) it forms a bijection since
> > there is an inverse exponent which will form the identity g^(x/x) mod p
= g.
>
> You thought right, but your calculations are incorrect. Looking at
>
> phi(2^64-1) = 9208981628670443520 = 2^45.3.5.17449,
>
> suggests that 3 cannot be invertible. Peter Montgomery's comment is a
> fancier way of saying the same thing.
According to Maple, phi(2^64 - 1) == ifactor(2^64 - 2) =
``(2)*``(7)^2*``(73)*``(127)*``(337)*``(649657)*``(92737)
Where 3 is a not as factor.
A trial computation
45^3 mod 2^64 - 1 = 91125
91125^6148914691236517205 mod 2^64 - 1 != 3.
Hmm What am I missing? Why isn't a bijection? arrg...
I know with W=8 (i.e mod 255) cubing has 255 elements..... maybe I made a
bigmath error but afaik it's a bijection.
Tom
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
