Posted
by
chrisd
on Tuesday August 06, 2002 @11:08PM
from the cats-and-dogs-living-together dept.

zorba1 writes "Manindra Agrawal et. al. of the Indian Institute of Technology Kanpur CS department have released a most interesting paper today. It presents an algorithm that determines whether a number is prime or not in polynomial time. While I haven't gone through the presentation in detail, it looks like a promising, albeit non-optimized, solution for the famous PRIMES in P problem."

pdflatex doesn't always work - try it with prosper slides for instance - and the times package is obsolete.

Either use package txfonts or maybe pxfonts (uses only PostScript fonts), or mathptmx (keeps Computer Modern fonts for math, but this doesn't always work), or install the vectorial T1 version of the ECM fonts and make sure those are used instead of the bitmap ones.

yeah, you would have thought that Adobe, the people tht brought us Postscript could write half-decent font rendering code, but no...

On the MaxOSX it looks great (I'm guessing they use the Mac's native font rendering), but on my XP box it looks like something from the mid 80's compared to the cleartype that everything else is done with.

>I'm not sure why it removes comparison symbols when set to plain text...

Slashdot removes left angle brackets in an attempt to stop abuse. Since it still lets raw right angle brackets through for old style quoting (which I prefer), the left ones have to go on unverified tags.

To display a left angle bracket despite that you'll need to type its ISO code, which renders the bracket unusable for tags (which is a good thing).

ie: < is entered with this: &lt;

Just something to note down FFR. Oh, and &nbsp; can be handy if you want to try to slip through some important, on-topic simple tables or ascii art. Sometimes. But not lately.

You have to escape < with &lt;, because otherwise the parser wouldn't be able to tell when an element tag was beginning or you meant less than. > isn't required to be escaped for this reason, because it is clear whether it is closing a tag or not. You also have to escape the ampersand, because otherwise the parser would have to scan ahead to know if you were specifying an entity like &nbsp; or you just meant & and whatever.

The technical definition is kinda long and complex, but in essence it's like this. Given a problem of some size n, a polynomial time algorithm is guaranteed to give a solution in time proportional to a polynomial of n. If a polynomial-time algorithm exists that solves a problem, then the problem is said to be in polynomial time.

To give an example, say you've got a list of numbers and you want to know the sum. That can be done in linear time - ie, the time taken is proportional to the length of the list of numbers. The size of the problem (n) is defined by the length of the list and the time taken (T) is as follows: T = c1 * n + c0, where c1 and c0 are some fixed constants. The formula for T is a polynomial, and so the problem "LIST-SUM" is in polynomial time. It would still be in polynomial time if the formula for T was a polynomial with n^2, n^3, n^50 terms in it, or even terms like n^1.5 (because as n grows very large an n^1.5 term will always be smaller than an n^2 term).

Showing you an example of something outside polynomial time is a little more difficult, but some standard examples are SAT (the satisfiability problem) or the travelling-salesman problem, which you can read about in any book on the subject.

Well, there are things that are definitely outside polynomial time - the halting problem for instance, which is undecidable no matter how much time you have. There are also problems that provably take exponential time even on a nondeterministic Turing machine. However, you are quite correct that TSP or SAT just might be in P (but it's pretty damn unlikely).

I was trying to keep it simple because the original poster said that he didn't know anything about theoretical CS.

an NP-complete (NP=non-polynomial) problem is one that can be solved, but takes about 8*age_of_universe time to solve. To get around this, approximation algorithms are used, but these can never give a 100% guarantee of finding the correct solution, nor may provide the same solution if it were to execute on the same data twice.

a polynomial-time problem is one that can be solved within our lifetimes, guarantee 100% accuracy, and can always generate the same solution for the same data.

there's a LOT more to it. The book Intro to Algorithms has a good chapter on the topic of NP-completeness, which will explain the intricate and gory details.

ie, it can be completed by a nondeterministic machine in polynomial time. The main problem with NP algorithms is that there aren't any nondeterminisitic machines around. (A nondeterministic machine can attempt all paths to try to reach a conclusion at once whereas a deterministic machine can only try one at a time.)

Ignore the parent post, since it is wrong. The previous poster did a much better job of explaining the concept of polynomial time.

An NP-complete problem does not take 8 times the age of the universe to solve. This completely missed the point. Every P or NP problem can be expressed in terms of a variable "n", which represents the input size. There are many practical problems where the best-known P algorithm is slower than the best NP algorithm for typical values of n. However, computational theory tells us that as n increases, the P algorithm will eventually beat the NP one.

There is a remote island in the South Pacific called 'Polynosia' (not to be confused with 'Polynesia').

The island has a number of strange customs.

1) All the women on this island are called 'Polly' in reverence to the island's god, Polynose.

2) The men of the island are very philosphical (maybe because all the women are called Polly, so it gets very confusing). They spend most of their time poring over mathematical problems.

