If Prime95 did some computation on some number at some random iteration numbers and submitted the result of this side computation as part of the result, could you prove that the primality check was done all the way through?

For example, the server somehow tells Prime95 to begin with 7, raise it to the power of 3 and take the remainder of a division by 3,011 at iteration 102,598. Then, at iteration 2,300,147 you cube the result and divide by 3,011. And again at iteration 11,529,866. Etc, etc.

In short, random_X to the power of random_Y mod random_Z at random iterations N[SUB]1[/SUB], N[SUB]2[/SUB], ... , N[SUB]random_K[/SUB].

Come up with maybe a half dozen calculation templates with three to five random parameters. If the assignment was encrypted and packaged with a bunch of noise, would that be difficult enough to break?

[QUOTE=TheMawn;350411]If Prime95 did some computation on some number at some random iteration numbers and submitted the result of this side computation as part of the result, could you prove that the primality check was done all the way through?

For example, the server somehow tells Prime95 to begin with 7, raise it to the power of 3 and take the remainder of a division by 3,011 at iteration 102,598. Then, at iteration 2,300,147 you cube the result and divide by 3,011. And again at iteration 11,529,866. Etc, etc.

In short, random_X to the power of random_Y mod random_Z at random iterations N[SUB]1[/SUB], N[SUB]2[/SUB], ... , N[SUB]random_K[/SUB].

Come up with maybe a half dozen calculation templates with three to five random parameters. If the assignment was encrypted and packaged with a bunch of noise, would that be difficult enough to break?[/QUOTE]

Unfortunately no, because you could either falsify the result, or the server would have to do the whole LL test if you wanted to check it.

I think it's better if we just didn't allow the same person to do a double check as whoever did the first LL test?

Another thing to keep in mind with proposals that depend on machine specific IDs, we don't want to make it painful or impossible to move an LL test from one machine to another mid-test. I suspect we've all done that numerous times.

Mawn's idea of spot-checking might have some merit but is not foolproof. It also does not work for those doing manual testing.

Only accepting double-checks from different users is very difficult since it is trivial for one user (or team) to create multiple accounts.

Also note that it is even more trivial to falsify CUDALucas results.

[QUOTE=Prime95;350424]Also note that it is even more trivial to falsify CUDALucas results.[/QUOTE]

AFAIK, this is why CUDALucas cannot be used to double-check a CUDALucas result.

FWIW, I sincerely doubt that this issue overall is that great of a threat to GIMPS. Keep in mind three thoughts:

1. The real object of the game, and from where the real "fame and fortune" comes, is finding a new Mersenne prime. Kind of hard to falsify *that*. What is fraudulently running up a million GHz-days in composite results actually going to achieve a bent user? Money? No. Fame? Well, maybe on the GIMPS leaderboard, but that will also lead to questions and suspicion if one's behavior is strange enough. I'd say that vandalizing Wikipedia with random lewd pictures is going to "impress" one's school chums more than disrupting a search for prime numbers.

2. Suppose someone is so bent that they don't understand (1) and just enjoy submitting false composite results. One of two things will happen: there will be a very (read: suspiciously) quick (and identical!) rise in the rankings from two users, whose completions strangely happen to mirror each other; or, more improbably (what would be the point, after all, as it would preclude being a "credit whiz"), we would see a whole slew of new accounts, half of which would be reporting LLs, and the other half of which would be reporting the corresponding DCs.

3. It is always possible to check the rate and quantity of results versus a user's quoted computing power. For instance, if Mal Evolent is contributing 500 LLs per day to GIMPS, but only has a single Pentium registered, we might suspect something fishy is afoot. Or if Mal is registered only under "Manual Testing", we might want to scrutinize his results more closely, as it is highly unusual that a user would have the time or the ability to sneakernet enough computers to collect 500 LLs per day.

Bottom line: This is a niche project, somewhat far off the radar of pranksters and vandals. Obviously, fixing a security hole is worthwhile, but I sincerely do not fear that the issue has the urgency that some might make it out to have.

:goodposting:
+1.

[QUOTE=NBtarheel_33;350444]FWIW, I sincerely doubt that this issue overall is that great of a threat to GIMPS. Keep in mind three thoughts:[/QUOTE]
Mal Evolent's personal motivation is probably mindless vandalism. He or she probably acts alone without particular need of tangible reward or impressed reactions from peers. The person may also feel no particular need to turn in a [I]lot[/I] of false results which would make them stand out as you point out: just a handful here and there will be enough to give him the twisted satisfaction that he can succeed in submitting false data and get away with it.

Meanwhile, the bona fide contributors, including those with huge crunching power, are keen to be certain that M30402457 is the 43rd Mersenne Prime when that gets established during the coming period. The certain knowledge that Mal Evolent will not get away with submitting false DCs here and there will be important for these bona fide users' motivation and peace of mind.

[QUOTE=Batalov;350401]It will do nothing to this particular attack. (I am reluctant to say "my" attack.)

