There's still time before 'need' is the correct word for it. A public factorization effort that will generate more than 4 billion relations would probably need both Bruce and Greg's resources combined, for extended periods of time. Modifying Msieve to handle more than that many relations is not difficult per se, but the assumption of 32-bit relation numbers is all over the postprocessing code and would have to be removed in stages. Then there's the matter of making sure it still works afterwards...

More troubling is removing the next bottlenecks in line: building on-disk clique removal, for one. Parallel duplicate and singleton removal would also be nice, in case the initial dataset has trouble fitting in 48GB or 64GB of memory.

In contrast, getting lasieve to spit out larger large primes might just be a matter of removing a single size check in the code; I just don't know. Tom did do a preliminary skim of the source and nothing looked obviously impossible about it.

[QUOTE=debrouxl;281866]RSA-210 and RSA-704 ? :smile:
...[/QUOTE]
I can tell you about the factors of RSA-704. Two 352-bit primes,
more-or-less. Any reason you'd be interested to know which primes?
-Bruce

[(2^351+epsilon1)*(2^351+epsilon2) is short of 2^703+epsilon3;
maybe one 352-bit and a 353-bit? Inquiring minds need to know?]

(By contrast, factoring a wanted Cunningham number with a known
ecm pre-test has some suspense. Three prime factors? A near-miss
for ecm ... & etc.)

They would have same number of digits, so a factor of 8 between them is not to be excluded. Theoretically it can also be 351 and 354 bits. So the search space is almost triple.

Modern standards for RSA keys require the factors of the modulus to have the exact same number of bits. If the modulus has p-bit primes, each prime must be larger than sqrt(2)*2^(p-1)

[QUOTE=bsquared;281851]I've thought of using daily recurring scheduled tasks for the 120 windows cores, but haven't implemented it yet. I'm sure there's a way to schedule jobs on linux too but I don't know the particulars.[/QUOTE]

Do you know you can scheduled it over the LAN?

For example:

schtasks.exe /Create /S <ip> /U <username> /P <password> /SC DAILY /ST <startime> /TN <name of task> /TR <file to run>

Use "schtasks /?" and "schtasks /Create /?" to see more.

[QUOTE=jasonp;281896]Modern standards for RSA keys require the factors of the modulus to have the exact same number of bits. If the modulus has p-bit primes, each prime must be larger than sqrt(2)*2^(p-1)[/QUOTE]
I was thinking epsilon1, epsilon2 around 100-bits; large enough so
that p*q would be safely way from snfs, small enough to keep the bit
count simple. Do we know whether RSA-704 meets modern standards?
Must be relatively ancient. With p1, p2 both larger than (sqrt(2)/2)*2^p
we'd get p1*p2 > .5*2^(2p) = 2^(2p-1) ... so 2p-1 = 703, p1 and p2
with 352-bits, p1 = 2^351 + sigma1, p2 = 2^351 + sigma2, both larger
than .707 decimal * .... 1.41 decimal, converts to 1.01101 binary; uhm
(1.011)*(2^351) = 1.011*10000.... that's 1+1/4+1/8, so
10011000, sigma's supposed to be big, like 2^351+2^349+2^348+ (0's)...
=p1 and 2^351+2^350+ (0's) = p2 and p1*p2 = 2^702.

Sounds like RSA-704 isn't modern? Suppose I could check RSA233. -Bruce

[QUOTE=jasonp;281896]Modern standards for RSA keys require the factors of the modulus to have the exact same number of bits. If the modulus has p-bit primes, each prime must be larger than sqrt(2)*2^(p-1)[/QUOTE]

Talking about RSA210 and RSA704, they are not "modern standards", and everything we know about their factors is the fact they have the same number of digits. From the past-factored RSA numbers we can see that the "same number of bits" rule was not exactly followed in all the cases. There are 3 or 4 exceptions, for example RSA120 has a ratio of 2.11759 between its factors (>2, so no way they have same number of bits!), same for RSA170 (2.02626) or just the former RSA200 (2.243724) and some of the other with the ratio under 2 also have different number of bits. In fact I did not compute, but for one of the "exceptions" above, it could be more then one bit difference. Like from 29 to 67, both have 2 digits, their ratio is about 2.2, but 29 has 5 bits, and 67 has 7 bits.

So, for RSA numbers (including 210 and 704) we can expect any ratio of their factors, between 1 and 10, so a 3-bit difference between their factors is NOT to be excluded. Just my tuppence.

Edit: in fact a difference of 4 bits must not be excluded too, as for example 1009 and 9973 are both primes, their ratio is smaller then 10, they both have 4 digits, but the first has 10 bits and the second has 14 bits.

Note that having the same number of digits is a condition stronger then the fact that the ratio is smaller than 10, this is important, otherwise other smaller pair could be found with the ratio also smaller then 10, but different number of digits, like 29 and 257, first having 5 bits and the second having 9. Also the primality is important, otherwise the smaller example could be 13 and 129 (4 bits, respective 8). In fact, 7 and 67 would suffice too, and by chance they are also primes, but they don't have the same number of digits.

RSA 210 will have two 105-digit factors.
RSA 704 will have two 352-bit factors.

This much we can be sure of.

EDIT:- Using these facts:

The factors of RSA 704 should be between 8070373681869514072734228812145027220094678854297782287717332620153464615011270601823360738857596970569828 and 2^352 (a ratio of 1.13675)

RSA 210 should have factors between 245246644900278211976517663573088018467026787678332759743414451715061600830038587216952208399332071549104 and 10^105-1 (a ratio of 4.0775)

I suggested RSA-210 or RSA-704, here and to Greg several weeks ago, because while the standards for choosing the size of RSA keys already strongly discourage the creation of RSA keys <= 1024 bits, public efforts such as MersenneForum / NFS@Home, using FLOSS tools, and making headlines by factoring RSA-210 or RSA-704, could help accelerate the existing 1024-bit RSA keys being phased out :smile:
Double bonus points for improving the FLOSS tools in the process, in the directions mentioned by jasonp. I'm not among those who have clues on the math and the implementation of these tools.

Phasing out 1024-bit RSA keys is a double-edged sword: it would help eliminating some certificates used for SSL/TLS, but it would eliminate one of the ways people trying to make permanent installs of third-party software, on the hardware they own, can achieve their goals. For instance, TI Nspire calculators, use 1024-bit RSA signing keys on 2007-2010 models, and have already switched to 2048-bit RSA signing keys on the 2011 models. It's not desirable that other manufacturers of devices which users should be able to control, follow suit...

Why GNFS?
 

Why does the next one need to be GNFS? Why not SNFS up in the kilobit range, where there are many candidates?

The only answer I can see at the moment is that it gives a chance to stress-test Janon's polynomial finding code.

Paul

[QUOTE=fivemack;281834]I'm slightly saddened how little external interest I had in the 197-digit GNFS sieving - maybe I over-egged the description of how difficult the sieving would be to the point that it put people off, and likely the other people with significant resources (I'm thinking of Serge and Ben) have more interesting things to do with them.[/QUOTE]I played no role for the second reason --- too many things to do with too few resources. That has been the cry of factorers for decades, if not longer.

Paul