3) The island has strict laws on the use of technology. Telephones are not allowed, aircraft are not allowed to land there, in fact the only way to reach the island is by boat, nevertheless it is very popular with tourists.

4) It is considered offensive to Polynose for anyone who is not a Polynosian woman (a Polly) to prepare food. Since the island is popular with holiday makers though, all of the enterprising Polly's have opened small restaurants called 'Polly-meal-time'.

The men of the island, in order to discuss their mathematical musings, recently opened a cafe. To distinguish this from all the restaurants, they named it 'Polly-no-meal-time'.

The article reports that recently a boatload of mathematicians visited Polynose, and told the island's men how to check if a number is prime.

I am by no means a heavy duty math cruncher or cypherpunk, but how exactly is this going to affect number and factoring? I don't know of any advanced prime number search algorythms, but Sieve of Erothenes (did I get that right?) solved in NP time. (Each number is check is evenly divisible by an earlier prime, and if none found, add to list of primes, lather rinse repeat)If primes can be found in P time, finding the first 50 prime numbers would take the same time as finding the first 50 three hundred digit primes.

While that may not be thrilling at first, let's use the RCA contest for money as an example. We get a 1024 bit number containing 200 digits in decimal formm, which is the product of exactly two prime numbers. We know then that:1. We only need to find one prime to easily find the other.2. The digits in the factors can total no more than 200 digits. 3. One of the factors contains less than 100 digits.

Start at 10^100 and count down using this algorythm, and youll find it in P time instead of NP time. It'll still take forever, literally and figuratively, but wouldn't it take significantly less time than before?

Start at 10^100 and count down using this algorythm, and youll find it in P time instead of NP time. It'll still take forever, literally and figuratively, but wouldn't it take significantly less time than before?

Ah, no. First, note that a 2^1024-big number has more than 300 decimal digits, and so a 2^512-big number has more than 150. Then, even if primality testing took only 1 operation, we'd still need to perform something like 2^511 operations by your method. At 10^24 (one trillion trillion; unfathomably many) operations per second, this'd *still* stake 10^112 times longer than the estimated lifetime of the universe (1.5*10^10 yrs) to complete!

There are, however, faster ways of factorization than testing all the numbers in (1..sqrt(N)) to see if they are factors of N. They are not noted in (or relevant to) the paper mentioned by this article.

[nb: See other comments for why this is, in *practical* use, not such a big improvement on Miller-Rabin and other randomized methods which have been known for decades.]

Everyone: just because you start out by writing "I'm no mathematician, but..." doesn't means you can pull crap right out of your ass. Words mean things, and when you talk about math, words mean things exactly. Please don't misuse them.

It's the Sieve of Eratosthenes. A number n is of size log(n). This is a deterministic algorithm; why bring up NP? What is the time complexity of division? And here's a hint: you start with n-digit (n=100) numbers and present an algorithm that runs in time 10^n. This is in P?

Has anyone actually read the paper? The algorithm is outlined, with a complexity analysis. Don't forget, P-time doesn't mean usable.

For those of you wondering about the implications for cryptography, this does not imply that composite numbers can be factored in polynomial time. This algorithm is simply a primality test -- that is, it tells you whether or not a number has any proper divisors (in polynomial time), but it doesn't tell you what these divisors actually are. Determining whether a number is prime has always been considerably easier than finding the prime factorization.

In fact, for schemes like RSA -- where the key is the product of two large primes -- we already know that the number is composite, by definition, so a more efficient primality test doesn't give us any new information.

Key generation for algorithms like RSA already use numbers that are prime with a high probability. There are quick algorithms for that. But key generation algorithms currently don't run for several months to ensure for 100% that the factors are prime.