The attack goes as follows:
1. Set e.g. InterimFiles=250
2. Start the run, and pause and exit anywhere after iteration 500. You now have a legitimate savefile at iteration 500.
3. In C, write a program that simply opens the file, "rewinds" the iteration counter, adjusts hash dword, and write back:
[CODE]iteration counter += N-1500;
hash_dword += N-1500;[/CODE]
4. Put this savefile it in the prime95 folder, and start the program, wait for it to finish and report.

On another (this time, a linux) computer, do steps 1-4 again, totally independently, from total scratch. The savefile will be different, the shift will be different, but the RES64 will be the same. Voila, a double-checked trusted result and a N-1000-th savefile.

I am hesitant to suggest any solution, but something like [URL="http://en.wikipedia.org/wiki/Hash-based_message_authentication_code"]HMAC[/URL] should work. In fact, because Prime95 is linked to wwwlib as far as I remember its name (which includes libcrypto), you only need to do some library calls and establish some keys (one of them could be the workunit's AID, or the keys could be somehow derived from AID and ComputerGUID (see local.txt). While I was writing, I see that this is already a crosspost to Chris' message (I haven't read it yet fully).[/QUOTE]

sounds like a read only/non-editable savefile at the first InterimFiles might work then, what do you think ?

Filters
 

I have a friend who works at bank headoffice monitoring the usage of credit cards. Whenever someone uses his/her credit card in an unexpected way there is a secutrity alert at the bank and my friend checks in the way she can if there is any kind of abuse. For instance if the card is used in two different countries at the same time there is an alert. There are a whole bunch of complicated occasions that could trigger an alert.

So could it not be a good idea to scan the GIMPS results in a similar way? Lets say if the same user hands in a lot of DCs of his own LLs it could be good if somebody is alerted and maybe runs an extra DC or two at least for some of the results. Or if one users LLs are always followed by the same other user is always doing a DC it could be good maybe to check if the DC is sent maybe from the same IP and so forth.

My guess is that it would be much easier to enhance the integrity of the database in this way then adding some kind of extra functionality in the program itself.

There has been some discussion here about "trusted users". This way of monitoring would possibly result in a (very small) list of non-trusted users/IPs that could be good to keep an extra eye on.

M595999993
 

[QUOTE=aketilander;349615]I see that you have observed my LL of M595999993, with its severe error code.

Let me tell a little more about this run. My idea was to run a parallell LL and DC on different machines and compare the intermediary residues all the way to make sure that it was a clean run. This was successful until interation 120M or so when the second computer broke down.

Please note:
1. Early during the run I experimented a little with OC. Unfortunately prime95 restarted at reboot. I forgot to turn it off while experimenting. This accounts for a good part of the errors.

2. All intermediary residues though on the second machine did match the residues on the first, so many of the errors were corrected and proven not to have affected the run.

3. SUM(INPUTS) error checking has been turned on during the whole run and all errors (if I understand it rightly) were found by this error checking. When an error is found the program backtracks to the last save file. So you can say that the program makes sure that the found error is not fatal and continues the run. SUM(INPUTS) error checking does: "Selecting this option will run an extra error check on every iteration. This will slow down the primality test slightly." I don't know how good or bad this error checking is, but at least it found all errors up until iteration 120M since that part has been verifyed.

Since so many of the errors were found and corrected and all errors are of the same kind this gives me the gut feeling that this may have been a good run anyway. If I had run this LL with error checking turned off prime95 would have found no errors.

Here is the results.txt from the run. All intermediary files are saved.

[CODE] Sorry no text here since I was not allowed to write more then 10000 characters. I will see if I can send it later[/CODE][/QUOTE]

I noticed with great pleasure Tony, that you have starting double-checking [URL="http://mersenne.org/report_exponent/?exp_lo=595999993&exp_hi=10000&B1=Get+status"]M595999993[/URL]!!! I would be so happy if you will keep us posted concerning if the intermediary results match or not! I am very much looking forward to follow your DC. You will find my intermediary residues in the post quoted as an attachment.

M595999993
 

As you remember I did some initial DC. Here are the results from my DC as far as I did it:

[QUOTE=aketilander;320115]I cannot think of any reason why not publish the interim residues since you cannot start a calculation from only a residue, so I publish them here if someone would ever like to do a double-check:
[code]
[SIZE=3][FONT=Times New Roman]M345678877 interim We4 residue EC2374466B30E335 at iteration 120000002[/FONT][/SIZE]
[/code][/QUOTE]
Just to let you know that 120M iteration is passed (the 34% mark, or one third of the work) and it checks up.
(edit: if it would run continuously, the ETA would be ~39 days, but expect it like August or so, I "[URL="http://www.mersenne.org/report_exponent/default.php?exp_lo=345678877&exp_hi=&full=1"]legally assigned" on Apr 28[/URL], but only work it during the nights, this is a Black-Titan work, air cooled, and I have heat-troubles during the days, initial ETA was 59 days)