When will GIMPS's first prime...

[Christenson]

Originally Posted by Brian-E

Could saving intermediate residues potentially cause an issue with less certain integrity of double-checking? While the PrimeNet server could and should keep the intermediate residues non-accessible to general users, the very existence of the extra information might lead to questions about whether people were still somehow getting access to it and thereby fraudulently performing a double-check from a point somewhere during the LL test (like towards the end) instead of starting at the beginning.

I think we'd need a little bit of cryptographic help from P95 here...that is, a BLOCK is DC'd, not the whole exponent...and you'd have to pull whatever cryptographic trick off that P95 does now to ensure that you aren't just guessing at the residue.

[Brian-E]

Originally Posted by Christenson

I think we'd need a little bit of cryptographic help from P95 here...that is, a BLOCK is DC'd, not the whole exponent...and you'd have to pull whatever cryptographic trick off that P95 does now to ensure that you aren't just guessing at the residue.

Yes, the security can be achieved technically with already known techniques. And yes, this is already being done out of necessity for the final result as far as LL tests are concerned (last two hex digits of the residue not available before successful double check is completed). But the ICT world is littered with instances of security being breached, very often through human error in applying the security procedures. Extra information which needs to be kept secure implies extra risk.

[xilman]

Originally Posted by Brian-E

Extra information which needs to be kept secure implies extra risk.

True. It also implies extra inconvenience. TANSTAAFL.

However, a client could create a public key pair when it is initialised. The server registers the public key and uses it to verify all important communications from the client which, of course, must sign them with the private key. A residue is not sent en clair but, rather, concatenated with a nonce and the result signed; the result of which is encrypted to the server's public key. (Alternatively, theThe server verifies the signature and discards the nonce. The nonce is there to discourage replay attacks but this feature could be removed if such attacks are not thought to be important.


Paul

[Brain]

Originally Posted by NBtarheel_33

Yeah, I don't know what they are talking about either. Not sure why we would be doing tests on 3M exponents.

When I used the term "3M" I meant "FFT of length 3M" i.e. current LL test range.

[NBtarheel_33]

Originally Posted by Brian-E

Yes, the security can be achieved technically with already known techniques. And yes, this is already being done out of necessity for the final result as far as LL tests are concerned (last two hex digits of the residue not available before successful double check is completed). But the ICT world is littered with instances of security being breached, very often through human error in applying the security procedures. Extra information which needs to be kept secure implies extra risk.