So perhaps this algorithm makes RSA, DSA, etc. even stronger because it will be easier to guarantee that the factors are prime instead of assuming it with 99,999999999999% probability.

From looking at the algo, I can't figure out what 'x' (or maybe it's a chi) is? Can someone help? I've looked it over, but couldn't find a definition of it. I'm also assuming that the 'if (r is prime)' line is a recursive call to itself? Also, how do we determine 'q' the 'largest prime factor of r-1' ? Another recursive call to get the factors? I must admit, I'm kind of lost by the algo, but it's still interesting.

no you dont need recursive call. as r is O(log(n)) so size of r is O(log log(n))) so if an exponential time algorithm is used for checking the primality of r, it'll be exp in log(log(n)) i.e. linear in log(n)

Same goes with q. as it's "small" you can afford an exponential algoritm.

From looking at the algo, I can't figure out what 'x' (or maybe it's a chi) is? Can someone help? I've looked it over, but couldn't find a definition of it. I'm also assuming that the 'if (r is prime)' line is a recursive call to itself? Also, how do we determine 'q' the 'largest prime factor of r-1' ? Another recursive call to get the factors? I must admit, I'm kind of lost by the algo, but it's still interesting.

OK, I'll address these points in order:

First off, 'x' doesn't matter. The loop at the bottom checks a congruence of two polynomials over two finite rings (if I'm reading it right, the first is generated by x^r-1 and the second by the input n). Simplistically, this amounts to grinding out the coefficients of the two polynomials and verifying that the difference of the polys equals zero, modulo the ring generator. The actual 'value of x' is never used.

Second, if you check the order statistic calculation, they're assuming worst-case on factoring 'r' (they apply order r^1/2 for that factorization). They then make an assumption that O(r^1/2) = O((log n)^3), or that O(r) = O((log n)^6), which seems rather suspect (as if they knew the answer ahead of time and plugged in a recursive value for it). Nevertheless, they do go to some length to show that such an r exists, and that it requires at most O((log n)^6) iterations of the first loop to find it.

As for 'q', I think again it is determined by brute-force factoring r-1. On the one hand, r is small; on the other hand, that doesn't mean a damn thing when it comes to dealing with order statistics, which I think is also a little suspect.

It's funny when I read the comments, and I see all kinds of stuff that reminds me of my Discrete Structures class (we did the P and NP stuff at the end)...

Makes me wonder what this means for computer theory, but if you think about it, polynomial time can still be slow for very large n with very big powers... although not as bad as an exponential with large n's (assuming you go out far enough that the exponential will grow faster then the polynomial)

I'm dead tired and will look at the paper in the morning. But right now I have a problem with step 6: "Let q be the largest prime factor of r-1" Won't getting q boost the thing back into power n complexity?

Here, quick math trick that will save people a bit of time. It's always easy to tell if a number is divisible by three, just add all the digits together, and if the result is divisible by three, then so is the original number. 909 = 9 + 0 + 9 = 18 (divisible by three). Oh, and you can take it a step further (18 = 1 + 8 = 9) if the result is still too long.

Therefore, this number showed up right away to me as being divisible by three, and quick division will show that 303 * 3 = 909.

However, [determining the factors of a number] is MUCH harder, and that is the one which will break cryptography as we know it.

Not all public-key cryptography is based on the difficulty of factoring numbers. There are a number of other one-way functions (such as elliptic curves) that are being used in cryptography. So I wouldn't say it'll break crypto "as we know it", but it would certainly freak some people out.

There have been comments as to the relation of this finding to the strength of modern prime depending crypto algorithms. Based on my understanding won't this increase the stength of crypto not decrease it.

Prime based encryption schemes (RSA,etc) are based on the complexity of factoring large numbers into primes, not the the ability to determine if a number is prime or not.

Incidently, many implementiotions make use of pseudo-primes, as the ability to validate primeness is (or was) cumbersome, and not actual primes. This should give implementations the ability to ensure key pair values are actual primes which would strengthen the resulting encryption.

We already have probabilistic algorithms that can tell whether a number is prime or not in polynomial time to any degree of certainty you wish.

All this would mean is that now instead of verifying that a number is prime with a (1-10^-10) level certainty in polynomial time, it could now be done with certainty, so there would be no revolution in cryptology, as some other posters suggest.

