Cryptography-Digest Digest #66, Volume #9 Wed, 10 Feb 99 18:13:04 EST
Contents:
Re: Intel's description of the Pentium III serial number ([EMAIL PROTECTED])
Re: Encryption Algorithms (Paul Crowley)
Re: Schneier key stretching? (Paul Crowley)
Re: RNG Product Feature Poll (Michael Sierchio)
Re: Pentium III serial number - Why should webs be free? (Jim Felling)
Re: RNG Product Feature Poll (R. Knauer)
Position Posting ([EMAIL PROTECTED])
Re: RNG Product Feature Poll (R. Knauer)
Re: Everybody Seems to Have a Web Site These Days! (John Savard)
Re: Everybody Seems to Have a Web Site These Days! (David Crick)
Re: Threat Models: When You Can't Use a One-Time Pad (Darren New)
Re: An observation on sci.crypt ("Trevor Jackson, III")
Re: Schneier key stretching? (David Crick)
Re: simple challenge protocol (Jeremy Nysen)
Re: Transforming RC4 into a one-way hash function (Bauerda)
Re: What is left to invent? (John Curtis)
Diffie-Hellman with RSA-type modulus HAS been thought of! (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.intel
Subject: Re: Intel's description of the Pentium III serial number
Date: Wed, 10 Feb 1999 15:45:11 GMT
In article <[EMAIL PROTECTED]>,
Chris Fischer <[EMAIL PROTECTED]> wrote:
> Anthony Naggs wrote:
> >
> > After much consideration Chris Fischer decided to share these wise
> > words:
> > >Nogami wrote:
> > >>
> > >> On 7 Feb 1999 19:42:59 +0100, Anonymous <[EMAIL PROTECTED]> wrote:
> > >>
> > >> >> 3. Website typically asks user permission to access personal
> > >> >> information, including processor serial number
> > >> >
> > >> >Emphasis on the word 'typically'?
> > >>
> > >> I'm not terribly concerned about being able to disable the serial
> > >> number, or prevent it from being read...
> > >>
> > >> What I AM concerned about is websites (and software authors) that just
> > >> block all access unless you enable it, thus forcing your hand.
> >
> > This doesn't make much sense, why should a web site care if I'm using my
> > home PC, a PC at work, in a cybercafe or in college where I'm doing an
> > evening course?
> >
> > >Wouldn't it be fun to change the undefined opcode handler to emulate
> > >this, and pollute the net with fake serial numbers?
> >
> > Software wont ask for the Serial Number unless the feature is present,
> > so there are no undefined opcodes for you to catch.
>
> I realize that. But wouldn't it be fun if we could?
How about this. AMD releases a clone of the PIII that gives you instructions
to let you set the serial number to whatever you like. Which would you buy?
AMD of course.
How could Intel stop that?
>
> >
> > --
> > BAD COMPUTER! That's my registry file you've trashed.
>
> --
>
> Chris Fischer [EMAIL PROTECTED]
> Coda Software, Limited
>
>
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Encryption Algorithms
Date: 10 Feb 1999 09:45:58 -0000
Asher Pressman <[EMAIL PROTECTED]> writes:
> Does anyone know of any good sites where i can find encryption
> algorithms? I've been looking for a while and i just can't find
> anything...
Peter Gutmann's enormous link farm is a useful starting point.
http://www.cs.auckland.ac.nz/~pgut001/links.html
--
__
\/ o\ [EMAIL PROTECTED] http://www.hedonism.demon.co.uk/paul/ \ /
/\__/ Paul Crowley Upgrade your legacy NT machines to Linux /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Schneier key stretching?
Date: 10 Feb 1999 10:17:35 -0000
The DoggFather <[EMAIL PROTECTED]> writes:
> What is Schneier's "key stretching" method? I don't think it's in his book,
> nor his web site. Search engines couldn't find it. Links to relevent
> websites would be helpful, unless someone has the kind heart to oust my
> ignorance of this subject with a layman-level explanation. Thanks.
John Kelsey, Bruce Schneier, Chris Hall, David Wagner, "Secure
Applications of Low-Entropy Keys",
http://www.counterpane.com/low-entropy.pdf
Passphrases usually aren't very good; users generally aren't very good
at thinking of them. So even if your secret key is encrypted with
256-bit Serpent, the key used will be generated from your passphrase,
so the attacker can avoid trying to guess all 2^256 keys if they can
simply try around 2^40 (or fewer) likely passphrases to get in.
Key stretching makes the transformation between passphrase and key
really expensive to compute. The downside is that when you type in
your passphrase to decrypt your messages, it'll take perhaps half a
second to verify rather than half a millisecond. The upside is that
it will also take your attacker a thousand times as long to reject
each guess at your passphrase, which is nearly as good as increasing
your passphrase entropy by ten bits.
In practice you should be able to get well over ten bits out of the
technique. This has actually been known for a while; the paper names
it, describes it with care including some necessary precautions, and
gives a proof that with reasonable assumptions a particular technique
will be secure.
Treat passphrases like radioactive waste; they're very secret and very
poor, and require careful handling. Pretty much every application
that accepts a passphrase should apply the techniques described in
this paper. You can also apply some of the ideas to keys limited to
40- or 56-bits for stupid legal reasons, though unlike passphrases
it's not always clear that the time to stretch the key is acceptable.
hope this helps,
--
__
\/ o\ [EMAIL PROTECTED] http://www.hedonism.demon.co.uk/paul/ \ /
/\__/ Paul Crowley Upgrade your legacy NT machines to Linux /~\
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: RNG Product Feature Poll
Date: Wed, 10 Feb 1999 09:15:59 -0800
Reply-To: [EMAIL PROTECTED]
"Wm. Toldt" wrote:
>
> Herman Rubin wrote:
>
> > Random does not imply independent or equidistributed.
>
> This statement appears to be wrong. Not only is it contrary to my
> opinion, but a book by Donald Knuth says the following
Let me rephrase Herman's statement: Random does not imply independent
or equidistributed, but some will infer those qualities when someone
utters the term ;-)
I assume that it is the chaotic property of phenomena that make them
useful for the purposes of a hardware RNG to be used in crypto. This
gives us part of what we need. Satisfying the conditions that it be
*approaching* an equal distribution of bits and *probable* independence
might fulfill the remaining requirements.
------------------------------
Date: Wed, 10 Feb 1999 11:30:44 -0600
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.sys.intel
Subject: Re: Pentium III serial number - Why should webs be free?
Scott Berg wrote:
> Gee, a company (Microsoft or anyone else) spends a fortune learning about a
> topic and putting it on the web, then they expect people to PAY for it? And
> lock out those who can't prove that they HAD? The nerve of them all!
>
Er.. The site in question is their free technical support site. And they don't
expect people to pay for it. They just lock out people that are using their
programs(such as IE) -- legally purchased and configured with settings approved
by Microsoft.
>
> Why, I regularly go to the gas station and fill up my car's tank without
> paying for it, go to the supermarket and fill up my cart without paying for
> it, use the telephone without paying for it, ... Why should it be any
> different to fill up my hard drive without paying for it?
You should report yourself to the proper authorities right now then.
>
>
> Sarcasm aside, the web is changing from a government subsidized (read: YOUR
> tax money) experiment into a business. You pay for other goods and services
> like those listed above. Why should web content be different? Now, I agree
> that bug fixes should be free since they shouldn't have been there in the
> first place, but handing them out only to those who bought the original
> package instead of pirating it seems only fair. I even agree that the net
> can be compared to highways, where taxes pay for the "basics" but private
> trucking companies make money by charging you for hauling stuff on it.
Since this is their bug fixes/ known issues with our software site you shoot
your own foot here.
>
>
> But remember:
> Ain't no such thing as a free lunch!
>
> Nogami wrote in message <[EMAIL PROTECTED]>...
> >On Mon, 8 Feb 1999 20:17:44 +0000, Anthony Naggs
> ><[EMAIL PROTECTED]> wrote:
> >
> >>>> What I AM concerned about is websites (and software authors) that just
> >>>> block all access unless you enable it, thus forcing your hand.
> >>
> >Ever tried getting on Microsoft's online support pages with cookies
> >disabled? It totally locks you out. No cookies = no entry.
> >
> >That's why I'm afraid of this Intel serial number idea...
> >
> >N.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: RNG Product Feature Poll
Date: Wed, 10 Feb 1999 19:17:32 GMT
Reply-To: [EMAIL PROTECTED]
On 10 Feb 1999 09:03:45 -0500, [EMAIL PROTECTED] (Herman Rubin)
wrote:
>That many people use "random" in the sense of "equally likely"
>does not mean that the two should be confused. I suggest that we
>keep things clear by using "equidistributed" instead. Random
>sequences are unpredictable, but not necessarily equidistributed.
A random number generator for use with the OTP cryptosystem must be
capable of generating all possible finite sequences equiprobably or
else the ciphers will leak information in a significant manner, making
them unsecure.
If that is what you mean by "equidistributed", then a TRNG must be
equidistributed. Indeterminancy is a necessary condition but not a
sufficient condition unless you are restricting it to an equiprobable
distribution. IOW, an indeterminant non-equidistributed random number
generator will not be proveably secure if it results in too much
information being leaked.
That is why it is crucial not to filter any sequences from the output
of a TRNG. That is also why Kolmogorov Complexity is not a valid
criterion for crypto-grade randomness. If certain sequences have a low
probability, or even zero probability, of occurance then the
cryptanalyst can use that fact to attack the ciphers.
A proveably secure cryptosystem requires a random number generator
that is capable of generating an equiprobable distribution of all
possible finite sequences for the keystream.
Bob Knauer
"It is not a matter of what is true that counts, but a matter of
what is perceived to be true."
--Henry Kissinger
------------------------------
From: [EMAIL PROTECTED]
Subject: Position Posting
Date: Wed, 10 Feb 1999 19:33:40 GMT
Reply-To: [EMAIL PROTECTED]
I am looking for a data security expert to aid in a new and exciting
electronic commerce initiative at America One. America One is the largest
direct marketer of cellular services in the United States. We are growing at
an unbelieveable rate.
I am looking for someone who can design and build a DMZ for our company and
has expertise in cryptography and other security technologies (ssl etc). Java
Knowledge and skills are required, Experience in object oriented is preferred.
This is a great opportunity to work in a world class information technology
organization. If you are interested please forward your resume to
[EMAIL PROTECTED]
Paul Given
Manager Electronic Commerce
America One Communications
Paul Given
Electronic Commerce
America One Communications
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: RNG Product Feature Poll
Date: Wed, 10 Feb 1999 20:13:19 GMT
Reply-To: [EMAIL PROTECTED]
On 10 Feb 1999 08:52:54 -0500, [EMAIL PROTECTED] (Herman Rubin)
wrote:
>If by TRNG, you mean one in which all sequences have the same
>probability, you will not get it. What you will have to settle
>for is one which is "probably" "close" to that.
That is something that can determine experimentally by doing a
complete audit on each subsystem of the TRNG, including subsystem
diagnostic tests. I believe the term in Kolmogorov Complexity Theory
is pac (probably approximately correct). If you can prove
experimentally that a TRNG is pac-secure to an acceptable level, then
it is "proveably secure" to that level.
That cannot be done with other RNGs since statistical testing on the
output is not sufficient to certify anRNG as secure to any level of
confidence.
Bob Knauer
"It is not a matter of what is true that counts, but a matter of
what is perceived to be true."
--Henry Kissinger
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Everybody Seems to Have a Web Site These Days!
Date: Wed, 10 Feb 1999 19:21:18 GMT
[EMAIL PROTECTED] (Frode Weierud) wrote, in part:
>The URL for GCHQ and some other crypto agencies are at my
>Web page under the links for Government Agencies:
>http://home.cern.ch/~frode/crypto/index.html
And after visiting your site once again, I noticed a paper by W. T.
Tutte, which I have used to correct and expand my description of the
Lorenz Schlusselzusatz.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
Date: Wed, 10 Feb 1999 19:58:13 +0000
From: David Crick <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Everybody Seems to Have a Web Site These Days!
[EMAIL PROTECTED] wrote:
>
> http://www.gchq.gov.uk/
Just make sure you use a bare-bones computer (OS+web) so they
can't steal your secret keyring and then crack the password ;)
David.
--
+---------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] http://members.tripod.com/~vidcad/ |
| Damon Hill WC '96 Tribute: http://www.geocities.com/MotorCity/4236/ |
| Brundle Quotes Page: http://members.tripod.com/~vidcad/martin_b.htm |
| PGP Public Key: (RSA) 0x22D5C7A9 00252D3E4FDECAB3 F9842264F64303EC |
+---------------------------------------------------------------------+
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Threat Models: When You Can't Use a One-Time Pad
Date: Wed, 10 Feb 1999 18:40:37 GMT
R. Knauer wrote:
>
> On Mon, 08 Feb 1999 23:03:25 GMT, Darren New <[EMAIL PROTECTED]>
> wrote:
>
> >> Truth is found in Reality. Falsity is a lack of Truth.
>
> >Shame on you. Godel disproved this decades ago.
>
> Godel disproved using formal systems to decide all truth and falsity.
>
> My statement permits experimentation in the real world to decide truth
> and falsity.
I'm merely objecting to "Falsity is a lack of Truth." I don't know of
any experimental way to prove a lack of Truth, only experimental ways to
prove the lack of something that would contradict your theories. Nuff
said from me.
--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"Everybody down! He's becoming disgruntled!"
The singular of "data" is "datum," not "anecdote."
------------------------------
Date: Wed, 10 Feb 1999 13:39:56 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: An observation on sci.crypt
==============2AB7D06E048A99A339BEA193
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Emrul Islam wrote:
> Hello there,
> Over the last few weeks I have noticed a real big increase in the
> number of articles being posted in this group, and also the
> cryptographic intellegence levels on average have gone up.
> There is now constructive criticism, professional cryptographers
> and _lots_ of interesting ideas floating around.
>
We can fix that! ;-)
==============2AB7D06E048A99A339BEA193
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
Emrul Islam wrote:
<BLOCKQUOTE TYPE=CITE> Hello there,
<BR> Over the last few weeks I have noticed a real big
increase in the number of articles being posted in this group, and also
the cryptographic intellegence levels on average have gone up.
<BR> There is now constructive criticism, professional
cryptographers and _lots_ of interesting ideas floating around.
<BR> </BLOCKQUOTE>
<I>We can fix that! </I> ;-) </HTML>
==============2AB7D06E048A99A339BEA193==
------------------------------
Date: Wed, 10 Feb 1999 19:55:56 +0000
From: David Crick <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Schneier key stretching?
Christopher wrote:
>
> I found it using AltaVista, anyway the PDF is at
> http://www.counterpane.com/low-entropy.pdf
http://www.counterpane.com/low-entropy.html
Provides and abstract and allows you to select either postscript
or PDF.
David.
--
+---------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] http://members.tripod.com/~vidcad/ |
| Damon Hill WC '96 Tribute: http://www.geocities.com/MotorCity/4236/ |
| Brundle Quotes Page: http://members.tripod.com/~vidcad/martin_b.htm |
| PGP Public Key: (RSA) 0x22D5C7A9 00252D3E4FDECAB3 F9842264F64303EC |
+---------------------------------------------------------------------+
------------------------------
From: Jeremy Nysen <[EMAIL PROTECTED]>
Subject: Re: simple challenge protocol
Date: Thu, 11 Feb 1999 09:19:30 +1100
Cameron wrote:
>
> Paul LeMahieu wrote:
>
> > Hi,
> >
> > I'm writing some client-server code, and I'd like a simple
> > method for the server to verify that the command came from
> > a client having the correct password.
> >
> > My requirements:
> >
> > 1) no clear-text passwords sent over the network
> > 2) server only executes command if it was sent
> > by a client with the correct password
> > 3) Model: hackers can look at the network, block packets,
> > send packets, spoof machine identities, etc.
> >
> > I have a feeling the algorithm I'm about to describe is
> > very well known. It seems simple and safe, but I want to make sure
> > there's nothing obvious I'm missing.
> >
> > Assumptions:
> >
> > Both client and server know a password (secret key k),
> > and a good one-way hash f(k,data). Everything but k
> > is known by potential hackers.
> >
> > Protocol:
> >
> > 1) Client sends command c to server.
> > 2) Server creates challenge r (random number) and sends it to the
> > client
> > 3) Client responds with f(k,c+r)
> > 4) Server compares the f(k,c+r) returned by the client with
> > a locally computed one. If they're the same, the server
> > executes the command c.
> >
> > Is this as secure as it seems to me? I see only one shortcoming: the
> > server
> > must store the clear-text password somewhere (storing a one-way
> > encrypted version
> > won't do).
> >
> > I welcome any comments on this protocol, as well as comments on the
> > faith
> > I've placed in "a good one-way hash".
> >
> > Thanks,
> >
> > Paul LeMahieu
> > [EMAIL PROTECTED]
>
> In esseence the protocol is secure but it does have a few failings.
> It is like most protocols vulnerable to a man-in-the-middle attack. The
> only way around this would be to introduce a trusted third-party to
> verify both the server and the client to each other.
> Also it would be wiser to remove the command from the first step or
> from the third and fourth steps. The reason for this being that if c is
> sent as plaintext with the protocol and later used as part of the hash
> function it introduces an element of insecurity to the hash function as
> any one listening in on the protocol will know both c and r there by
> reducing the difficulty in breaking the hash function severly. In
> practice at the moment this may not seem like a serious enough point but
> it you can never be to careful.
> The server does not have to store the plain-text password, it can in
> fact store a one-way has of the password so long as the same one-way
> hash is used by the client. Put simply when the client uses the
> password k in the hash function in step 3 before including it with c and
> r it first passes it through another hash function, preferably not the
> same one used in the protocol for communications between the client and
> the server, and then includes it in the final hash sent to the server.
> This means that the server need only store the hash of the password and
> not the plain-text version.
By storing a one-way hash on the server, the protocol has not changed as
far as
the hacker is concerned. (Obviously it does make it harder for the
average user to accidentally view a password and use it later.) The
stored hash becomes a plaintext equivalent.
The plaintext equivalent can then be used as a plaintext password by
modifying the client application (easy in the unix/Open Source world,
still relatively easy in the Windows world). This can be then be shown
to be equivalent to sending plain text passwords over the network and
storing the plaintext on the server (a bad option).
The solution: Well there are a couple. The first is to use some form of
public-key
crypto-system. This is dangerous, as a poor implementation (which may
seem great -
like SSL) can be susceptible to a man-in-the-middle attack. To resist
the man-in-the-middle attack, most protocols store a private key on the
local host, and another on the server. (Not so good if you move from
machine to machine in a corporate network.)
Another good solution can be found at <http://srp.stanford.edu/srp>. The
SRP (Secure Remote Password) protocol uses modular-exponentiation in a 4
pass protocol. It has some very nifty features, but solves not only the
network secrecy issues, but also the storage issue at the time. It also
exchanges a session key that can be used for encryption. Very
interesting - worth checking out.
Jeremy Nysen
------------------------------
From: [EMAIL PROTECTED] (Bauerda)
Subject: Re: Transforming RC4 into a one-way hash function
Date: 10 Feb 1999 22:34:27 GMT
>1. Generate 20 random bytes
>2. Concatencate the reversed e-mail address to the original
>3. Load the e-mail address into RC4 as the key
>4. Encrypt the 20 bytes generated in step 1.
>5. Use the output as the hash.
>
>The hash (step 5), the user's e-mail address and the random bytes (step 1)
>are
>saved in the database.
>
>Will this be secure, assuming the database is secure? For verification
>purposes (i.e. when I need to verify that the user knows his/her e-mail
>address for some reason), I ask them to provide it, retrieves the random
>bytes
>from the database and then go through the protocol as usual from step 2.
Yes, I believe that this is secure for your purpose, but I have a question.
Why do you just XOR the random bytes into the keystream? Why not add them on
to the end (or beginning) of the e-mail address as part of the key?
David Bauer
------------------------------
From: [EMAIL PROTECTED] (John Curtis)
Subject: Re: What is left to invent?
Date: 10 Feb 1999 22:33:01 GMT
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (R. Knauer)
writes:
>
>As long as you can demonstrate that by doing an audit on the TRNG,
>including diagnostics on its subsystems, then it is proveable secure
>to a certain experimental level. To apprecitate that, you must
>consider experimental proof as a valid form of proof.
>
[Pardon the length of this post.]
I agree with you 100% in this statement. The thing that
concerns me is that we haven't really arrived at any kind
of statement as to "how good is good enough" in a real,
on the test bench, TRNG.
Every real system is going to exhibit leaks and feedback
paths of one sort or another. Way back when, I used to
design instrument electronics, and this is a truism..
For example, it is going to be very difficult to get >120 db
of signal to noise ratio out of any realized RF system, for the
very simple reason that the thermal noise at the characteristic
impedence of real systems checks in at approx. this level.
(A correct analysis of this is quite a bit more complicated, but
you grasp the concept.)
Real sampling systems differ from first order descriptions of them
by various distortions and sources of error.
Lets just think about a TRNG that consists of a source of
thermal noise (big resistor), an amplifier, a sampler (A/D converter),
some digital circuit to drive the sampler, and a connection to
a computer.
Let's list some sources of error in this system:
1. The resistor is going to have to be shielded from outside
E fields, B fields, etc. This shielding is going to be
impefect and (non random) outside signals are going to couple
in.
2. The resistor/amplifier system will distort the spectrum of
white noise theoretically available from the thermal noise by
having a limited bandwidth and a non-flat passband.
3. The amplifier is going to have its own noise sources, which
are probably going to look like semiconductor noise which may have
1/f characteristics different from thermal noise, may be bursty.
4. The sampling A/D is going to have non-linear characteristics.
Hopefully, it is fully monotonic and choosing the proper bits in
its output eliminate these effects.
5. The digital circuit driving the system will have a quartz
oscillator in it somewhere, this may drift thermally or with
age, or pick up microphonics from outside the system. Small
effects, but these are there.
6. The computer this is hooked to is very noisy and may couple
say, the horizontal refresh signal of the monitor into the
A/D, biasing the comparator here in some subtle periodic way.
Every real system is going to exhibit imperfections of some
order. I believe that designing these effects out of
digital detectors (like geiger counters and photomultiplers)
is easier than doing that for analog detectors. Radioactive
decay is also a nice system because you are using avalanche
detectors that couple very small events (individual particle
decays) up to macro-signal levels as a digital event.
There are still going to be some subtle detector effects there
(how about supply
ripple in some of the high voltage supplies changing
probability of detecting a particle of given energy).
The collection of atoms in the source is pretty impervious to
outside influence, which is nice and not true of the electrons
in a thermal noise source.
I'm sorry for being so longwinded. I'm left with the
question: what test or tests can we apply that set
some threshold on how large these distortions can be and
still allow useful cryptographic use of a given RNG?
ciao,
jcurtis
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Diffie-Hellman with RSA-type modulus HAS been thought of!
Date: Wed, 10 Feb 1999 22:38:25 GMT
And, apparently, it has been found to work very well:
http://www.scs.carleton.ca/~morin/reports/reductions/provable/node18.html
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
** 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
******************************