Suppose that Cray joins GIMPS (a guy can dream, can't he?) and starts turning in 100x the daily LL tests we get now. Wouldn't this pose the same security risks that you're discussing here - basically, a higher volume of information that needs to be kept secure per time interval?

Keeping 100 LL tests secure, in theory, ought to be the same as keeping 100 partial residues secure.

On the other hand, of the million-plus LL tests and tens-of-millions of factoring assignments that GIMPS has produced over its lifespan, what percentage of these results have been shown to be patent fakes? Moreover, in nearly sixteen years of existence, how many security threats have been waged on GIMPS? How about SETI? How about Folding@Home?

What's more sexy: "Hey baby, I just brought down AT&T's entire network" or "Hey baby, I just screwed up a bunch of 20-million-digit numbers belonging to some math geeks"?

[aketilander]

There will be several advantages splitting the really big LL-assignments in smaller pieces.

1. Today a number of persons dedicate more then one core to do a large first time LL-assignment in a reasonable time. This is a much less efficient way of using the capacity. If we have intermediary files saved the DD-assignments could start with any part, so if you would like to speed up a DD-assignment then you dedicate different parts to different cores without the loss of capacity. Due to this the DD-wave may in the end catch up on the LL-wave bacause it will be much more efficient doing a DD then a First time-LL.

2. Errors will be a growing problem when the assignments grow. I fear that the error-rate when really large LL-assignments are concerned will be a really large problem. If we have a mismatch between the first time-LL and the DD, with intermediary files saved, we could continue from the last point having a match and we would not need to start another DD. Again we would save capacity.

3. Looking at the project as a whole, I find the number of interrupted assignments which never finish is quite substantial. If we had intermediary files backuped on the server we would again save capacity. Today the waste due to unfinished assingments ist quite substantial.

I think the security problems could be managed.

[Brian-E]

Originally Posted by NBtarheel_33

Suppose that Cray joins GIMPS (a guy can dream, can't he?) and starts turning in 100x the daily LL tests we get now. Wouldn't this pose the same security risks that you're discussing here - basically, a higher volume of information that needs to be kept secure per time interval?

Keeping 100 LL tests secure, in theory, ought to be the same as keeping 100 partial residues secure.

Well, aside from the fact that we are hardly likely to see such a sudden huge increase in the LL work being turned in, I would think that it is more sensible to consider the volume of information to be secured per GHz-day of work, or perhaps per tested exponent. This is largely because if the integrity of the LL double checks were to be thrown into question and an investigation were needed, then the quantity of work that would need to be investigated would be important, not the length of absolute time that had passed while the tests were being done.

On the other hand, of the million-plus LL tests and tens-of-millions of factoring assignments that GIMPS has produced over its lifespan, what percentage of these results have been shown to be patent fakes? Moreover, in nearly sixteen years of existence, how many security threats have been waged on GIMPS? How about SETI? How about Folding@Home?

No idea. But we've had strange, unexplained things happen. Such as small factors being found by P-1 which should have been found by the trial factoring which had supposedly already been done. (Maybe this was later explained by a bug found in the TF routines? Who remembers? Whatever, this sort of thing always throws up the possibility that someone has turned in results without carrying out the work.) And just a few months ago you may remember that someone here admitted to exploiting a bug which gave him huge amounts of credit on PrimeNet for turning in large factors apparently from P-1 but which were actually the product of two smaller factors found by TF. He said he did it to highlight the bug, but the credit he was getting was very nice too. So let's not rule out the possibility of fraud: it would only take one person to run riot for whatever reason to severely dent our confidence in the database of results.

What's more sexy: "Hey baby, I just brought down AT&T's entire network" or "Hey baby, I just screwed up a bunch of 20-million-digit numbers belonging to some math geeks"?

Depends what turns you on.

I admit I'm being a touch paranoid and a spoil-sport. Pouring cold water on good ideas is a hobby of mine and it makes me really popular too. As aketilander says, the security problems can be managed. Maybe in the way Paul outlines.

[Christenson]

I'd also suggest that a certain amount of diversity of workers should be required; that is, if I turn in the LL test, or part of the LL test, I should not be able to turn in the same part of the DC.

I don't have the same problem when finding factors, because these are so easily verified -- but the sort of thing Brian-E discusses should be checked into -- on a confidential basis -- because, if you have a systematic cheater, that is the only way to catch him or her. On the other hand, my factoring efforts had a dry spell lasting a month this summer...not clear if it was simply bad luck (e.g. TF'ing in well P-1'ed territory and P-1'ing in well TF'ed territory) or erros from the high temperatures, since when double-checks were run on found factors, they were invariably found.

Anyway, another factor found tonight, another DC that won't be needed.....but 43 that will still be needed...

[Dubslow]

Originally Posted by axn

Another data point: Today, M35 is at 274. That's a drop of 104 positions in 244 days. Linear projection gives me 2014 days to fall off top 5000 - that is 5.5 years! That means in practice, it'll be like 3-4 years!

http://primes.utm.edu/primes/lists/all.txt

It's now at 301, at 27pos/~50days ~ .5 pos/day --> ~25 years.
http://www.wolframalpha.com/input/?i...+days+to+years

Also, each of my P95 save files are about 6MB, which concurs with http://www.wolframalpha.com/input/?i...ion+bits+to+MB =~6.75MB for a 54M exponent. Or, at a bare minimum, a 332M exponent would have a ~45MB file size.

45MB*50,000 ~ 2.25 TB. That's 50,000 backup files of a 332M exponent. That costs a bit less than $100 at current HDD prices. We're all coming up with the idea that this is perfectly within our means. The only part I'd be worried about is bandwidth, because downloading a 45MB save file isn't trivial (yet).

EDIT: Whoops, seems I somehow missed there was a second page, along with its discussions. My points have all been brought up :P

[Mr. P-1]

Originally Posted by Brian-E

...we've had strange, unexplained things happen. Such as small factors being found by P-1 which should have been found by the trial factoring which had supposedly already been done. (Maybe this was later explained by a bug found in the TF routines? Who remembers?

I found one such, which did turn out to be the result of a bug. This does not prove that every such was the result of a bug.

[davieddy]

Originally Posted by Mr. P-1

This does not prove that every such was the result of a bug.

I would have said a "bug" of some type would invariably describe such an occurence.

David