The famous result by Miller 1976 (and indepdently rediscovered(?) by Rabin 1980) already
did that. The only difference is that their algorithm was in RP (randomized polynomial). Namely, if the algorithm says it is prime it might be wrong (with probablity half, say), and if it says that the number is not prime, then it is not prime for sure.

Now, if you have a number n, you run this algorithm, say 20*log(n) times. If the algorithm
says it is prime on all executions that it is prime, you know damn sure it is. If it says it isn't, you are sure it isn't. There is a rediclously tiny probablity that if the algorithm claims that it is prime in all executions, that it is still not prime. This probablity is so small, that it can be essentially ignored. Now, random bits are cheap nowadays, so this is quite satisfactory. This is in fact the algorithm that turned the RSA crypto system into a practical and useful algorithm, because suddently finding primes became easy.

To break RSA, and become really famous, one has to come up with a polynomial time algorithm for factoring. It might even be that RSA can be broken without factoring, but this is still an open question (I think).

Ahh, and BTW. Polynomial time means polynomial time in the size of the input. So if the number is n, the size of the input is O(log(n)), and the running time needs to be O( (log(n))^(O(1)) ).

Does anybody know what happens to RSA if in fact one of the "prime" numbers is not prime? My guess is that this does not make it suddenly easy to break, or make it fail to encode (because either of those would imply a fast way to determine if a number is prime by seeing if it works in RSA). I would guess that a tiny fraction of messages would decode to garbage rather than to the desired text, but does anybody know for sure?

I probably really shouldn't be replying, because it's been a while since I read how it works, but I can copy the algorithm and tell you where I think it would break (if at all). Please correct me where I'm wrong.

So when p or q are not prime, phi(n) != (p - 1)(q - 1), so when you calculate d, you'll get something that doesn't negate the encrypting process (because its not a multiplicative inverse mod the real phi(n)), so you'll probably get junk when you decipher.

I don't really feel like doing a detailed analysis of the algorithm, but I imagine that this isn't used as a primality test because it's running time probably isn't polynomial time.

(Note: phi(n) is the number of primes less than n (Euler's totient function, I believe). phi(p) = p - 1 for prime p, and phi(pq) = phi(p)phi(q) for p relatively prime to q (note, this step breaks if p or q aren't prime))

A slight error: phi(n) is the number of positive integers less than n, which are relatively prime to n (ie. gcd(n,x)=1). Therefore, if p is a prime, it is also relatively prime to all smaller integers, so phi(p)=p-1.

The function that tells the number of primes smaller than n is pi(n), the prime counting function.

All primes above some low number of digits are pseudo-primes. Pseudo-primes aren't proven prime by attempting to factor all numbers smaller than it, but are proven by a number of tests that seem to indicate that the number is prime.

For testing why things break because you can factor a supposedly prime number, an even number will work as well as any other and its sure speeds up the factoring if you have to do it by hand.

Rabin's test says that if there is no witness below 2ln^2(n), then thenumber is certainly prime. The repeated-by-a-fixed-small-number PRP-test MR test is still acompositeness test, or a Probable Primality test, and does not give acertain answer.

Yeah, in fact someone told me about a determinastic polynomial algorithm almost a year ago. Maybe he was a reviewer for this paper, I dunno. But I assume someone more knowledgable will pipe up on this eventually. What I know is that there are some known composites that look like primes to the Miller and Rabin algorithms, and they can wreak havock to encryption. I think there is a test for these, but there may be more of em out there. Carmichel is the name that pops in my head, but I'm probably wrong.

In anycase, for cryptography you would probably run the randomized algorithm on a bunch a numbers until you found a number to be a prime with high probability, then you would run this to verify that it is a prime with higher certainty. The certainty sorta depends on the length of the proof for this algorithm. Since for a sufficiently complex proof there is a non-zero probability that the proof is not correct, and the probabilistic algorithms often have simple proofs that we may be more certain of.

He never said log2(n). He said log(n) without a base. O() measures what happens when n gets arbitrarily large and the statements are true for ANY fixed base. That's why no base it given, it is irrelevant. The difference between log2(n) and log10(n) is a fixed factor of 3.3. The O() of a problem tells you weather it takes you microseconds or gigayears to solve it. There really isn't any meaningful difference between 1 microsecond and 3.3 microseconds, or between 1 gigayear and 3.3 gigayears.

