Cryptography-Digest Digest #592, Volume #9 Tue, 25 May 99 14:13:02 EDT
Contents:
A question on congruential algebra ("Manuel Pancorbo")
Re: Symmantic question (John Savard)
Re: TwoDeck (Jim Felling)
Re: HushMail -- Free Secure Email (Sacha Brostoff)
Re: block ciphers vs stream ciphers ("Rochus Wessels")
Re: Why would a hacker reveal that he has broken a code? (SCOTT19U.ZIP_GUY)
q: Choosing polynomials in MPQS (Francois Grieu)
Re: block ciphers vs stream ciphers ([EMAIL PROTECTED])
Re: Security (wtshaw)
Give up; Scott is the unflappable undead. (TTK Ciar)
Re: block ciphers vs stream ciphers ([EMAIL PROTECTED])
Re: DSA (Digital Signature Standard) and the Schnorr Patents ("Roger Schlafly")
Re: block ciphers vs stream ciphers (SCOTT19U.ZIP_GUY)
Re: ScramDisk and Windows 2000 (Daniel Garlans)
Re: TwoDeck ([EMAIL PROTECTED])
Re: block ciphers vs stream ciphers ("Rochus Wessels")
Re: A question on congruential algebra ("Manuel Pancorbo")
Re: RSA Cryptography Question (Chris Monico)
----------------------------------------------------------------------------
From: "Manuel Pancorbo" <[EMAIL PROTECTED]>
Subject: A question on congruential algebra
Date: Tue, 25 May 1999 17:48:49 +0200
I would like to know how difficult (Polinomial, Non-Polinomial time
requiered) is to solve the following problems about congruences and their
most proper solving algorithm.
1) Given 'y' and the prime modulus 'n' find 'x' that fullfils
n^2 mod n = y
2) Given a prime modulus 'n' and given also the fact that the problem, for
this given 'n', has solution, find any 'a', 'b'
(a^2 + b^2) mod n = 0
Thanks in advance.
Manuel Pancorbo
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Symmantic question
Date: Tue, 25 May 1999 15:50:24 GMT
[EMAIL PROTECTED] (Matthew Skala) wrote, in part:
>In article <[EMAIL PROTECTED]>,
>John Savard <[EMAIL PROTECTED]> wrote:
>>Doubling the key length squares the time required for an exhaustive
>>keysearch attack.
>There's a dimension problem with that; I think you mean it squares the
>number of keys in the keyspace. Squaring the "time" would give you an
>answer measured in "seconds squared", which don't see very useful.
As the time is proportional to the number of keys, it is true that the
time is multiplied by a factor proportional to the time when the key
length is doubled.
Obviously, the result in seconds squared is divided by a constant
scaling factor dimensioned in seconds (the time required to try one
key) ... however, I warn all concerned that I do not subject all my
USENET posts to the scrutiny required to remove nitpicks of this
nature.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: TwoDeck
Date: Tue, 25 May 1999 11:15:58 -0500
Even with a good(known) shuffle twodeck is vulnerable. Assume that an
analyst knows the shuffle is done by rearranging the deck according to the
output of a keyed LSFR, and further they know that it is being used to send
English text(ASCII).
Notational note M(i)= byte i of message M
The Opponent intercepts a message. Call it M.
Examining M(i) if the high bit is set will tell us whether A(B(i)) is < or
less than 128, which allows us to separate the stream . ( In addition, since
most of the values being XORed fall in a very specific range other
information will also be leaked -- it should be possible to arive at a
estimate as to the values of some of the other bits in A(B(i)) ).
Depending on the strength of your Keyed RNG. Our ability to trace the
position of cards 0-127 vs 128-255 will give us valuable clues as to the
output of your RNG, and thus given we know its nature, a potential attack
versus it. This cypher is thus no more strong, and possibly less strong
than directly XORing the RNG used in shuffling with the plaintext
[EMAIL PROTECTED] wrote:
> > Another suggestion is faster switching -- the practice of exhausting a
> > whole deck before it is reshuffled is very bad -- it means that your
> > available randomness falls extremely low before being refreshed and
> will
> > give an opponent a chance to analyze the deep structure of the deck in
> > full -- more intermediate decks might not be a bad idea and possibly
> > changing the order in which the decks are used at intervals. Another
> > suggestion is multiple shuffles at the intervals -- not much code
> load
> > difference in shuffling both A and B at the same time(esp if the same
> > algo is used for both -- but obviously different shuffle points).
>
> Well that's not really a problem. The problem is the deck is never
> really shuffled well. If I steped through the entire deck and shuffled
> youwould still not be able to tell the deck from any N! combinations.
>
> I however have two alternatives which are more compact and easier to
> implement (albeit no faster). I will discuss them when it's ready.
>
> I appreciate the interest in TwoDeck and someday I might improve it.
> If anyone else wants to work on it, by all means go ahead. It started
> with nice theory... :)
>
> 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: Sacha Brostoff <[EMAIL PROTECTED]>
Subject: Re: HushMail -- Free Secure Email
Date: Tue, 25 May 1999 17:26:47 +0100
Reply-To: [EMAIL PROTECTED]
> >If so, is there any way to automate that process?
>
> I would think that's possible, but I see no evidence that it's been
> implemented in this case yet.
If HushMail's aplet started doing bad things while pretending to do good things, that
would make it a Trojan of
sorts. In which case, one's anti-virus software ought to pick it up during/just after
download - given suitable
updates of course!?
Sacha.
------------------------------
From: "Rochus Wessels" <[EMAIL PROTECTED]>
Subject: Re: block ciphers vs stream ciphers
Date: 25 May 1999 16:18:31 +0200
"cairus" <[EMAIL PROTECTED]> writes:
> It seems that today the cryptographic community
> is much more interested in block ciphers than in
> stream ciphers. Which is the reason for this trend?
Block ciphers can also be used to generate a
keystream for stream-encryption.
Stream ciphers are used to encrypt small amounts of data,
like key-presses in a telnet-session, block ciphers for
big amounts, so block ciphers need to be more efficient
and it doesn't hurt very much to construct a stream cipher
from a block cipher. So all research efforts regarding
the security are better spend on block ciphers.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Why would a hacker reveal that he has broken a code?
Date: Tue, 25 May 1999 15:26:22 GMT
In article <7idtkj$6j5$[EMAIL PROTECTED]>, "Philip Hawthorne" <[EMAIL PROTECTED]>
wrote:
>Sure. That explains why every patient whose has investigations for PUD
>(peptic ulcer disease) routinely has a Clo-test done? And if the Clo-test is
>positive for helicobacter species starts eradication treatment? Or maybe the
>several clinical studies showing that helicobacter is _a_ causal agent, not
>_the_ causal agent should be ignored? Maybe sticking to factual data rather
>than broad, inaccurate, sweeping statements about unconnected disciplines
>would be be useful.
>
>
>Philip Hawthorne
>
I have had friends that just short a time a ago as 1995 where being treated
for uclers and they could not belive that the doctors where not curing them.
One of them after checking the stuff on the internet went to another doctor
in a big city and got his uclers cured. I am not sure what happened to the
other friend and I think your a fool if you think EVERY patient the doctors
think have PUD get tested. You almost seem to think that all doctors care
about people and not lining there pocket books. While my friend good caring
doctors in the US went the way of the DODO bird. They stopped caring when
they stopped making house calls. Your the one making broad statements.
What happened to this doctor that invented the cure that cost the american
medical union millions of dollars each year. And yes Mr Hamilton I will not
reveal my friends names to you.
>> It took more than 15 years for his discovery to be accepted, but now
>>the medical reference books all mention the "Helicobacter Pylori" as
>>the prime suspect in peptic ulcer (for those who read these books).
>>On the other hand, practicing physicians keep this information hidden
>>from their patients, and repeatedly perscribe diet, acid reducers and
>>other Bl-St so that patients would return to them year after year.
>>
>> Moral: never go to a doctor without doing your homework first.
>> remember - all doctors are in business, they care first
>> about their checkbook, then about their business partners,
>> and then, (maybe...) about your well-being.
>>
The trouble is many people get stuck with the HMO doctors who
have to run people through in factory speed so even if the doctor gave
a damn about people and was semi confident. The bean counters
would jump on them if they took to long. It would be nice if the AMerican
doctors union allowed more doctors in this country but then that might
effect the profit line.
>> Best wishes BNK
>>> --
>>> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
>>> http://www.jim.com/jamesd/Kong/scott19u.zip
>>> http://members.xoom.com/ecil/index.htm
>>> NOTE EMAIL address is for SPAMERS
>
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: q: Choosing polynomials in MPQS
Date: Tue, 25 May 1999 18:44:32 +0200
Please skip this article if you don't know the Multiple Polynomial
Quadratic Sieve, a fast technique to factor hard composite integers of
200-400 bits.
I'm trying to figure out a reasonable choice of polynomials in MPQS. The
simple "Davis" variation is rephrased below in the context of the "Two
large primes" variation. I fail to see why it is inferior to the more
complex "Hypercube" variation. My hope is that someone knowledgeable can
comment.
Notations:
N integer to factor (maybe already multiplied by a small integer)
B1 factor base limit
B2 large prime limit
B3 smoothness limit, B1 < B2 < B1*B2 < B3 maybe B3 = B2^2
(for RSA129 in ref[5], N is about 2^428 B1=16,333,609 B2=2^30)
S N^0.5 rounded up, such that (S-1)^2 < N < S^2
F(x) the polynomial (S+x)^2 - N
pj prime quadratic residues mod N not over thresold B1
Pj powers of pj not over B1 (mostly, the pj)
Dj,Ej the two integers x in [0..Uj[ such that Pj divides F(x)
We sieve the polynomial F(x) by adding the log(Pj) in an array at
indexes I=Dj+Pj*k and I=Ej+Pj*k for |I| small. Examining the
magnitude of the array elements quickly locates the I such that |F(I)|
is the product of many pj and an integer Q with Q<B3. For those I,
we factor |F(I)| using trial division by the primes pj, then when the
unfactored portion Q is more than B2, run a primality test, and for
composite Q perform an heuristic factoring, giving a total of 4 cases :
a) Q=1 a "full" relation
b) B1 < Q < B2 a "partial" relation
c) Q = Q1*Q2 with B1 < Qj < B2 a "partial-partial" relation
d) Q is a prime with B1*B2 < Q < B3 a "byproduct" relation
(the "small primes" variation can speed up things)
In the byproduct case we observe that for any integer x F(Q*x+I) is a
multiple of Q. G(x) = F(Q*x+I)/Q is an integer of order 2*x*N^0.5
when |x|<<N^0.5/Q which makes the polynomial G(x) about as smooth
as F(x). Each full, partial, or partial-partial relation found when
sieving polynomial G(x) translates in a usable relation, by multiplying it
with the byproduct relation that gave G(x).
The amount of work to start sieving polynomial G(x) given a byproduct
(I,Q) is essentialy adjusting the Dj and Ej, which is dominated by
computing the inverse mod Q of each of the pj. This is not too expensive,
because Q is small. On RISC CPUs it appears reasonably easy to interleave
the calculation with unused CPU cycles while the sieving step of the
previous pj is making cache misses, assuming we are not playing other
tricks with the caches.
The byproduct relations are almost free, and relatively frequent. Even if
we run out of those found sieving F(x), we can reuse second-order
byproduct relations found when sieving the G(x), and so on to several
levels. The risk of accidental duplicated sieving is low (if this was
frequent, we could get lots of full relations).
So why not use this simple "Davis" method rather than the more complex
"Hypercube" technique ? Maybe it would help if I knew the usual size of
the sieving interval, usual choice of B3, and the relative cost of sieving
and changing polynomial in a typical Hypercube MPQS.
Advance apologies: I should have read ref[1] and ref[3] but did not, as I
failed to find them either online or in my local public library (the
"Bibliotheque Nationale de France"). And I could have programmed both
Davis and Hypercube MPQS, but was too lasy and would rather ask.
Francois Grieu [reposted with corrections, thanks Mark]
References:
[1] J.A. Davis and D.B. Holdridge: Factorisation using the Quadratic
Sieve. Sandia report Sand 83-1346, Sandia National Laboratories,
Albuquerque, New Mexico, 1983.
[2] Carl Pomerance: The Quadratic Sieve factoring algorithm. Advances in
Cryptology - Proceedings of EUROCRYPT 84 (1985) vol. 209 of Lecture Notes
in Computer Science, Springer-Verlag page 169-182.
[3] Robert Silverman: The Multiple Polynomial Quadratic Sieve.
Mathematics of Computation 48 (1987) page 329-339.
[4] Rene Peralta: Implementation of the Hypercube Variation of the
Multiple Polynomial Quadratic Sieve (TR-95-05-04)
<ftp://ftp.cs.uwm.edu/pub/tech_reports/HyperSieve.ps>
[5] Derek Atkins, Michael Graff, Arjen K. Lenstra, Paul C. Leyland: THE
MAGIC WORDS ARE SQUEAMISH OSSIFRAGE
<ftp://ftp.ox.ac.uk/pub/math/rsa129/rsa129.ps.gz>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: block ciphers vs stream ciphers
Date: Tue, 25 May 1999 16:51:06 GMT
> Block ciphers can also be used to generate a
> keystream for stream-encryption.
> Stream ciphers are used to encrypt small amounts of data,
> like key-presses in a telnet-session, block ciphers for
> big amounts, so block ciphers need to be more efficient
> and it doesn't hurt very much to construct a stream cipher
> from a block cipher. So all research efforts regarding
> the security are better spend on block ciphers.
>
That't not correct. For serial communication a byte-wide stream cipher
would be better.
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] (wtshaw)
Subject: Re: Security
Date: Tue, 25 May 1999 11:56:11 -0600
In article <[EMAIL PROTECTED]>, Bryan Olson
<[EMAIL PROTECTED]> wrote:
>
> With an ideal cipher, we expect a unique solution at about
> the point where the redundancy in the text is equal to the
> entropy of the key (here we mean the redudancy in bits, not
> the percentage). The random padding that extends each byte
> to a block makes the amount of redundancy in each block the
> same as the amount of redundancy in the original byte. The
> padding has zero redundancy and the byte hasn't lost any.
> With an ideal cipher, we expect a unique solution at about
> the point where the redundancy in the text is equal to the
> entropy of the key.
>
Being conditioned to having padding added at the end it unfortunate.
There is no reason that padding could not be at the beginning or any other
place, or in more than one place. The nature of the of the padding should
make it obvious regardless of its placement upon proper decryption. Not
knowing where the padding occurs means attacking a cipher with assumed
inserted nulls, which is not the same as one without them..
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
------------------------------
From: [EMAIL PROTECTED] (TTK Ciar)
Subject: Give up; Scott is the unflappable undead.
Date: Tue, 25 May 1999 17:24:03 GMT
In article <7iek9o$3j8$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>
>Why is scott19u any better then a block cipher? Are you saying stream
>ciphers are always better then block ciphers? Me thinks not.
>
>Hey scott do yourself a favor (not trying to be mean) and actually
>'break' or explain why breaking your algorithm would be difficult.
>Saying hey it looks good is not enough.
>
>BTW, what happens when the file doesn't compress? You never answered
>that. Try a formal explanation, cause well I would love to see it
>(honest).
When I stopped reading sci.crypt over a year ago, Scott was spewing
vague, uneducated nonsense all over the newsgroup and plugged his toy
cryptosystem at every opportunity, ignoring anyone's requests (mean or
not) for him to elaborate on his assumptions, support his half-formed
arguments, or just shut the hell up.
Now I'm back, and one of the first posts I see is a vague paranoid
bullshit rant from Scott about block ciphers vs stream ciphers, the
NSA, and his toy cryptosystem. He doesn't seem to have changed at
all, even after all that time.
I know that seeing him misinform newbies and peddle snake oil is
very frustrating, but the best solution is really just to put him in
your killfile and ignore him. Anything more would be wasted effort
to no effect, and I would rather see people working on cryptographic
theory and technology than beating their heads on the "Scott brick
wall".
-- TTK
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: block ciphers vs stream ciphers
Date: Tue, 25 May 1999 16:48:57 GMT
>
> I think the reason is that stream ciphers are harder to
> analyze and most block ciphers only encrypt small blocks
> at a time. This makes the NSA job of reading your mail
> much easer. There are very few block ciphers capable of
> treating a whole file as a single block. However for the non
> brain dead you can use scott16u.zip or if you have afast
> k6-2 or k6-3 scott19u is hard to beat.
Why is scott19u any better then a block cipher? Are you saying stream
ciphers are always better then block ciphers? Me thinks not.
Hey scott do yourself a favor (not trying to be mean) and actually
'break' or explain why breaking your algorithm would be difficult.
Saying hey it looks good is not enough.
BTW, what happens when the file doesn't compress? You never answered
that. Try a formal explanation, cause well I would love to see it
(honest).
I think your idea is good (compress+encrypt) because the entropy of the
message is higher, however you have to avoid encrypting literals at the
start... how do you do that? (we are talking major known plaintext).
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: "Roger Schlafly" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.security.pgp,comp.security.pgp.discuss
Subject: Re: DSA (Digital Signature Standard) and the Schnorr Patents
Date: Tue, 25 May 1999 10:38:18 -0700
rosi wrote in message <7id6fp$rjv$[EMAIL PROTECTED]>...
>Am I correct that Roger is the one 'entangled' with RSA in some kind
>of a law suit?
Yes, correct. That is how I know for sure that the Schnorr patent
does not cover DSA. Actually, a couple of lawsuits, now resolved.
RSADSI and its lawyers deliberately filed false testimony, violated
a court order, and various other nasty ploys. For more info, see
my web site:
http://bbs.cruzio.com/~schlafly/pkp.htm
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: block ciphers vs stream ciphers
Date: Tue, 25 May 1999 18:28:05 GMT
In article <7iek9o$3j8$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>>
>> I think the reason is that stream ciphers are harder to
>> analyze and most block ciphers only encrypt small blocks
>> at a time. This makes the NSA job of reading your mail
>> much easer. There are very few block ciphers capable of
>> treating a whole file as a single block. However for the non
>> brain dead you can use scott16u.zip or if you have afast
>> k6-2 or k6-3 scott19u is hard to beat.
>
>Why is scott19u any better then a block cipher? Are you saying stream
>ciphers are always better then block ciphers? Me thinks not.
>
Actually this has been explained many times. IF you go to my website
you may learn something. But the contest I am running with scott19u
is of the kind that can't be done with any of the current AES candidates
where the file size is not changed. I never said all stream ciphers
are better than block methods.
>Hey scott do yourself a favor (not trying to be mean) and actually
>'break' or explain why breaking your algorithm would be difficult.
>Saying hey it looks good is not enough.
>
I have but u well get mail from dolts like Hamelton that say otherwise
>BTW, what happens when the file doesn't compress? You never answered
>that. Try a formal explanation, cause well I would love to see it
>(honest).
>
Well if by compress you mean running the file through the compressor any file
can be compressed. If you mean that somefiles are such that when you run
through a compressor they my get longer. But they still get modifef by the
cmpressor some files just get longer.
What is to explain. No method on earth or heaven above can causes every file
to get smaller.
>I think your idea is good (compress+encrypt) because the entropy of the
>message is higher, however you have to avoid encrypting literals at the
>start... how do you do that? (we are talking major known plaintext).
>
>Tom
Well Tom if your using scott19u the encryption of the literals in the front
of the file. Are a function of everything that follows in the file so there is
no problem. If your stuck useing an AES candidate I do have a method
that compress by a pass in forward direction and then in reverse direction
I have code and examples of how this compress would work at my web page.
Thanks For asking Tom
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Daniel Garlans <[EMAIL PROTECTED]>
Subject: Re: ScramDisk and Windows 2000
Date: Tue, 25 May 1999 18:35:53 +0100
Jennifer wrote:
>
> Hi
>
> Are there any plans to produce a Windows 2000 version of ScramDisk?
>
What is scramdisk? :)
-ws/dtl
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: TwoDeck
Date: Tue, 25 May 1999 17:28:08 GMT
The problem still remains that
y = B(A(x))
What is A or B? If A were truly randomized you would never find it
(faster then searching N!). This is because you never find out the
order of A or B. The problem is actually shuffling the function to make
it random is hard.
i.e it's not the output that is protected, its the order. However this
algorithm is non-recursive which makes it have cycles determined by the
shuffling output (except when N! functions have been produced).
Tom
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: "Rochus Wessels" <[EMAIL PROTECTED]>
Subject: Re: block ciphers vs stream ciphers
Date: 25 May 1999 19:44:44 +0200
[EMAIL PROTECTED] writes:
> That't not correct. For serial communication a byte-wide stream cipher
> would be better.
I wrote "it doesn't hurt VERY MUCH" (to construct a stream cipher
from a block cipher). Yes, a specialised cipher is always faster,
but since it is often used for very little bandwidth (max. 10 keystrokes/s
per user) there is not much gained.
The construction (bc to sc) has the advantage, that
the intensive security-analysis from the bc can be used.
------------------------------
From: "Manuel Pancorbo" <[EMAIL PROTECTED]>
Subject: Re: A question on congruential algebra
Date: Tue, 25 May 1999 19:46:48 +0200
>I would like to know how difficult (Polinomial, Non-Polinomial time
>requiered) is to solve the following problems about congruences and their
>most proper solving algorithm.
>
>1) Given 'y' and the prime modulus 'n' find 'x' that fullfils
>
>n^2 mod n = y
Sorry, I mean
x^2 mod n = y
Manuel Pancorbo
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Chris Monico)
Subject: Re: RSA Cryptography Question
Date: Mon, 24 May 99 21:46:08 GMT
In article <[EMAIL PROTECTED]>,
Emmanuel BRESSON <[EMAIL PROTECTED]> wrote:
>> >oooouuups... Of course you meant:
>> > m^phi(n) == 1 mod n
>> Hmmm, methinks that's not quite right either:
>
>It is true in (Z_n)*, the set of invertible elements of Z_n, because
>phi(n) is the order of this multiplicative group.
>In your example, 5 is not in this set (Z_15)*.
>Assumming that condition of being an invertible element, we have
>obviously
> m^{phi(n)+1}=m mod n
>of course. (Even if n is not square-free)
> Emmanuel
I'm sorry. Apparently I didn't post the relevent text. It was
qualified with "for all m". My replacement text is valid for all m.
That was the point.
------------------------------
** 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
******************************
