Cryptography-Digest Digest #740, Volume #11 Tue, 9 May 00 11:13:00 EDT
Contents:
Re: Proving that you are who you say you are ("C. Prichard")
Re: Scary Possibility: Ticklish Chips ([EMAIL PROTECTED])
Re: new Echelon article ([EMAIL PROTECTED])
Re: Proving that you are who you say you are ("C. Prichard")
Re: Why no civilian GPS anti-spoofing? / proposal ("Trevor L. Jackson, III")
Re: Any good attorneys? ("Trevor L. Jackson, III")
Re: Unbreakable Superencipherment Rounds ("C. Prichard")
Re: Prime Generation in C,C++ or Java (Bob Silverman)
----------------------------------------------------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Proving that you are who you say you are
Date: Tue, 09 May 2000 13:36:46 GMT
You can wrap the site in Perl and use sophisticated server key for tag =
encryption. The encrypted tag are a low cost line of security for server =
content.
In the scheme, each successful login generates a new page tag encryption =
key. Each user having his own key that is also optionally refreshed with =
new page content. (With frames the key is changed for each frame as it =
is refreshed.) This makes user impersonation very unlikely and forces =
all users to use the links presented and the passwords to get =
information.
The method does not require a client side cookie.
If a user shares his password, it is possible that another person can =
use the account,, but not jointly as both users will race for the same =
encryption key only one time with the loser being ejected from the =
system.
I have a working example that shows that I have worked out much the code =
and encryption for this solution at: =
http://www.greentv.com/cgi-bin/cgiwrap/greentv/CRI/_nttc.cgi?page=3Dopene=
r&user_id=3D
When you roll over the links you can see they are encrypted. Its just a =
simple demonstration of what can be done with my CipherText algorithm =
which has a patent pending on an innovation. The algorithm allows =
encrypted content to be %100 HTTP text/html protocol compatible reducing =
the overhead needed for conversion when using other algorithms. =
CipherText uses a double symmetric cipher where the key length can be =
masked using a set of tiered keys so that the set of applied cipher =
combinations can easily exceed message length. The make it highly immune =
to key pair attacks and frequency analysis.
You can contract me to work on the scheme with you, meeting your =
client's demands and actually licensing the CipherText algorithm.
Regards,
Charles Prichard
www.greentv.com
<[EMAIL PROTECTED]> wrote in message =
news:8ditc3$scl$[EMAIL PROTECTED]...
> I'm going to be working on developing a client/server application pair
> this summer in which the client will communicate with the server using
> a closed, proprietary protocol. I need some mechanism to insure that
> only _my_ client talks to the server. In other words, although the
> protocol will not be documented, I want to guard against the
> possibility that someone will reverse engineer the protocol using a
> packet sniffer and write an alternative client that emulates my real
> client and talks to the server. This application will be used inside =
a
> large corporate intranet system, and, based on certain 'organizational
> politics' type issues, it is extremely likely that someone will try to
> create a rogue/imposter client. My job is to make sure that the =
person
> who tries this does not succeed. :-)
>=20
> This seems like the kind of problem that others may have faced before,
> and I would like to know how this is generally dealt with. Obviously,
> there is going to have to be some kind of authentification handshake =
in
> the protocol in which my client identifies itself as being the real
> McCoy before the server starts talking. I assume the best way to do
> this is to use RSA encryption, i.e., the client transmits some data
> that is encrypted with a private key and the server decrypts it with a
> public key. However, I'm concerned about two things. First, if I
> distribute an application with a key, won't it be rather easy for a
> person with malicious intentions to get ahold of the key and then =
spoof
> being the real client? Should I encrypt the key? Also, secondly, =
what
> data should I encrypt and send? If I just send an encrypted version =
of
> the same message each time (e.g, the word "HELLO"), it'll be pretty
> easy to fake out the server because the crypt text will always be the
> same. I thought about encrypting the current time (the requirements
> for the project assume that the client machines are all set to the
> correct time +/- 10 minutes) and sending that, but if anyone ever
> figured out that that was what the crypt text was, it might be =
possible
> to crack the key pair. (i.e., knowing that the crypt text was always
> an encrypted version of the current time would give a cracker a very
> large set of plain text/crypt text pairs, and this might make it easy
> to determine the value of the key).
>=20
> Does anyone have any suggestions? I feel like I must be missing an
> obvious solution here...
>=20
>=20
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Scary Possibility: Ticklish Chips
Date: Tue, 09 May 2000 13:41:38 GMT
In article <8f8g1l$2cn$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Rubin) wrote:
> That's called differential fault analysis and it's a serious problem
> for smart card manufacturers. Several papers have been written about
it.
>
> For modules with more complicated packaging than smart cards, it's
easier
> to protect against, though I don't think any type of hardware tamper
> resistance can stop a really determined and rich attacker.
I believe Bruce Schneier and his Counterpane Labs claim to be able to
break most existing smart cards in their lab. They're not a particularly
large company, so apparently you don't need Megabucks to be able to do
it.
-Erik Runeson
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,talk.politics.crypto,alt.journalism.print,alt.journalism.newspapers
Subject: Re: new Echelon article
Reply-To: [EMAIL PROTECTED]
Date: Tue, 09 May 2000 13:28:34 GMT
On Mon, 08 May 2000 20:14:09 GMT, [EMAIL PROTECTED] (Jos Horikx) wrote:
>Some new evidence entered the press. See:
>http://msnbc.com/news/403435.asp?cp1=1
>
>The beginning of the article:
>
>--- quote ---
>
>NEW YORK, May 7 � Newly unearthed documents, mostly
>letters from the CIA to Congress, lay out evidence of an in-
>tensive intelligence effort to help U.S. corporations win con-
>tracts overseas. The documents, all published during the
>Clinton administration, appear to confirm reports that
>America�s electronic eavesdropping apparatus was involved
>in commercial espionage....
>
>--- unquote ---
>
>Kind regards,
>
>JH
I think the last two paragraphs of the article are quite revealing:
===============
In a general discussion of "specialized technical operations"
in a July 1995 report to Congress, the CIA�s National Counter
Intelligence Center noted "because they are so easily accessed and
intercepted, corporate telecommunications" particularly international
telecommunications "provide a highly vulnerable and lucrative source
for anyone interested in obtaining trade secrets or competitive
information."
The report continued: "Because of the increased usage of these
links for bulk computer transmission and electronic mail, intelligence
collectors find telecommunications intercepts cost-effective."
==============
Sounds like a sales document, a presentation in a corporate boardroom,
doesn't it? Market segment analysis and the "trade secret" and
"competitive intelligence" markets are described as "vulnerable,"
"easily accessed," "lucrative," and "cost effective." Key words
straight from MBA school.
Oh, yeah, that's right. Our intelligence agencies don't spy on "U.S.
persons" to help out campaign contributors and FOBs. I don't know what
the heck I'm thinking. [Do you think the #2 pencil has a dual use?
Watch your ass Eberhard-Faber!!!! They've got themselves a loophole!]
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Proving that you are who you say you are
Date: Tue, 09 May 2000 13:59:54 GMT
Page tage encryption prevents access to content with much less overhead.
There is no need to encrypt entire content, only the actual tag used for =
each request needs to be uniquely encrypted for each user. Both page =
names and tag-encryption keys should be sophisticated. The keys can be =
changed however with each user response making it almost impossible to =
submit a request based on a guess of what the encryption keys is and =
what a page tag could actually be.
I have your solution. Part of it is getting patented and censored from =
the public in this newsgroup.
-Charles Prichard
www.greentv.com
NFN NMI L. a.k.a. S.T.L. <[EMAIL PROTECTED]> wrote in message =
news:[EMAIL PROTECTED]...
> <<closed, proprietary protocol.>>
>=20
> Gaaach!
>=20
> << I need some mechanism to insure that only _my_ client talks to the =
server.>>
>=20
> So, only one computer can talk to the server. Okay.
>=20
> <<In other words, although the protocol will not be documented>>
>=20
> Yeck!
>=20
> <<I want to guard against the possibility that someone will reverse =
engineer
> the protocol using a packet sniffer and write an alternative client =
that
> emulates my real client and talks to the server.>>
>=20
> So, the Adversary gets to monitor all server-client communications, =
but does
> _not_ get physical access to the client, nor can he break into the =
client and
> look at its files?
>=20
> <<Obviously, there is going to have to be some kind of =
authentification
> handshake in the protocol in which my client identifies itself as =
being the
> real McCoy before the server starts talking.>>
>=20
> Yes.
>=20
> <<I assume the best way to do this is to use RSA encryption, i.e., the =
client
> transmits some data that is encrypted with a private key and the =
server
> decrypts it with a public key.>>
>=20
> Pro'lly something like that.
>=20
> << However, I'm concerned about two things. First, if I
> distribute an application with a key,>>
>=20
> Whoa, back the truck up. This is for multiple server-client pairs? =
Okay.
>=20
> <<won't it be rather easy for a person with malicious intentions to =
get ahold
> of the key and then spoof being the real client?>>
>=20
> Only if you do something stupid like have a hardcoded key embedded in =
every
> application.
>=20
> Here's what _I_ would do, and I know hardly anything about =
programming.
>=20
> First, document your work. Duh! Next, your Adversary _cannot_ get =
access,
> physical or otherwise, to the client in any way. If the Adversary =
gets a copy
> of its files or gets to mess with it, all is lost. Period. No amount =
of "copy
> protection" or semi-clever hiding tricks will stop a determined =
cracker. Now,
> it's okay if the communications between the server and the client are =
tapped
> and bugged. Now, you'll need to generate a big RSA keypair, actually =
two of
> them. Probably something like 4096 bits, if you want to be real nice =
and
> paranoid. Give the server the public client key, and give the client =
the
> public server key. Do this physically, because you don't want to =
bother with
> man-in-the-middle stuff. (Or have your users physically do this with =
diskettes
> between the systems. Don't hardcode the keys, obviously). All =
messages sent
> from the client to the server should be encrypted to the server and =
signed by
> the client, and vice versa. Only messages signed by the client will =
be noticed
> and acted upon by the server, and only messages signed by the server =
will be
> noticed and acted upon by the client. (Due to the nature of your =
one-to-one
> setup, there's no real difference between server and client except in =
what they
> do.) Just sign and encrypt everything.
>=20
> That ought to work.
>=20
>=20
> -*---*-------
> S.T. "andard Mode" L. ***137***
> STL's Wickedly Nifty Quotation Collection: http://quote.cjb.net
------------------------------
Date: Tue, 09 May 2000 10:25:57 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Why no civilian GPS anti-spoofing? / proposal
The problem of spoofing correction signals has appeared before, notably in the
context of the correction signals broadcast for harbor navigation. The
signals are emitted by fixed base stations that know their own location to
very high precision ;-), and thus can deduce the error in the GPS signal in
real time. They simply broadcast the differential using lower power (~10 mile
coverage) so that ships near coastlines can navigate around rocks safely.
The terrorist threat from disrupting marine navigation does not provide as
much human interest as an airliner filled with people, but it offers a greater
threat. An LNG tanker contains a serious amount of energy. Running one a
ground in a harbor like Boston or Baltimore would threaten a loss of life
several orders of magnitude larger than the airliner scenario.
Dave Ashley wrote:
> You bums on this newsgroup are really beginning to worry me. One of
> you is probably building a transmitter right now and waiting for a zero-
> visibility day at the airport.
>
> Sick puppies!
>
> I'm worried.
>
> Dave.
>
> In article <8f7u5e$pdr$[EMAIL PROTECTED]>,
> zapzing <[EMAIL PROTECTED]> wrote:
> > In article <lOsR4.7372$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> > > Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> > > > Nobody said that. A few state-backed terrorists steering a
> > > > few jumbo commercial airliners way off course would certainly
> > > > be sufficient to terrorize the public.
> > >
> > > I think my problem with the whole scenario is two-fold. First, I'm
> > > basically as anti-gps as you can get. Having firsthand experience
> > > using it, I find it of very limited use as an _aid to
> > > navigation_. That's not to say it's a bad idea, or a waste of money,
> > > just that it's primarily useful for doublechecking your current
> > > location.
> >
> > But it could be better.
> >
> > >
> > > Second, it just seems obvious to me that a state sponsored terrorist
> > > would have many cheaper/easier ways to terrorise air traffic than
> > > this.
> > >
> >
> > Easier, perhaps, but cheaper? all they would need is
> > a transmitter.
> >
> > > When you talk about sending planes off course though, the thought
> > > occours to me that while causing planes to collide is farfetched, it
> > > may be somewhat easier to keep one lost over the ocean long enough
> to
> > > run out of fuel, or some other navigational shenanegin.
> >
> > Such as causing a plane to fly into a mountainside.
> > Yikes. We certainly don't want that to happen.
> > Why won't the fedgov let us have the anti-spoofing
> > signals to prevent such a catastrophie?
> > I think they *like* it when catastrophies happen,
> > so they can blame it on terrorists and then grab more
> > power from a terrified public.
> > >
> > > > The fact is, our technological infrastructure is exceedingly
> > > > fragile, a fact that has many people concerned (and occasionally
> > > > somebody actually working on the problem). The more one puts
> > > > his eggs all in one basket, especially a fragile one, the more
> > > > likely a catastrophe will occur.
> > >
> > > Well, as I said above, you should _not_ be putting your eggs all in
> > > the gps basket. Given that the navigator should still be navigating
> by
> > > hand, large deviations from the GPS fix will be obvious. The
> challenge
> > > then is to figure out which location is correct. Anywhere inside
> most
> > > nations air space this should be trivial, over blue water it's
> > > probably slightly more problematical.
> > >
> > > > The sad thing is that GPS is a nearly ideal application for
> > > > public-key cryptography (everybody could decode, but only the
> > > > system itself could encode), which would have solved the
> > > > spoofing problem.
> > >
> > > I don't know, my experience with gps is limited to little black
> boxes
> > > that I plugged into other little boxes. ;) I would think though,
> that
> > > there would always be at least an impractical spoofing
> > > attack. Assuming somehow the system sent a signal that everyone
> could
> > > decode, which only it could generate. Then, if I wanted you to think
> > > you were at point B rather than point A, why couldn't I go to B and
> > > transmit the signal to you? Assuming the points were close enough
> that
> > > you didn't notice the time difference, your equipment would assume
> it
> > > was at B.
> > >
> >
> > simply include the current time in the signature,
> > and put clocks in the little black boxes.
> >
> > > --
> > > Matt Gauthier <[EMAIL PROTECTED]>
> > >
> >
> > --
> > Do as thou thinkest best.
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
>
> --
> -------------------------------------------------
> Dave Ashley, [EMAIL PROTECTED]
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
Date: Tue, 09 May 2000 10:46:56 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Any good attorneys?
Joaquim Southby wrote:
> In article <[EMAIL PROTECTED]> Trevor L. Jackson,
> [EMAIL PROTECTED] writes:
<snip>
> >> >Thus I believe your conclusion is flawed by the application of copyright
> >> >principles to the domain of patents. You may want to reread the portion of my
> >> >post that you snipped.
> >> >
> >> You are right. I shouldn't have used illegal downloads of copyrighted
> >> software as an example. The portion of your post you refer to is not
> >> relevant to my argument since I don't believe the end user is liable or
> >> responsible for a patent violation in a product they received from
> >> someone else. I'll have to run that one by the patent lawyers at my
> >> company next week for their opinion.
> >
> >I'll be interested in the opinion. In the past users have been enjoined from using
> >patented technology even though they were not the "manufacturer" or "distributor".
> >In the absence of this consideration, would-be violators could set up dummy
> >companies, manufacture the rip-off products for themselves, and be immune to the
> >consequences of enforcement of the patent upon the dummy. Consider, for example,
> >patents that are never licensed, but used to distinguish a company from its
> >competitors.
> >
> I talked to a friend of mine who is an ex-programmer/present patent
> attorney. She told me that she doesn't know a thing about the subject
> since their job is to develop the patents, not defend them. She referred
> me to the corporate attorneys and helped me don my armor.
>
> The trip to corporate attorney land was an experience. They are only a
> stone's throw from the executive offices and miles away from any open
> door policy. I went in, gave my name, and asked our basic questions
> about liability. They wanted to know why I was asking. I told them it
> was to augment a discussion on Usenet. They wanted to know what Usenet
> was. When I told them, they huddled together for some moments and then
> began a strange dance. Almost too late, I realized it was a decoy to
> draw my attention away from the two circling to cut me off from the door.
> I bullrushed them, knocking one to the floor, and managed to escape with
> only two Super StickOn Subpoenas (tm) plastered to my back. Fortunately,
> I hadn't given my real name (sorry, Trevor, but you're being sued for
> sexual harassment and charged with mopery).
Isn't that the blanket indictment they use in Yemen against people the Gov't doesn't
like? I suppose I should be honored.
>
>
> Seriously, once I had asked the questions, the guy I talked to went into
> another office, came back with his boss and they asked me about Usenet,
> etc. They conferred for a while and then told me they could not comment.
> Hmmm...sounds like there's a company that's working on a similar
> problem, doesn't it? Sorry I couldn't get any valid opinions. I tried
> some other lawyerly friends and even a judge, but none of them were any
> help.
>
> >> In any case, you seemed to be taking issue with my usage of the term
> >> "distribution" even though I was trying to agree with you in the first
> >> place that there could be dispute about that term.
> >
> >Mostly because it is hard to analyze products as slippery as freeware. Since
>there's
> >no money involves the author has no knowledge of the users, and may not have any
>form
> >of contact with the majority of the users because there can be an arbitrarily large
> >number of intermediaries who copy the software (with the blanket permission of the
> >author), and who might be better characterized as "the distributor".
> >
> In the case under discussion, though, wouldn't the originator of the
> tainted software still be culpable, no matter what the chain of
> distribution looked like?
I do not believe so. Until the product crossed the jurisdictional boundary, there was
no
infringement. The originator had no part in the infringing act, so cannot be culpable.
Do we indict the miner who exhumed the lump of lead ore from which a murderous bullet
was
fashioned?
>
>
> >> I was trying to
> >> illustrate that point with my reference to copyrighted software on a
> >> Hotline server. Let's change that to "software containing patented
> >> algorithms". Do you believe that anyone should be able to use a patented
> >> algorithm in a piece of software and either sell it, give it away, or
> >> make it available for download without compensating the holder of the
> >> patent?
> >
> >AFAIK, compensation to the holder of the patent is not relevant. Permission is
> >relevant. (Of course permission may require compensation ;-)
> >
> >Your question does not address the issue of multiple patent jurisdictions. Within a
> >single jurisdiction, one cannot legally sell, give away, or make available for
> >download any patented product/technology/algorithm. Nor can one use it without the
> >patent holder's permission.
> >
> >Can anyone not in the jurisdiction of a patent sell a piece of software that would
> >infringe if sold within the patent jurisdiction? Yes. Can one give it away? Yes.
> >Can one make it available for the download? Yes. The third point is the only
>sticky
> >one. I reached the affirmative conclusion by reasoning that forbidding the
> >downloading of the software would prohibit legitimate activity, which rules out the
> >blanket prohibition on downloading software. In support of this we can observe that
> >the person who moves the software from outside the patent jurisdiction to within the
> >patent jurisdiction is the one responsible for the infringement. That action,
> >"infringing distribution" if you will, is the action that is prohibited by the
> >existence of the patent.
> >
> >A logical extension of this line of reasoning leads to the conclusion that while one
> >cannot sell or give away patented technology within the patent jurisdiction, one
> >could make it available for download. If we presume that the software is offered
> >with the proviso that users within the jurisdiction would have to seek the
>permission
> >of the patent holder then in theory there is no infringement. I suspect this
> >conclusion is far out on thin ice.
> >
> I'm not sure logic and the US Patent Office are in sync yet on Internet
> technologies. Apparently RSA is taking the tack opposite to your
> conclusion by saying that Tom is at fault for making the software
> available within the patent jurisdiction.
It may be that Canada is within the domain of the RC5 protection. I'm uncertain of the
facts regarding the true situation, and the actual intent of RSA. The form of their
message, somewhat boilerplate, leaves their intent unrevealed. The standard protective
action is to demand withdrawl of an infringing product. It is not RSA's
responsibility to
point out to Tom how he can modify his product(s) to avoid infringement, and it would
be
counter to the RSA's interest for their lawyer to do so.
> I think this is the same
> problem that arises when taxing the Net -- where does the transaction
> occur? The software physically resides on a server in Canada, yet it is
> being advertised (via Web pages, in a loose sense of the word) to the US.
> If someone in the US downloads the software, where does the transaction
> take place?
There is no principle of equity that justifies the imposition of restrictions upon the
actions of persons not subject to (outside of) the jurisdiction of the imposing agency.
If the US really needs to inhibit the importation of infringing software it is up to
the
US to inspect all data transfers that cross the border. The history of Radio Free
Europe
is a fertile ground for researching this kind of conflict. Also the state laws against
pornography have not fared well when imposed upon web sites in other states.
However, in this case I believe the issues to be more mundane than those of the virtual
marketplace.
> We agree that the downloader, being within the patent
> jurisdiction, is liable for infringement no matter what, but is the
> provider of the software acting within that jurisdiction also? I think a
> case could be made for that.
How so? Is every web site subject to every jurisdiction? I don't think you can make a
reasoned case for implicating the source.
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Unbreakable Superencipherment Rounds
Date: Tue, 09 May 2000 14:36:53 GMT
With CipherText I can simply create a set of cipher combinations that =
exceed message length and mask the root key length.
A simple demonstration is at:
http://greentv.com/Java/CipherText_2.html
Where it uses only one tiered key based on the root (but of different =
length.)
And at:=20
http://www.greentv.com/cgi-bin/cgiwrap/greentv/CRI/_nttc.cgi?page=3Dopene=
r&user_id=3D
Where the algorithm is used for the simple task of page tag encryption.
CipherText offers practical encryption for the default HTTP 7-bit =
transfer protocol and can be licensed on a per site basis. Page tag =
encryption is a new user authentication solution that I have =
demonstrated but not seen anywhere. It offers advantages in cost to =
implement and makes user impersonation impossible for more than one =
instance in a given thread. If two uses contrive to contend for the same =
identity, one loses it and is ejected from the system.
I can be contracted to develop an authentication solution for your =
clients in Perl or Java and to license the CipherTex algorithm on a per =
site basis.
-Charles Prichard
www.greentv.com
Runu Knips <[EMAIL PROTECTED]> wrote in message =
news:[EMAIL PROTECTED]...
> UBCHI2 wrote:
> > There is a way to encrypt communications that make them impregnable =
to
> > cryptanalysts theoretically. Can the following sequence be =
implemented?
> >=20
> > 1) 1 round RC6
> > 2) 1 round TwoFish
> > 3) 1 round Serpent
> > 4) 1 round Mars
> > 5) 1 round Rijndael
> >=20
> > Then top off the rounds with a final pass with 3DES. Then I do it =
again by
> > randomizing the number of rounds of each and the order of the
> > superencipherments using SIGABA irregular movement of the =
algorithms.
>=20
> Wrong. You create a new cipher which is
>=20
> (a) very complex and therefore hard to analyse
> (b) very slow
>=20
> The only good property of it is, that some steps of it are 3DES. If
> you use a different key for 3DES and the other rounds, the resulting
> cipher shouldn't be less secure than 3DES.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Prime Generation in C,C++ or Java
Date: Tue, 09 May 2000 14:25:23 GMT
In article <[EMAIL PROTECTED]>,
Eric Hambuch <[EMAIL PROTECTED]> wrote:
> Lewis-Oakes wrote:
> >
> > Is there a quick and relatively short algorithm in any of these
languages
> > for generating primes? The primes do not have to be huge, to the
order of 5
> > to ten digits in decimal.
> > Thanks
> > Justin Lewis-Oakes
>
> Create a random number and then test if it is prime. This can be done
by
> a probabilistic algorithm
> (see Handbook of Applied Cryptography,
Hopeless.
The poster said he wanted "5 to 10 digit primes". One does not
need a probabilistic method. All of the pseudoprimes less than
25 * 10^9 with respect to bases 2,3,5,7 have been identified.
This gives a fast deterministic test. Albeit for 5 digits, trial
division or table lookup will be faster
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