And here's the kicker: Nothing prevents me from using a base equal to the number itself.

As I said, O() measures what happens when n gets arbitrarily large. If you are using an arbitrarily large base then what you've got is a quantum computer. This problem and the harder problem of actually finding the factors have already been proven solvable in polynomial time for quantum computers.

As far as practice, it's fairly irrelevant. Probabilistic primality testing can be done in constant time with bounded error.

The Miller-Rabin test [mit.edu] will tell you if a number is prime with at most 1/4 probability of error. That sounds ridiculous, but the catch is that you can iterate it using a random parameter. Do the test twice and your probability drops to 1/16. Do it fifteen times and your chances of being wrong are about one billionth.

If you're truly paranoid, do it 50 times. That'll bring the error rate of the algorithm magnitudes below the error rate of your hardware.

The Miller-Rabin test [mit.edu] will tell you if a number is prime with at most 1/4 probability of error. That sounds ridiculous, but the catch is that you can iterate it using a random parameter. Do the test twice and your probability drops to 1/16. Do it fifteen times and your chances of being wrong are about one billionth. If you're truly paranoid, do it 50 times. That'll bring the error rate of the algorithm magnitudes below the error rate of your hardware.

Just consider how fast it's on some of the better known commercial operating systems, because even that 1/4 error probability is magnitudes below the error rate of your platform

What nobody knows though is if error is good or bad. If Miller-Rabin says a number is prime, and you use it for an application that requires a prime number, the application will still work. At least that is true for all the applications I know of that require a prime number (Public Key Encryption), there are probably others.

I've speculated that the existance of non-primes that work is one of the things that makes public key encryption hard enough to be useful. I can't prove it though, and offer it only as an interesting (but likely wrong) point to consider.

So I'm already sensing the level of confusion rising as this is a very confusing topic. Here's a quick review. Note: I'm going to do this on a higher level and not start talking about Formal Languages as this is not the place to teach it.
So in loose terms, Problems that in P are easily solveable. For example, sorting is a problem in p. Proof: I can sort a set of n numbers in no worse than n^2 time using a bubble sort. (Yes - I know there's faster but this is an example). The bubble sort just compares every number to every other number. Assuming you didn't optimize the algorithm you'd compare each number to every other number and they'd be sorted in no worse than n*n = n^2 comparisons.
So what is NP? NP are problems that given a proposed solution we can verify that the solution is correct or not in polynomial time.
An example of this is factoring. (note: it is not known whether factoring is in P). Given current methods we know factoring a big number into its prime factors. But if I was to tell you that p=q*r you could very quickly multiply q*r and see if it is equal to p and "verify" my answer. Another way to think about it is you can try out one branch of computation in polynomial time.
So what is NP-complete? NP complete problems are is follows.
A problem is NP-Complete iff
1) The problem is in NP
2) A solution in polynomial time to this problem would yield a polynomial time solution to all other problems in NP. That is, no other problem in NP is harder than NP-Complete and if one NP-Complete problem is solveable in Polynomial time than all of NP is solveable in polynomail time, P=NP and you will win doctorates and a nobel prize, turing award and a million bucks from the clay institute for proving this.
Sigh - you are probally still confused..:)

We give a deterministic
O((log n)**12) time algorithm for testing whether a number is prime.

[Sorry, the Slashdot filter does not allow me to
superscript the 12.]

The algorithm takes O(log2(n)**12) time, where n
is number being factored. If we optimistically assume that this algorithm can test the primality
of a 16-bit number in one microsecond, then here is how long it would take to test time primality of some larger numbers.

2**12 times as long for a 32-bit number = 4096 microseconds = 4 milliseconds,

4**12 times as long for a 64-bit number = 16,777,216 microseconds = 16 seconds,

8**12 times as long for a 128-bit number =
68,719,476,736 microseconds = 68,719 seconds = 19 hours,

16**12 times as long for a 256-bit number =
281,474,976,710,656 microseconds = 9 years.

I don't know what a realistic base time for this
algorithm really would be, and I don't know
where the cross over point against existing exponential time deterministic primality testing
algorithms would be, but at least this provide a sense of how log2(n)**12 grows.

