On Saturday 21 September 2002 16:15, Daran wrote: > > > ... through 64 bits the algorithm runs much faster than it does for 65 > > bits > > > and above. The factor is around 1.6 rather than 2. > > Good point, and one which I didn't consider in my reply. But the ratio > must be different for the P4, which uses SSE2 code for factorisation over > 64 bits.
Pass, I haven't let my one & only P4 system do any TF! > > > According to undoc.txt:- "You can limit how far the program tries to factor > a number. This feature should not be used with the Primenet server.", > which implies that something bad will happen if you do. Umm. I guess there is a possibility that PrimeNet might get confused about whether an assignment is completed (as far as the system running it is going to go). > > > Suggestion: the TF savefile should be modified to contain an internal > > consistency check (say the MD5 checksum of the decimal expansion of the > > current factoring position) so that cheating by editing the savefile, > > causing > > > "jumping" past a large range of possible factors, would be made a great > > deal > > > more difficult. > > Easily cracked. Why not just encrypt it? True. But the problem with encryption is that it has to be decrypted - if the client knows how to do that (& it has to, if the save file is to be any use at all) then a cheat can dig out the code somehow. One thing that could be done is to write an extra "hidden" save file (or store a registry key) containing some value computed from the save file contents, so that if the save file was manually changed there would be a clash & the client would know something odd had happened. Another trick (which I actually used in a now-obsolete anti-tamper system) is to take the time the file is opened for writing (in unix seconds) & xor that into part of the file data. When checking the file, read the file creation date from the directory, xor into the data, if the file checksum fails increment the creation date & try again - at most 10 times, since the file creation date (stored in the directory) shouldn't disagree with the system clock read by your program just before it called the file open routine by very much. This works pretty well because few people will twig what you're doing (even if you document it!) & even fewer will manage to frig the checksum properly. The idea here is to make "successful cheating" not worth the effort. There's no way it's going to be possible to stamp it out altogether. Personally I'm more concerned about the possibility of cheating your way up the PrimeNet LL testing league table. The obvious way to do this is to start a test, stop manually after a minute or two, edit the iteration number to a few less than the exponent & restart ... lo & behold, you _could_ "complete" LL tests on _any_ exponent in about five minutes, even on a P90 system. The fact that the residuals would all be wrong is irrelevant since PrimeNet doesn't penalise bad results; in any case, you'd probably get away with it until DC started to catch up with you. An internal consistency check would make this a lot harder to do. MD5 is pretty good (though not perfect) as there is no "simple" way to fudge it; the compute effort involved in frigging a file to achieve a specified MD5 sum is several orders of magnitude greater than that required to LL test a 10 million digit exponent, so it's simply not worth trying. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
