Factoring composite Mersenne numbers using Pollard Rho
 

First post here - sorry if this is either an obvious or mundane question.

The Pollard Rho factoring method is suppose to have a running time proportional to [TEX]n^{\frac{1}{4}}[/TEX], however if you're trying to factor a composite Mersenne number [TEX]M_{p}[/TEX] and you are using the same iterating function as the one used in the Lucas-Lehmer primality test (that is [TEX]x_{n+1} = x_{n}^{2} - 2[/TEX] over mod of [TEX]M_{p}[/TEX] with [TEX]x_0 = 4[/TEX]
), is it known to factor [TEX]M_{p}[/TEX] considerably faster ?

I've tested it on the first three composite Mersenne integers [TEX]2^{11} - 1, 2^{23} - 1[/TEX] and [TEX]2^{29} - 1[/TEX] and the above iterating function becomes periodic after [TEX]5,11[/TEX] and [TEX]13[/TEX] iterations (the first two return to the starting [TEX]x_0 = 4[/TEX].

………...…………………......….

(Note - Carl Pomerance suggests using an iterating function of [TEX]x_{n+1} = x_{n}^{2p} + a[/TEX] where [TEX]x_0[/TEX] and the constant [TEX]a[/TEX] can be arbitrarily chosen. I can see the logic here as well since [TEX]M_{p} \equiv 1 mod M_{p} [/TEX], however this is a different strategy all together it appears.)

Hello, welcome to the forum.

The pollard rho can be tweaked to work nicely for Fermat numbers.
The Funktion to generate the numbers has to be modified here.
With this modification it was possible to give one factor of F_8 = 2^(2^8) + 1
by choosing f(x) = x^(2^(8+2)) + 1 see :

[url]https://maths-people.anu.edu.au/~brent/pd/rpb061.pdf[/url]

I did not read the article but the same approach might also work for Mersenne numbers.

Brent has found factors of M227, M199 with it. [url]http://centaur.reading.ac.uk/4571/1/1987_H_Mersenne_Numbers.pdf[/url]

Thanks for the reference ThilaHarich….

Yeah the factorization of [TEX]F_{8}[/TEX] was the most successful application of the Pollard Rho method to date for sure. Interestingly Brent mentions that there could've been further speed-ups, however decided to keep things simple in his paper.

As you mentioned, he applied the iteration function [TEX]x_{n+1} = x_{n}^{2^{10}} + 1[/TEX] and the reason he did this is because for any Fermat number [TEX]F_{k}[/TEX], any prime divisor[TEX] p_{k} \mid F_{k} [/TEX] must satisfy [TEX]p_{k} \equiv 1 mod 2^{k+2}[/TEX]. Thus the above iterating function can only generate integers [TEX]x_{n}[/TEX] over a set that contains [TEX]\frac{p_{k} - 1}{2^{k+2}}[/TEX] elements. This drastically decreases the average numbers of iterations that will need to be performed before the sequence [TEX]{x_{i}[/TEX] starts to repeat itself.

I won't go into the specific details. They are based on probabilistic assumptions or heuristic arguments, however many textbooks like to use the Birthday Problem as an explanatory analogy: [url]https://en.wikipedia.org/wiki/Birthday_problem[/url]

Re - further speed-ups to the above

Brent was likely aware of this, however the iteration function he used could've been given another boost! He used the function [TEX]x_{n+1} = x_{n}^{2^{10}} + 1[/TEX] which would've required a total of 11 multiplications (the extra +1 bit I believe is due to a reduction modulo F_8).

However had Brent used the iterating function [TEX]x_{n+1} = x_{n}^{2^{11}} + 1[/TEX] instead, he would've only added one extra squaring operation cost, however because [TEX]2^{10} \mid 2^{11}[/TEX], the above function would've still been iterating over a set of at most [TEX]\frac{p_{k} -1}{2^{10}}[/TEX] integers and there is a 50% chance that it would've been iterating over [TEX]\frac{p_{k}-1}{2^{11}}[/TEX] integers if so happened that [TEX]p_{k} \equiv 1 mod 2^{11}[/TEX]. In the case of [TEX]F_{8}[/TEX] this happens to be true.

In general, if we let [TEX]s = lcm(1,2,3...k)[/TEX] for some relatively small integer [TEX]k[/TEX], if we are already aware that [TEX]p_{k} \equiv 1 mod m[/TEX] for some relatively large integer m, it actually makes sense to use the iterating function [TEX]x_{n+1} = x_{n}^{sm}+ 1 [/TEX].

This can be applied to Mersenne integers as well, since any prime factor [TEX]q \mid 2^{p} - 1[/TEX] must satisfy [TEX]q \equiv 1 mod (2p)[/TEX]. You could call it a combined [TEX]P - 1 / Pollard Rho[/TEX] factorization algorithm.

Anyway, this doesn't have anything to do with the idea of using [TEX]n_{n+1} = x_{n}^{2} - 2, x_0 = 4[/TEX] strategy to factor Mersenne integers, but its still interesting. I'll try to say something about factoring M227 and M199 using these methods in another post.

Would it be possible to combine Rho factoring with a LL test? If residues in a LL test start to repeat would that mean you have found a factor? How likely would it be to find a factor that hasn't been found by TF or P-1?

This assumes the overhead for the extra calculations would be paid for by the chance of finding a factor.

Chris

Experiments would have to be done but I suspect that it might always need more iterations for rho to find a factor than to test primality via LL. Plus you would have to store all the full iterations which would be nontrivial for the huge numbers we test nowadays. It would be great if someone could prove me wrong though. I suspect it possible to prove me right though. Who will accept this challenge?

I believe that using x-->x^2-2 in the rho method causes the cycle to be length O(p) instead of O(sqrt(p)).

For instance, for the prime factor 228479 of M71, x-->x^2-1 finds a cycle in 658 iterations, while x-->x^2-2 requires 7035 iterations.

[QUOTE=wpolly;511053]I believe that using x-->x^2-2 in the rho method causes the cycle to be length O(p) instead of O(sqrt(p)).
[/QUOTE]

That may be why Knuth says x^2-2 should be avoided.

My plan was to run rho for a suitable number of cycles, then switch to a normal LL test if we havn't found a factor. If it's worth doing any rho cycles though.

Chris

That is not feasible, you need to store ALL residues, and check at every iteration, because you don't know the period after which they repeat. If you know the period, then you know an order of some non-square, so you can find a factor. Of course, you may store only a part of each residue, or some CRC/hash of it, to be easy to check, but in that case, when you have a match you have to repeat the test and keep full residues to see if it is really a match.

Also, residues repeat after some order of the factors, and because factors are 2kp+1, it may be that this order is larger than p. For example, order of 3 in 2^11-1 is 88. If you know this, you get immediately the factor (89), but as you only make p-1 iterations (here 10), you will never find the fact that residues repeat. If you start a PRP test with base 3, the residues will start repeating after 88 iterations, and for LL test, they may repeat after 60.


Edit: @jshort: can you factor M727, or at least M523 with that "combined" method? If so, I would be interested in it... :)