Hold your breath... the algorithm is log2(n)^12 where n represents the number to be tested, not the number of digits. If you denote the number of digits by m, that is, m = log2(n), you get a complexity of O(m^12). The algorithm is therefore polynomial in the number of digits, with a very large exponent of 12. This large exponent could easily hamper the practical use of the algorithm, as Adam correctly demonstrated. The upshot is: Adam is right, RelliK is wrong!

Note that this algorithm takes O((log n)^12). For this to actually be faster than, say, factoring n directly, and assuming a multiplicative factor of 1 in the order statistic, n has to be at least 3*10^22, or roughly 75 bits long. This algorithm is probably very ineffective at factoring small integers.

I wrote a paper back in 1990 about a prime number sieve that was basically an O(n^2) algorithm.It basically worked by finding out if numbers were composite, but the algorithm used could be "inverted" to tell you if a number was prime or not by telling you if it was composite or not.It was very well suited to parallel implementations, too.

For P, it has to be polynomial in the size of _the input_. The input size here is log(n) since it requires log(n) bits to represent n. log(n)^12 hence is polynomial (which i believe their algo guarantees), whereas sqrt(n) is not.

No. Polynomial time, as was said, is polynomial in terms of the input. Input b bits and n is (worst case) on the order of 2^b so now sqrt(n) is about sqrt(2^b)=2^(b/2) which is far worse than polynomial in b.

Assuming you meant "wouldn't call", division is definitely "considerable". Remember we are talking about large numbers. Try doing long division on paper for 35184535666823 divided by 4194319 (answer is 8388617) and you can see there is some work involved, even with these small numbers.

The paper method of long division is O(n^2) and it turns out it can be done more efficiently: As I understand it, you can do division in the steps required for multiplication. Therefore the number of operations required to divide two n digit numbers is bounded by the best multiplication which is O(n lg n lg lg n) (from Knuth Volume II).

This is about 57 for 10 digits and about 182 for 20 digits. You can see that doubling the number of digits here more than triples the required number of operations to compute this result!
Likewise 30 digits require about 6 times more operations. You can see that the "n times" grows faster than the number of digits. Thus, division gets slower and slower the more digits you have to divide.

ECPP is already polynomial time with theoretical exponent ~6. However, thebest ECPP implementation out there, Marcel Martin's 'Primo', seems to behaveas if it has exponent ~4.5-5.ECPP is non-deterministic though. But it looks like this one is too.

So this looks as if it may be worse than the state of the art.

I'll wait for Lenstra and Pomerance to say their piece though, before makingmy mind up.

Yeah... that step in key generation where you check whether a candidate key is prime or not will now be performed with 100% confidence instead of that annoying 99.999999999999999% confidence we used to have.

Of course, there's still a larger chance of a cosmic ray flipping a bit in the processor or memory then the math being wrong, anyway.;)

This may seem like a strange question, but isn't a non-prime that passes the 99.99999999999% check just as good as a prime in encryption? I mean, seriously, is anyone really going to notice it's not prime? Sure, they could accidently stumble on the 'wrong' factors while trying decode it, but, seriously, halving the time to decode your message isn't a huge mistake, considering we're talking on the order of centuries at least.;)

Consider a simple public key encryption algorithm based on the fact proved in any beginning number theory book that for primes p, q

a^x = a (mod pq) if x = 1 (mod m)

where m = (p - 1)(q - 1)

Now choose your favorite number f and use Euclidean algorithm to efficiently find a number g such that

fg = 1 (mod m)

You may have to try another value of f if the Euclidean algorithm terminated before reaching 1, but it won't take many guesses. Now publish the number f and mod m as your public key and keep g private.

Someone sends text t to you by sending t^f (mod m).Now you just raise that message to the power g and reduce mod m to recover the original text. (This follows immediately by combining the above statements).

Finally, I'll get to the point. This algorithm is simply busted if p and q are not prime because t^fg will not equal t mod m unless you are very lucky. In fact, if you want to add a bunch of nines to your percentage certainty, just encrypt and decrypt a sample message text and verify that it works.

but isn't a non-prime that passes the 99.99999999999% check just as good as a prime in encryption? I mean, seriously, is anyone really going to notice it's not prime? No, most messages will decode incorrectly.

So, if the key obviously doesn't work, then you can assume that the modulus isn't prime and try another.

In fact, following that argument through, you could have a test suite of various messages to encode. If they work, you can be reasonably sure the number is prime. Obviously, with this approach you'd need to be reasonably sure you had a prime, otherwise you'd waste a lot of time.

