Cryptography-Digest Digest #725, Volume #11 Sun, 7 May 00 16:13:01 EDT
Contents:
How does PGP passphrase produce the session key ? ("Thierry FALISSARD")
Re: zeroknowledge.com and freedom.net - Snake oil? (Roger)
Factoring RSA ([EMAIL PROTECTED])
Re: Fresco transmits my name (was: Spammed after just visiting a site) (Mark Wooding)
Re: How does PGP passphrase produce the session key ? (Tom St Denis)
Newbie question about primes ("JoeC")
Re: Newbie question about primes (Earl K. Nimoy)
Re: Joystick as RNG (Sandy Harris)
Re: Tempest Attacks with EMF Radiation (Diet NSA)
Re: SBOX using boolean logic (Terry Ritter)
Re: Fresco transmits my name (was: Spammed after just visiting a site) (James
MacDonald)
Re: Fresco transmits my name (was: Spammed after just visiting a site) (James
MacDonald)
Re: Fresco transmits my name (was: Spammed after just visiting a site) (Terry Blunt)
Re: Newbie question about primes (Sandy Harris)
----------------------------------------------------------------------------
From: "Thierry FALISSARD" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.tech
Subject: How does PGP passphrase produce the session key ?
Date: Sun, 7 May 2000 19:48:23 +0200
I know the passphrase is hashed to produce the session key
(I am interested here only in conventional encryption).
If the passphrase is hashed by MD5, the size of the hash will be 128 bits.
If the encryption algorithm is 3DES, 168 bits of key are required.
How does PGP create the missing key bits ?
------------------------------
From: Roger <[EMAIL PROTECTED]>
Subject: Re: zeroknowledge.com and freedom.net - Snake oil?
Date: Sun, 07 May 2000 10:50:05 -0700
"David A. Wagner" wrote:
> In article <[EMAIL PROTECTED]>, Steve <[EMAIL PROTECTED]> wrote:
> > And BTW, since the Freedom Network does not use latency or remix
> > to muddy the digital trail, traffic analysis can determine who
> > any user is, provided that someone with sufficient interest and
> > funding cares.
>
> Care to elaborate? That was not my impression at all.
> After all, I thought the whole architecture was based on mixing,
> so I'm not sure where your comments are coming from, but I'd be
> happy to be educated on what they're doing wrong.
They can't do everything. If you are the only one using a
particular server and someone monitors that server, then
presumably traffic analysis will yield some info. Maybe
not very much, but I think it is enough to keep Freedom Net
from making absolute claims of anonymity.
------------------------------
From: [EMAIL PROTECTED]
Subject: Factoring RSA
Date: Sun, 07 May 2000 17:54:33 GMT
I would like to know, given a factoring time ot Ft for an n digit RSA,
how to claculate the asymptotic time increment Ft' for n' (n'>n) for
the following algorithms:
CFRAC
GNFS
SNFS
Thanks
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Crossposted-To: comp.sys.acorn.misc
Subject: Re: Fresco transmits my name (was: Spammed after just visiting a site)
Date: 7 May 2000 17:52:32 GMT
Rev. James Cort <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, Mark Wooding
> <[EMAIL PROTECTED]> writes
>
> > * The symmetric session keys are too short. A space of 2^{128} bits
> > can be searched in less than a week given the sort of computing
> > power available to the US government.
>
> IMHO, Most likely possibility. Intel admit to having some *much* faster
> processors operating in their labs than anything generally available.
> Why shouldn't the government have similar or greater levels of computing
> power which *aren't* known about?
2^{128} is a big number. Let's assume, sort of for the sake of
argument, that Intel have designed terahertz processors, and for some
reason aren't selling them to anyone outside the US government. Let's
assume that they can do one key schedule *and* encryption *every* cycle.
To keep the numbers nice, let's say that that's 2^{40} encryptions every
*second*.
Now let's say that they have a million of these things. That's another
2^{20} factor. We're up to 2^{60} keys tested every second. (At this
point, we can find 16 DES keys per second.)
Hmm. We're still a factor of 2^{68} off where we want to be. Breaking
a 128-bit cipher, by brute force, with the computational resources
described above (not corrected for Moore's law) will take 2^{68}
seconds. That's unfortunate, because 2^{68} seconds is a little over 9
billion years.
Which is more than a week, I believe.
Let's correct for Moore's law. Let t be the time, in seconds, where 0
is now. Let Y be the number of seconds in a year: Y = 31,557,600.
I'll take Moore's law as `speed doubles every 18 months'. If the number
of keys-per-second at time t is E(t), then the number of keys-per-second
at time t + 3Y/2 is E(t + 3Y/2) = 2 E(t). A little bit of maths shows
that E(t) = E(0) k^t works well as a model, where k = 2^{2/3 1/Y}.
Now, the number of keys tried between times t0 and t1 is
/ t1
| E(t) dt
/ t0
if I'm not much mistaken (that was an integration sign). Since we're
presuming we start right now, let
/ T E(T) - E(0)
K(T) = | E(t) dt = -----------
/ 0 ln(k)
denote the number of keys which can be tried in time T. We want to find
T where K(T) = K. Trudging through the maths gives that
T = log_k ( K ln(k) / E(0) + 1)
Finally, choosing K = 2^{128} and E0 = 2^{60} gives t as about 62
years.
(Choosing the rather more plausible E0 = 2^{40} gives t as a little over
a hundred years.)
> > * The US government can break RSA by factoring 1024-bit moduli in less
> > than a week because
> > -- they have enough computing power to make the generalized number
> > field sieve work fast enough; or
>
> See above re. chips in labs
This is a rather trickier issue. The standard algorithm for factoring
numbers (and finding discrete logs) is the general number field sieve
(GNFS).
To help me get my numbers straight, I've just fetched RSA Security
Bulletin 13, which discusses issues of public key lengths. The
information is recent -- the document was published last month.
A 512-bit `hard' number, RSA-512, was factored last year. A 1024-bit
key, as used in SSL, requires 7 million times as much CPU and 2 thousand
times as much memory. Following this, and looking at the history of
large number factoring, breaking a 1024-bit RSA key might be possible in
about 2030-ish.
The same document suggests that breaking a 1020-bit RSA key is about as
expensive as breaking a 96-bit symmetric key. Applying the Moore's law
analysis against this shows that, with the silly estimate of E0 = 2^60 I
gave earlier, a 96-bit key will take about 15 years.
This ignores all sorts of complexities with breaking RSA, such as the
fact that there just isn't enough memory for the matrix phase of the
GNFS (although, of course, there might be by the time it's actually
needed, if we start sieving right now). The point I'm trying to make is
that, even if you're prepared to be silly about how much resources the
US Government has at its disposal, it's not likely that the keys used in
SSL are vulnerable.
I'm sure a real expert will correct me if I've messed up the above
analysis.
-- [mdw]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.tech
Subject: Re: How does PGP passphrase produce the session key ?
Date: Sun, 07 May 2000 18:10:43 GMT
Thierry FALISSARD wrote:
>
> I know the passphrase is hashed to produce the session key
> (I am interested here only in conventional encryption).
>
> If the passphrase is hashed by MD5, the size of the hash will be 128 bits.
> If the encryption algorithm is 3DES, 168 bits of key are required.
>
> How does PGP create the missing key bits ?
You can pad the remaining bits to zero to make a 168 bit word.
Tom
------------------------------
From: "JoeC" <[EMAIL PROTECTED]>
Subject: Newbie question about primes
Date: Mon, 1 May 2000 22:45:17 +0100
As I understand it, one of the key factors(pardon the pun) in the security
of PGP and similar is the time taken to factor a large prime number.
Does it not take an equally large amount of time to create a prime, which I
would need were I to create a private/public key pair? Obviously it can't,
or the thing wouldnt work.
Could someone point me at a good source (or is there a quick explanation)
for the obvious time difference between creating a prime compared to
factoring one, since I thought in order to determine if a number was prime,
you had to factor it?
Thanks
Joe
------------------------------
From: [EMAIL PROTECTED] (Earl K. Nimoy)
Subject: Re: Newbie question about primes
Date: Sun, 07 May 2000 19:20:16 GMT
"JoeC" <[EMAIL PROTECTED]> wrote:
>As I understand it, one of the key factors(pardon the pun) in the security
>of PGP and similar is the time taken to factor a large prime number.
It's impossible to factor a prime number. By definition, the only factors a
prime number has are itself and 1.
--
"Earl K. Nimoy" is actually 7640 519382 <[EMAIL PROTECTED]>.
0123 4 56789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: [EMAIL PROTECTED] (Sandy Harris)
Subject: Re: Joystick as RNG
Date: 7 May 2000 19:45:24 GMT
[EMAIL PROTECTED] (Tom St Denis) spake thus:
>Another rng idea is to use the input from a joystick. I wrote a small
>demo program (which I can share with anyone who asks, it runs on x86
>only...).
>
>A joystick essentially is just a series of bit fields comming in. One
>bit for the y axis and and 1 bit for the x-axis. When the joystick is
>dead-center the bits switch on and off with a prob 1/2. However the
>duration the bit is stuck doesn't appear to be less-than-random.
>
>My idea is just todo this.
>
>int rngbit() {
> do {
> a = y_axis xor x_axis
> b = y_axis xor x_axis
> } while (a == b);
>
> return b;
>}
>
>Which removes runs of the same bits. Since almost everyone with a x86
>PC has a joystick anyways, this may be usefull..
I doubt that. At a minimum, you need to estimate the entropy in those
inputs and apply some sort of mixing/compression function. e.g. collect
some large number of your x, y bits, run them through MD5 and you might
get 128 random bits. Choosing the large number and the hash function are
both tricky, though.
If you don't need cryptographically strong random numbers, there are lots
of reasonable pseudo-random techniques. Knuth is one good reference.
If you do need crypto strength, have a look at RFC 1750.
ftp://ftp.isi.edu/in-notes/rfc1750.txt
>Has this ever been discussed before?
>
>Tom
Yes, more-or-less discussed to death in fact. Once you understand the
basics from RFC 1750, try some of the links on this site:
http://www.openpgp.net/random/index.html
------------------------------
Subject: Re: Tempest Attacks with EMF Radiation
From: Diet NSA <[EMAIL PROTECTED]>
Date: Sun, 07 May 2000 12:44:40 -0700
In article <[EMAIL PROTECTED]>, Diet
NSA <[EMAIL PROTECTED]> wrote:
Particles are quantum bundles of field theory.
A typo which should read "field energy" instead.
"If we do not prevent highly classified secrets from being stolen,
then how are we going to sell them to the Chinese?"
- Madeleine Albright (addressing recent thefts)
========================================================================
* 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: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: SBOX using boolean logic
Date: Sun, 07 May 2000 19:49:25 GMT
On Sun, 7 May 2000 12:02:01 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt Tim Tyler <[EMAIL PROTECTED]> wrote:
>Tom St Denis <[EMAIL PROTECTED]> wrote:
>: Tim Tyler wrote:
>:> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
>:> : Is it even possible to make a bijective sbox using just boolean
>:> : expressions? I am pretty sure it is.
>:>
>:> Yes [...]
>
>: So is it just a huge search to find a bijective function then?
>
>There are various ways of constructing bijective functions, using
>boolean logic gates. If you look at the work of those who've built
>block cyphers in hardware, this might provide you with some ideas.
Yeah, this is the fundamental issue, isn't it? I mean, the block
cipher itself is just that sort of construction based on smaller
transformations. The difference from creating a larger table out of
small ones is that we don't (and can't) store the cipher result.
>What to do depends on to what extent you're happy with s-boxes that
>deviate in some systematic way from what you'd get from a random LUT -
>i.e. how happy you are with non-random, "algebraic" s-boxes.
One way to do it is to build a small block cipher which uses boxes we
can build to create other boxes which we then use. My particular
contribution has been the orthogonal Latin square stuff which
guarantees diffusion, effectively doubles the block size in each
layer, and we can have as many layers as we want. But if the issue is
creating 4-bit tables, that's just about as easy as it gets. I would
shuffle a counting-sequence table with a pseudorandom sequence, test
it, and keep the n best. Right?
>You can do the equivalent of table look-ups with gates if you want to.
>I'm not certain of the most compact/fastest way of doing this - but
>perhaps imagine a binary tree branching from the inputs leading to a
>large number of leaves corresponding to the outputs.
It might be that one could try to factor particular bit columns into
the closest expression to a linear/affine sequence, but we want that
to be distant, so we can expect the result to be messy in general.
Other than that, we might just luck on some construction which tests
well and factors well in some other way, but factoring well in any way
at all probably would be a direct indication that the box is simpler
than we really want.
>You could use a Feistel-like construction - and then use several
>rounds of whatever function you like plus some XORs. The approach I seem
>to be most interested in would be to build lots of small non-linear
>bijective functions out gates and (carefully) connect them together.
Been there, done that. That is something like basic S-P stuff.
Without very special conditions, I was never satisfied with the
diffusion results. Maybe you have something else, though.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: James MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.acorn.misc
Subject: Re: Fresco transmits my name (was: Spammed after just visiting a site)
Date: Sun, 07 May 2000 20:33:28 +0100
In message <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Mark Wooding) wrote:
> David J. Ruck <[EMAIL PROTECTED]> wrote:
> > For further research look into certificate issuing authorities,
> > i.e. Verisign and their relationship to certain branches of the US
> > government.
> See also Thawte Associates in Africa.
VeriSign may yet expand to be all-encompassing. Worrying. Very.
> It's also possible to make your own CA keys and create certificates if (a)
> you're a cheapskate, or (b) you're paranoid.
While being your own CA is a good idea, you're starting a new root. Future
software may require certification by root keys belonging to the
NSA/VeriSign/Microsoft/whoever.
Doesn't offer any more security over VeriSign et al.; you can't prove via
a cryptographic chain of trust that you are Mark Wooding of NSICT and not
Agent Spook of the NSA if you generate your own key, but if you use VeriSign
to sign your key, what's to stop their "special relationship" with the US
government allowing them to sign Agent Spook's key, certifying that he is in
fact you?
Centralised forms of trust are not, IMO, a good idea. I really don't like
being forced to trust anyone. I don't like the insinuation that if my key/CA
does not belong to a web-of-trust that it is questionable. This is what SSL's
certificate management system does.
--
James MacDonald; Acorn/NeXT/Rush
Please remove "-invalid" to reply to news by e-mail.
Apologies for this, but it is necessary to avoid drowning in spam :(
------------------------------
From: James MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.acorn.misc
Subject: Re: Fresco transmits my name (was: Spammed after just visiting a site)
Date: Sun, 07 May 2000 20:27:52 +0100
In message <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Mark Wooding) wrote:
[ Mmm.. crypto and calculus.. ]
> Rev. James Cort <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>, Mark Wooding
> > <[EMAIL PROTECTED]> writes
> >
> > > * The symmetric session keys are too short. A space of 2^{128} bits
> > > can be searched in less than a week given the sort of computing
> > > power available to the US government.
> >
> > IMHO, Most likely possibility. Intel admit to having some *much* faster
> > processors operating in their labs than anything generally available.
> > Why shouldn't the government have similar or greater levels of computing
> > power which *aren't* known about?
> 2^{128} is a big number. Let's assume, sort of for the sake of
> argument, that Intel have designed terahertz processors, and for some
> reason aren't selling them to anyone outside the US government.
Well, the liquid helium coolant /is/ rather expensive.
> Let's assume that they can do one key schedule *and* encryption *every*
> cycle. To keep the numbers nice, let's say that that's 2^{40} encryptions
> every *second*.
> Now let's say that they have a million of these things. That's another
> 2^{20} factor. We're up to 2^{60} keys tested every second. (At this
> point, we can find 16 DES keys per second.)
> Hmm. We're still a factor of 2^{68} off where we want to be. Breaking
> a 128-bit cipher, by brute force, with the computational resources
> described above (not corrected for Moore's law) will take 2^{68}
> seconds. That's unfortunate, because 2^{68} seconds is a little over 9
> billion years.
> Which is more than a week, I believe.
By brute force, perhaps. But attacks on ciphers are possible. IDEA has been
broken for 4.5 rounds. Almost everyone is using 8, but it illustrates the
point.
If your cipher is secure enough that the only way it's going to be penetrated
is by brute force, apply the above.
It's easy to see when your maths is correct; your solution is sensible/valid
or it's not. It's not easy to see when your cryptography is strong. If you
miss something in designing a cipher which weakens it, say, to the equivalent
of half the key length of the equivalent cipher without the limitation, you
might well not spot it.
Unlike academia, the NSA doesn't usually publish its cryptanalyses. Nuts.
> Let's correct for Moore's law.
Moore's Law won't last forever. If it's not limited by time, after a few
iterations it begins to suggest the impossible. Silicon is limited in what
you can do with it. Eventually, you will reach a ceiling on performance
simply because it will not be possible to fab chips at <x> microns, access
memory at <y> cycles/second, or do <z> amount of work without generating
silly amounts of thermal energy.
It's certain that computing power will advance over time. But not necessarily
in silicon. Moore's Law takes no account of other yet-to-be-discovered forms
of computing that may not involve transistor technology.
[snip]
> To help me get my numbers straight, I've just fetched RSA Security
> Bulletin 13, which discusses issues of public key lengths. The
> information is recent -- the document was published last month.
> A 512-bit `hard' number, RSA-512, was factored last year.
Hmm? I thought that the RSA numbers were denoted by digit, rather than bits.
RSA-232 = 100988139787192354690956489430946858281823382195557395514112051620
583102133852854537436610975715436366491338008491706516992170152473
329438927028023438096090980497644054071120196541074755382494867277
1374075011577182305398340606162079 (digits = 232, bits = 768)
> A 1024-bit key, as used in SSL, requires 7 million times as much CPU and 2
> thousand times as much memory.
Assuming current factoring techniques known are employed. And perhaps the NSA
have new, secret algorithms. For safety, I like to assume that anything to be
discovered by civilian cryptographers in the next 10 years, the NSA may
already know about.
The problem with not knowing what the NSA are doing is that in ten years time
we may know that algorithm X has a gaping hole.. whereas the NSA were already
exploiting it.
> Following this, and looking at the history of large number factoring,
> breaking a 1024-bit RSA key might be possible in about 2030-ish.
By which time people should be up to 2048-bit RSA keys. You can spot the
snake-oil vendors who claim "Wow! 16384-bit RSA keys NOW!" - they're just
silly :-)
> The same document suggests that breaking a 1020-bit RSA key is about as
> expensive as breaking a 96-bit symmetric key.
I think the same thing applies to any other encryption scheme involving
primes, or at least the "n = pq" problem where p and q are secret.
> The point I'm trying to make is that, even if you're prepared to be silly
> about how much resources the US Government has at its disposal, it's not
> likely that the keys used in SSL are vulnerable.
s/SSL/unpatched SSL/
OK. You've established that the US Government can't crack SSL. But I'm sure
they could subvert a lot of commercial SSL implementations, to bring most
people under their control. Assuming you stick to OpenSSL, that's fine.
The problem is that cryptography is sufficiently complex that you either need
to spend some serious time researching algorithms, key exchange methods,
possible weaknesses, and so on to be able to use it confidently.
The average person wanting anonymity and privacy won't have done this. S/he
will be using a standard piece of software. Assume that today this piece of
software is IE 5/Outlook Express (evil, but pervasive). The crypto seems to
work; it produces nice unintelligible garbage. The person is happy.
The crypto's been doctored. The NSA know some of the bits. They can reduce
their cracking workload. They're happy.
The US/UK Government will not just try to break your right to privacy by
decrypting your keys. They'll break into your house, steal your computer,
attempt to crack your passphrase, tap your telephone, park a van outside your
house and snoop your password with TEMPEST, etc.
If you're on Mars and sending SSL-encrypted data with OpenSSL to someone on
Mercury, you're pretty safe. But encrypted data is always decrypted at one
stage.
--
James MacDonald; Acorn/NeXT/Rush
Please remove "-invalid" to reply to news by e-mail.
Apologies for this, but it is necessary to avoid drowning in spam :(
------------------------------
From: Terry Blunt <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.acorn.misc
Subject: Re: Fresco transmits my name (was: Spammed after just visiting a site)
Date: Sun, 7 May 2000 19:49:52 +0100
In article <[EMAIL PROTECTED]>, Mark Wooding
<[EMAIL PROTECTED]> writes
>Rev. James Cort <[EMAIL PROTECTED]> wrote:
>> In article <[EMAIL PROTECTED]>, Mark Wooding
>> <[EMAIL PROTECTED]> writes
>>
>> > * The symmetric session keys are too short. A space of 2^{128} bits
>> > can be searched in less than a week given the sort of computing
>> > power available to the US government.
>>
>> IMHO, Most likely possibility. Intel admit to having some *much* faster
>> processors operating in their labs than anything generally available.
>> Why shouldn't the government have similar or greater levels of computing
>> power which *aren't* known about?
>
>2^{128} is a big number. Let's assume, sort of for the sake of
<huge snip>
Surely a more down-to-earth practical limitation would be the number of
*different* pieces of encrypted data such an organisation would have to
crack in order to get anything meaningful.
If I, and a group of friends decide that we will *only* communicate via
encrypted e-mails, the whole idea rapidly becomes impractical for a code
breaker due to sheer weight of numbers.
If encrypted data transfer via the Internet *really* takes off, how is
anyone going to manage the vast quantity of date that would need to be
screened to find what was being searched for?
Needle in a haystack becomes simple by comparison (all you need is a
magnet + time)
--
Terry Blunt <[EMAIL PROTECTED]>
You are no longer a child when your big toe doesn't fit the bath tap.
You're an adult when you stop trying.
------------------------------
From: [EMAIL PROTECTED] (Sandy Harris)
Subject: Re: Newbie question about primes
Date: 7 May 2000 20:08:27 GMT
[posted and mailed]
[EMAIL PROTECTED] (JoeC) spake thus:
>As I understand it, one of the key factors(pardon the pun) in the
>security of PGP and similar is the time taken to factor a large prime
>number.
No. For the RSA public key system, the issue is factoring a large number
which is the product of two primes. This is considerably harder than
finding the product, given the primes.
Other public key systems use other hard-to-reverse caculations. One is
the 'discrete logarithm problem' modulo some large prime. Exponentation
is easy. I can quickly calculate 2 ^ 8 mod 13 = 9, but given 2^x mod 13 =
9, finding x is harder. Especially if we replace 13 with an
inconveniently large prime.
>Does it not take an equally large amount of time to create a prime,
>which I would need were I to create a private/public key pair? Obviously
>it can't, or the thing wouldnt work.
You create two primes. For large primes, this is not a trivial effort,
but it is reasonably quick and you only have to do it once, when creating
the key pair.
>Could someone point me at a good source (or is there a quick
>explanation) for the obvious time difference between creating a prime
>compared to factoring one, since I thought in order to determine if a
>number was prime,you had to factor it?
>
There are fancier ways; try a web search on Lucas and Lehmer or prime
tests for details, but one fairly simple test is based on a theorem of
Fermat.
a^p mod p == a for any integer 0 <= a < p
e.g. 2^ 7 = 128 and 128 == 2 mod 7 (remainder when you divide by 7 is 2)
So one way to test if x is prime, is to calculate
a^x mod x for some random a
If the result is not a, x is certainly not prime.
If the result is a, try again with another random a.
Repeat until you feel confident enough.
This is not foolproof; there's a class of numbers (Cunningham, I think)
that pass this test for all a but aren't prime. They are very rare.
a^x can be calculated efficiently, in about log2(x) steps.
e.g. a^107 = a * a^106
a^106 = (a^53)^2
a^53 = a * a^52
a^52 = (a^26)^2
a^26 = (a^13)^2
etc.
You don't need anything like 107 multiplications here.
------------------------------
** 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
******************************