[QUOTE]That is not feasible, you need to store ALL residues, and check at every iteration, because you don't know the period after which they repeat. If you know the period, then you know an order of some non-square, so you can find a factor. Of course, you may store only a part of each residue, or some CRC/hash of it, to be easy to check, but in that case, when you have a match you have to repeat the test and keep full residues to see if it is really a match. [/QUOTE]

Re - storing residues

You generally only need to store one residue. It's a "reference" point that we assume is already inside the periodic cycle for which we compare future residues with. If our assumption is wrong, then we abandon this residue and pick one further down in the sequence.

Another method which requires no storing and very easy to program is to simply define two sequences where one is simply a double iteration of the other. Here is a pari/gp example of this method:

rho(n) = { my(x=4, y=14);

while (gcd(y-x,n) == 1,

x = (x^2 -2) % n;

y = (y^2 - 2) % n; y = (y^2 - 2) % n;
);

gcd(y-x,n);
}

For arbitrary integers n, x^2 - 2, should be avoided because it doesn't form a Monte Carlo random walk over [TEX]\Z_p[/TEX]. For arbitrary n, you might want to use this algorithm

rho(n) = { my(x=2, y=5);

while (gcd(y-x,n) == 1,

x = (x^2 + 1) % n;

y = (y^2 + 1) % n; y = (y^2 - 2) % n;
);

gcd(y-x,n);
}

[QUOTE]I believe that using x-->x^2-2 in the rho method causes the cycle to be length O(p) instead of O(sqrt(p)).

For instance, for the prime factor 228479 of M71, x-->x^2-1 finds a cycle in 658 iterations, while x-->x^2-2 requires 7035 iterations. [/QUOTE]

Thanks for sharing. 228,479 is a factor of [TEX]2^{71} - 1[/TEX] and 7035 iterations is enormous.

Do you mind posting your code or describing the algorithm you used?

[QUOTE]Edit: @jshort: can you factor M727, or at least M523 with that "combined" method? If so, I would be interested in it... :)[/QUOTE]

Unless the least prime factors were relatively smooth, the "combined" method would fail miserably for numbers that size. Fyi --- the idea doesn't turn Pollard rho or P-1 into something fundamentally much better/faster. It also can't be generalized to Elliptic Curves in any clear way.

[QUOTE=jshort;511277]
Another method which requires no storing and very easy to program is to simply define two sequences where one is simply a double iteration of the other.[/QUOTE]

This is the approach which is applied in efficient implementation's of Pollard's Rho:

[url]https://en.wikipedia.org/wiki/Pollard%27s_rho_algorithm#Algorithm[/url]

[url]https://en.wikipedia.org/wiki/Cycle_detection#Floyd's_Tortoise_and_Hare[/url]