Disclaimer: I dropped out of Uni level Maths before I got to anything particularly hard, so most of this is over my head.

Thank you. I'm glad someone finally pointed out that we already have a classical (as opposed to quantum) probabilistic algorithm for determining primality. Every other fool on this board is running around wearing his/her tin hat and shouting about RSA being defunct. All this does is push primality testing from the BPP complexity class into the P complexity class. It is significant in the sense that it weakens the argument for BPP being larger than P.

Of course, we also have a polynomial-time algorithm for prime factorization (Shor's Algorithm). It's just that it requires a quantum computer, which is difficult to build. So far, the biggest number factored is 15... 1024 bit keys will be safe for a while yet. I believe it's 15 - 20 years until they're broken, if Moore's Law holds for quantum computers in terms of maximum number of qubits possible (so far, it roughly has, but then, we're only at about 7 qubits).

Hmm... you know, I've been thinking... if anyone actually saves some of those packets floating around on the 'net, it my be possible to decrypt ALL of them in that time frame. In other words, even if it's encrypted, be aware that it may not be secure for the remainder of your life, perhaps much, much less. I wonder if I'll have the same credit card numbers in 15 years. Alternatively, I wonder if anybody will think about this more than a year before it's possible.

Another interesting case where it's faster to wait for the hardware than to start chugging away with what we've got right now.

They could have easily taken over the infrastructure of a modernized computer-bent, encryption-shielded society such as the US or Japan.

Primality testing and factorization are not one and the same. It is possible to know that a number is not prime without knowing its factors. Breaking encryption requires factoring the product of two huge primes (it is already known that the number you're trying to factor is NOT prime, so Primes being in P is more or less useless by itself for this particular application), and factorization has yet to be shown to be in P.

Out of interest, will this finding have any impact on the effectiveness of present day cryptography?

Probably not. While it is possible that this research could lead to results in speeding up factoring, a faster algorithm for determining whether a number is prime is not going to compromise the security of RSA.

Your RSA key pair is derived from 2 large primes. The way we generate keys is to randomly test large random numbers to see if any of them are prime. Ergo, we must already have an efficient formula for determining if a number is prime or not.

FYI, the most commonly used algorithm is Euler's formula. Euler's formula doesn't actually tell you if a number is prime, but it will usually give a non-zero output if the number is not prime, so if you run it enough times with different inputs, you can be 99.99999% sure that a number is prime. However, a small percentage of numbers are "pseudoprimes" -- numbers that are not prime but which will also satisfy Euler's formula. Therefore, after you discover a candidate prime, you should use a different (slower) formula to double-check.

Since this is fairly common knowledge among geeks who use encryption, I'm somewhat surprised that so many people here jumped to the same conclusion you did.

google v. [common] To search the Web using the Google search engine,
`www.google.com'. Google is highly esteemed among hackers for its
significance ranking system, which is so uncannily effective that many
users consider it to have rendered other search engines effectively
irrelevant. The name `google' has additional flavor for hackers because
most know that it was copied from a mathematical term for ten to the
hundredth power, famously first uttered by a mathematician's infant
child.

---------

googol
n : a cardinal number represented as 1 followed by 100 zeros
(ten raised to the power of a hundred)

a Proof is not rigorus if it depends on unproven theorems. There are many examples if theories that were thought to be true and were later proved to be false.
This proof relies on nothing more than a little abastract algebra, some number theory and good ole plain algebra..

Indeed, primality has been known since the 80's to belong to the class RP (problems solvable in expected polynomial time by a randomised algorithm). It has never (in recent years) been suspected of being NP-complete. Most experts don't even think factoring is NP-complete.

Actually in RSA they don't need to be primes, because the property that RSArelies on also works with pseudo-primes (that's what makes thempsuedoprimes, the order-counting gives the same result as if it were prime). _However_, RSA using a pseudoprime is easier to factor using the factor-finding algorithms (but not using the composite-splitting algorithms).

It has no benefit to the GIMPS folk, or the GFN searchers (google for "GFNGallot"), because in those case P+/-1 is _completely_ factorable andtherefore a single positive PRP test, using Pocklington's theorem, or theLucas analogue thereof ( http://primepages.org/ ), proves absolutely theprimality of the candidate.