Mersenne Digest Tuesday, March 13 2001 Volume 01 : Number 828 ---------------------------------------------------------------------- Date: Mon, 12 Mar 2001 05:58:57 -0000 From: "Daran" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Security of prime95 From: Mikus Grinbergs <[EMAIL PROTECTED]> Newsgroups: list.mers To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 12 March 2001 00:18 Subject: Re: Mersenne: Security of prime95 + electricity costs. > I believe it is the CLIENT that initiates all GIMPS communications. > In other words, there is __no__ daemon which is listening to random > incoming messages. I sincerely hope not. I was a bit concerned by this in the WHATSNEW file:- #New features in Version 19.0 of mprime #-------------------------------------- [...] #18) The server can now broadcast important messages to the mprime client. However I think (hope) this means that it 'broadcasts' messages to clients when they connect. > (Buffer overflow attacks are usually directed > at programs which accept messages from anywhere on the internet.) There are two exceptions to this. 1) email and news clients can be attacked by way of hostile content in the message body or (more likely) the headers. Obviously this does not apply here, and 2) any client could be attacked by the server to which it connects. Again, the situation is a little different for a GIMPS client, from, say, a browser in that we are only connecting to a single server, which presumably, we regard as trustworthy. However, the Primenet server DOES accept messages from anywhere on the Internet, and, if cracked and owned, would be in a perfect position then to attack its clients. > To make use of the GIMPS communication protocols, the attacker > might have to WAIT for the user's Prime95 program to initiate > contact, and would then have to SPOOF being the Primenet server. > In my opinion, there are easier pickings on the 'net for attacks. That's the third scenario, and I agree that it is rare. However I don't think you can assume that an attacker is looking for easy targets. One cracking scenario is that he gains access to one machine which is connected by an intranet to other, more secure boxes. If one of them is running a GIMPS client then there's a fairly good chance that many or all of the others will be too. That would present a very tempting target. Bear in mind that, unlike a browser, a GIMPS client runs continuously, unmonitored, and often communicates when there is no human operator there. > In my opinion it would be easier to spoof the "Manual Entry" > Primenet server, which uses a browser interface rather than the > "below-the-covers" interface of the Prime95 client. The client source code is available for anyone to inspect. [...] > 2. Attacks facilitated by being on-line in the first place - I agree that the proportion of users for whom communicating with Primenet accounts solely for a significant proportion of their connection time is vanishingly small. >mikus Daran G. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 12 Mar 2001 01:43:48 -0600 From: "Jeramy Ross" <[EMAIL PROTECTED]> Subject: Re: Mersenne: prime95 - v21 progress Brian J. Beesley wrote: > > I fail to see how reducing the check-in interval would have any > impact on the "problem". Those people who are checking in every 28 > days aren't running into the 60-day expiry deadline. For one, the reduced check in time would allow the closer watch of "suspect" users who download a exp., run the program for a few days and then ditch out on the project. While it is true that people may run the program for upwards of a month or so and then ditch. The idea of having them check in about every week AS A DEFAULT too keep tabs on them while they have their FIRST exp. would aid in finding someone who ditches out. The process in which we use this aid is up in the air. > The 60 day expiry value is a server parameter, not a client > parameter. In any case, as I explained above, I think that a drastic > reduction in the value would be dangerous. I think it is realized that the 60 day value is a server parameter, and the change in value would be only effective for FIRST TIME users. Besides, I don't know of many users who have a problem checking in every week to keep things moving smoothly. Best wishes, Jeramy _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 12 Mar 2001 12:53:15 +0100 From: Alexander Kruppa <[EMAIL PROTECTED]> Subject: Re: Mersenne: Security of prime95 Compiling a forge version with malicious code of Prime95/mprime and distributing it is maybe the simples and possibly most devastating attack. Since the complete source (save for the Primenet checksums but these could either be reverse-engineered or the fake client could simply connect to a fake server) is freely available, it would be extremely easy to build a trojan Prime95 client that feels just like the real thing. Right now there are few possibilities to verify the integrity of a Prime95 package you get, other than downloading it from the original ftp server - but that could be hacked, too. I think it would be a good thing if George could get a certified public key and issued signatures for the official Prime95 releases. That way a forged Prime95 package could quickly be identified and counter measures could be taken. Ciao, Alex. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 12 Mar 2001 16:11:25 +0100 From: "Siegmar Szlavik" <[EMAIL PROTECTED]> Subject: Re: Mersenne: prime95 - v21 progress On Sun, 11 Mar 2001 07:55:04 -0600, Steve wrote: >[...] As others have mentioned, the problem is NOT slow machines but >rather abandoned exponents, which has nothing to do with machine speeds. > exactly... and that is the point... maybe someone with access to the server logs can give us a rough estimation of the expired/checked in exponents ratio, so we better know of what we are talking about... If it is too high, then I think it would be definitevly worth to find a way to reduce it, because indirectly it affects the average test time and recently there have been some 'complaints' about the time to complete a exponent and this beeing a reason not to join/continue the project... recently there were also several remarks regarding the fact, that one has to wait relatively long compared to other distibuted projects just to get mentioned for the first time in the top producers list. maybe we could do something for those who are in for 'competition' on a more individual/machine basis. It takes a long time to climb the 'highscore table' with just one computer. What I was thinking of was a sort of 'fastest machine of the day/week/month highscore table' which mainly shows a ranking of the best machines which checked in/updated the last day/week/month, what I think is easy to compute and can be done after every update/check in. These informations and maybe also some other statistical data can be used in combination with the screen saver idea and displayed on the user screen saying something like: "This computer is working on the GIMPS... right now it's the xxx fastest machine in the project running at ####, overall ranking is ****; peak performance was #### achived on 00-00-0000. Estimated time to complete active work: ...." and so on... ...just my 0.02 euro ;-) greetings, Siegmar PS: talking about mailing list server improvements in another thread... I just noticed, that there is no "Reply-To: [EMAIL PROTECTED]" line in the header. I would find it usefull if it would be like in other mailing lists where a reply goes by default to the list and not to the sender. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 12 Mar 2001 16:26:44 +0100 From: Guillermo Ballester Valor <[EMAIL PROTECTED]> Subject: Re: Mersenne: Primitive roots for Galois transforms? Hi: Jason Stratos Papadopoulos wrote: > > > Ernst Mayer and I exchanged many mailings about > > using GF(p^2) when p = 2^61 - 1. > > I thought he had implemented it, as part of a > > mixed integer/complex FFT. > > As I remember, he *had* implemented it but the project is in limbo now for > several reasons: first, the Alpha compiler wouldn't interleave the integer > and floating point instructions, and also Ernst mentioned that > non-power-of-two transforms in GF(p^2) had some subtle difficulty > (something about the order that you applied the various radices being > important). Last I heard he was embarking on implementing a mixed > integer/complex FFT in assembly language, but that was quite a while ago > and he likely has moved on. > As a new version of Glucas program, I am considering the possibility to work with M31=2^p -1 instead of M61. In this case p^2-1 is not as smooth as M61^2 - 1, but the use of this "small" GF(M31^2) could give us some advantages. The modular mul M31, for 64 bits integer should be fast enough to "fight" against the very fast FPU units. The modular add/sub is perhaps faster than Floating point one. So, a complex integer arithmetic could be as fast as complex float, a nice feature for processors with independent integer-mul-unit and float-mul-unit. If the compiler does a good job interleaving float and integer code, we can gain about 15 bits_per_limb with few cost, and so we should gain about 50% performance. Regards Guillermo. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 12 Mar 2001 21:08:06 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Security of prime95 On 12 Mar 2001, at 12:53, Alexander Kruppa wrote: > Compiling a forge version with malicious code of Prime95/mprime and > distributing it is maybe the simples and possibly most devastating > attack. Yes. This is much the most likely "exploit". The other putative exploits are IMHO so unlikely as to be for all practical purposes safe to ignore. Certainly anyone who operates _any_ web browser, or _any_ mail client, or _any_ server - even just ICMP echo - should not be living in fear of attack through the Prime95 / mprime client. > Since the complete source (save for the Primenet checksums but > these could either be reverse-engineered or the fake client could simply > connect to a fake server) is freely available, it would be extremely > easy to build a trojan Prime95 client that feels just like the real > thing. If the trojan client was communicating with a "fake" server, those of us who take an interest in following progress wouldn't be fooled for long ... we'd either start receiving stupid assignments, or stop seeing the results we'd posted appearing in the database. A successful trojan has to contain _all_ the functionality of the real package. > Right now there are few possibilities to verify the integrity of > a Prime95 package you get, other than downloading it from the original > ftp server - but that could be hacked, too. Those of us that operate software distribution servers are well aware of the fact. The software on the server I operate is protected from interference. Now I can't say that I absolutely guarantee to keep unwanted visitors out (no-one in their right mind would!), but I'm confident that I will detect any intrusion in reasonably short order. > I think it would be a good thing if George could get a certified public > key and issued signatures for the official Prime95 releases. That way a > forged Prime95 package could quickly be identified and counter measures > could be taken. Actually, if George just got a signed PGP key, he could communicate the CRC32 & MD5 checksums of the various files to us by signed email. It _may_ be _theoretically_ possible to engineer a trojan with the same file size, CRC32 & MD5 checksums which does incorporate the functionality of its genuine counterpart, but the probability of this happening within the lifetime of Prime95 is pretty close to zero. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 12 Mar 2001 21:08:06 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: prime95 - v21 progress On 12 Mar 2001, at 0:20, Alexander Kruppa wrote: > > (1) Removing these assignments from PrimeNet and managing them > > seperately. Anyone who is prepared to make special arrangements to > > acquire these assignments is unlikely to default by reason of lack of > > commitment. > > Someone is (or was?) doing something similar - David Campeau (sp?), aka > diamonddave, who set up scripts to grab small exponents right after the > Primenet servers recycle run and completed them in ascending order of > size. That was unofficial. I meant official, and I meant removing the lagging exponents from PrimeNet so that they simply can't be grabbed using this sort of technique. In any case, the "lagging" LL assignments are now in the DC range. The "diamonddave" technique simply wouldn't be effective. > This doesn�t help with the exponents that are currently reserved with a > expected run time of several years - but if the user abandons them, the > server will recycle them 60 days after the last update from the user > which doesn�t seem like an overly long delay for the project. If the > users chooses to complete the exponent on a slow machine or on a machine > that is not in use very often, then I don�t see why he shouldn�t be > allowed to do so, delaying a milestone or not. My suggestion wouldn't cope with that, either. Except by "officially" pirating the assignment. I would argue that a competent individual administering a relatively small amount of assignments manually should be able to make the required judgements. BTW I agree with Alex that milestones are not the be-all and end-all of the project. I'm simply trying to find something that will satisfy the "pushers" without upsetting those who are perfectly happy for a run to take a long time. Providing, of course, completion does eventually occur. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 12 Mar 2001 16:54:02 -0500 From: George Woltman <[EMAIL PROTECTED]> Subject: Mersenne: milestones Hi all, There is another, and perhaps the most important reason, progress on double-checking milestones has been slow. When a double-check is sent in the server does not have enough information to know if a triple-check is needed. That info is in my master database - 3000 miles away. I have not been very aggressive in informing the server that a triple-check is needed. Starting now, I will do this at the beginning of each month. In the meantime, I have 98 exponents below 4,000,000 available for triple-checking and many more above that. If you are interested, send me a private email letting me know how many you would like (shoot for a 6 week turn-around time). Since these will be manual assignments, you will not get primenet CPU credit. THIS OFFER IS GOOD FOR 24 HOURS ONLY - after that I'll let the server assign these exponents. Have fun, George _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 12 Mar 2001 19:51:58 -0500 From: "Joshua Zelinsky" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Security of prime95 Alexander Kruppa wrote: >I think it would be a good thing if George could get a certified public >key and issued signatures for the official Prime95 releases. That way a >forged Prime95 package could quickly be identified and counter measures >could be taken. While were on the topic of authentification. Why not have a code for the server as well. Prime95 could automatically check it whenver it contacted the server. That would help prevent hackers from acting as the server. Sincerely, Joshua Zelinsky [EMAIL PROTECTED] _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 12 Mar 2001 20:04:07 EST From: [EMAIL PROTECTED] Subject: Re: Mersenne: Primitive roots for Galois transforms? Jason Stratos Papadopoulos wrote (to Peter Montgomery): > > > Ernst Mayer and I exchanged many mailings about > > using GF(p^2) when p = 2^61 - 1. > > I thought he had implemented it, as part of a > > mixed integer/complex FFT. > > As I remember, he *had* implemented it but the project is in limbo now for > several reasons: first, the Alpha compiler wouldn't interleave the integer > and floating point instructions, and also Ernst mentioned that > non-power-of-two transforms in GF(p^2) had some subtle difficulty > (something about the order that you applied the various radices being > important). Last I heard he was embarking on implementing a mixed > integer/complex FFT in assembly language, but that was quite a while ago > and he likely has moved on. > Indeed I did implement a version for power-of-2 vector lengths. But even on the Alpha 21264 it was much slower than I expected, so, my time being limited, I shelved it and preferred to work on enhancing the all-floating FFT version, where the near-term payoff was much surer. Now that I've squeezed out about as much as I think I can be reasonably done from the floating-point version, I've been thinking about the modular stuff again. Your experience with all-modular convolution on the 21264 (I believe within a factor of 2 of the speed of floating FFT is what you said) gives me hope that a pure-integer over a field with nice arithmetic properties (such as the complex integers GF(q^2) as you mentioned, and choosing q a Mersenne prime makes modular arithmetic a lot nicer) can compete with floating-point transform on hardware with good integer support (multiply is the key in most instances.) What happened to me, as you noted, was a compiler which was awful at combining floating and integer code. The other "problem" I encountered, which you alluded to, is that one of the really nice properties of arithmetic over GF(q^2), namely that arithmetic modulo the gaussian integers closely mirrors that over the complex numbers, fails for non-power-of-2 runlengths, in the sense that the conjugation property exploited by complex FFTs which pack real inputs into half-length complex vectors no longer holds for the modular data. The conjugates are still there, but their locations in the transform output are all screwed up, to use nontechnical language. This probably can be overcome or at least mitigated to some degree, but it didn't look like it was going to be pretty when I first encountered it. But starting with a simple power-of-2 runlength implementation and using a good compiler (I plan to switch to C) should be a worthwhile effort. Guillermo Ballester Valor wrote: <M<M As a new version of Glucas program, I am considering the possibility to work with M31=2^p -1 instead of M61. In this case p^2-1 is not as smooth as M61^2 - 1, but the use of this "small" GF(M31^2) could give us some advantages. The modular mul M31, for 64 bits integer should be fast enough to "fight" against the very fast FPU units. The modular add/sub is perhaps faster than Floating point one. So, a complex integer arithmetic could be as fast as complex float, a nice feature for processors with independent integer-mul-unit and float-mul-unit. If the compiler does a good job interleaving float and integer code, we can gain about 15 bits_per_limb with few cost, and so we should gain about 50% performance. >> Choosing q = M31 may be better on architectures which lack an instruction to obtain the upper 64 bits of a 128-bit product, but the hardware will still need to be able to calculate 32 x 32 => 64-bit products quickly. M31 also allows complex operands to be packed into 64- bit fields, which allows adds to proceed in parallel on the real and imaginary part (assuming the hardware has a 64-bit adder.) Multiplies need to use unpacked (i.e. separate) real and imaginary parts. M31 also needs quite a few more modular reductions of intermediates than does M61. M31 should be nice on 32-bit SIMD hardware such as the Pentium MMX and G4 AltiVec units, assuming floating-point instructions can keep executing alongside (this may not be true of the MMX - not sure about the G4). Assuming balanced-digit representation, hybrid floating/M61 allows inputs ~30.5 bits larger than floating-only; hybrid floating/M31 allows ~15.5 bits more, but requires less overall memory bandwidth. On good 64-bit hardware, it could be a toss-up, in which case allowing either modulus would allow some optimization of transform length for the number under test, while still using just power-of-2 lengths and thus avoiding the data-access-pattern headaches associated with non-power-of-2 runlengths. Oh, Peter found 6+I to be a primitive root of order q^2-1 for both q = M31 and M61. Odd-order roots over these fields have the nice property that they are pure real, low-order power-of-2 roots (specifically, roots of order 2, 4 and 8) mirror those of the complex FFT. For power-of-2 runlengths, one can also use a nice closed-form expression due to Creutzburg and Tasche [1989] for the primitive root of order 2^(p+1) (where q = 2^p - 1): r = 2^[2^(p-2)] - I*(-3)^[2^(p-2)] (mod q). Note that for p > 2, 2^(p-2) is always even, so we can replace the -3 with 3 in the above formula. It can also easily be shown that, for odd p, the real part of r is just 2^[(p+1)/2]. Sorry if this appears a bit cobbled-together: it is, as I'm at work and lacking time for an elegant exposition. More later (and not just from me, I'm sure) - -Ernst _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 12 Mar 2001 22:04:38 -0500 (EST) From: Jason Stratos Papadopoulos <[EMAIL PROTECTED]> Subject: Re: Mersenne: Primitive roots for Galois transforms? On Mon, 12 Mar 2001 [EMAIL PROTECTED] wrote: > version, where the near-term payoff was much surer. Now > that I've squeezed out about as much as I think I can > be reasonably done from the floating-point version, I've > been thinking about the modular stuff again. Your > experience with all-modular convolution on the 21264 > (I believe within a factor of 2 of the speed of floating > FFT is what you said) gives me hope that a pure-integer > over a field with nice arithmetic properties (such as > the complex integers GF(q^2) as you mentioned, and > choosing q a Mersenne prime makes modular arithmetic a > lot nicer) can compete with floating-point transform on > hardware with good integer support (multiply is the key > in most instances.) What happened to me, as you noted, > was a compiler which was awful at combining floating and > integer code. Well, here's how the timings stack up at present. The Mlucas column gives optimal times for v2.7b, the ICL version gives the best times I can manage for an all-integer Mersenne-mod squaring. Both runs were on an otherwise idle DS10 Alphaserver with a 466MHz 21264 processor, 2MB of L2 cache and 128MB RAM on an 83MHz FSB. Mlucas ICL - ------------------- 256k .0737 .161 sec 512k .1721 .339 1024k .3786 .714 The integer convolution uses a 61-bit prime of no special form. Since the last version of the integer code I posted, I've tried a few tricks that don't help much, and before I got buried at work I was working on high-performance CRT code that may or may not shave off a little time. I also considered an M61 convolution, and have some figures that may help. For a schedule of instructions that includes loads and stores, the 21264 is supposedly capable of a sustained 3.25 integer operations per clock. I've actually found that when you mix together multiplies, loads and stores the best you can do is about 2.7 integer instructions per clock. The FPU can issue 2 operations per clock, but when you throw in FPU loads (which use the integer units) the maximum issue rate is 2.9 register writes per clock. With FPU stores thrown in the maximum sustainable issue rate goes down to 2.3 FPU instructions per clock. I have vector-M61-complex-multiply code on paper that can theoretically complete a complex multiply in 11-12 clocks (you need a 3-stage pipeline), and as I remember it issues 2.6 instructions per clock. It should be possible to reduce the integer issue rate slightly and fill all the remaining gaps with FPU instructions, and have the two computations finish in about 1.5x the integer-only time. ICL uses vector multiply code that takes 6 clocks/modmul, so there is no time savings on the integer side. However, a split-radix or radix-8 FGT will cut the number of complex multiplies by 20-30%, and you can expect to see similar speedups with the convolution itself. I suspect that any butterfly loop or computation that involves complex multiplies is going to need *major* assembly langauage to get optimal performance. Heck, Compaq C for linux doesn't use 128-bit long longs, and non-bleeding-edge gcc does not perform 21264 optimizations. Hope this helps, jasonp _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 12 Mar 2001 21:36:55 -0800 From: Monte Westlund <[EMAIL PROTECTED]> Subject: Mersenne: VB primality test program Hello all, I'm looking for a primality test program source code written in VB, for fun and adventure. Just want to mess around a little. Searched a little with no luck. Running Prime95, just made 7755 ranking. WooHoo! Monte _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 13 Mar 2001 00:08:48 -0600 From: "Steve" <[EMAIL PROTECTED]> Subject: Re: Mersenne: prime95 - v21 progress >I think it is realized that the 60 day value is a server parameter, and the >change in value would be only effective for FIRST TIME users. Besides, I >don't know of many users who have a problem checking in every week to keep >things moving smoothly. > Also remember that the current 60 day value will not cause an exponent to expire in 60 days as it now stands; it's more like 88 days. Now I'm not advocating reducing that all the way to 7 days, but even if it were, all you would have to do is change the "check in" parameter to (say) 50 days and the exponent would then not expire for 57 days (unless it would finish in less than 50). You could even tell it you were going on "vacation" for 88 days and it wouldn't expire for 88 days, same as now, regardless of the expected completion date. There is no reason for those paying attention to have to check in every week. Those not paying attention are the ones creating the lags. Steve Harris _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 12 Mar 2001 22:12:54 -0800 From: "John R Pierce" <[EMAIL PROTECTED]> Subject: Re: Mersenne: VB primality test program > I'm looking for a primality test program source code written in VB, > for fun and adventure. Just want to mess around a little. Searched a > little with no luck. I'm afraid VB would be awfully slow at any sort of intensive numerical work like this, and not very good with precision either, so I rather doubt anyone has spent any signficant time on anything much more sophisticated than a erathonese sieve program - -jrp _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 13 Mar 2001 06:17:34 -0000 From: "Daran" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Quitting GIMPS - -----Original Message----- From: Shot <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 12 March 2001 07:32 Subject: Mersenne: Quitting GIMPS >- LL tests take a long time to complete. Current exponent will take >four months on my machine - a little too much for me.... I last returned a result on 6 December, but I may have finished it several days earlier. My current exponent (5151593) is scheduled to complete in three days time, so that's nearly three and a half months. My next (6193307) is expected to finish 18 August - five months - though I'll have replaced my PC before then. I joined the project on Feb 28 1999. I've returned just 12 DCs and 6 factorisations efforts. I have found no factors. I contribute a little under 13 P90 hours/day. OK, so I'm running it on an abacus. :-) I'm Slow But Reliable. I'm glad to read that it isn't us SBRs that are holding up the project. >...Yes, I know, I >can do double checks of factor, but, let's face it - _for me_ double >checks are not *that* thrilling,... Somebody's got to do them. >...and only 10% of factoring time is >'counted' (right?). 0% of OGR searching time is counted in the Primenet top producer tables. :-) >- Errors. I recently added some more RAM to my computer, and the >first module I bought was bad - before I managed to run the torture >test it affected (or not) my four months of searching with >sum(inputs) != sum(outputs) and round off errors. It was my mistake >(I should've turned Prime95 off before inserting the new RAM), but it >was unreversable. What you 'should've done' is back up your data. >- Ranking. Well, distributed.net's way of counting work is much more >'sexy' - in distributed.net I'll be returning work much more often, >and I'll get credited for it every day. Maybe if PrimeNet could count >every iteration (and switch for daily, instead of hourly, statistics - >there are reasons for doing it), or we could come with some other >way to credit work more often. Personally I think all the 'credits' and 'rankings' business is irrelevant fluff... ...but if I were a top 100 producer, then I'd think it was /very important/. :-) >- Money. No, I'm not in it for money - OGR is the only >distributed.net's project that has no cash prize. At least that >much... ;?) It's easier to buy a lottery ticket. Probably cheaper too. >Any comments to above are welcome - I'm not going to quit reading >GIMPS mailing list (at least not it the list moderator decides to >unsubscribing me). ;?) I don't see why he/she should. According to the welcome message "This list is for discussion of the computation of Mersenne primes." There's nothing there about being a GIMPS participant. I can't see any reason why anyone should be offended by your decision. It's not as if anyone's life depends upon the discovery of the next Mersenne prime. You're not abandoning distributed computing - you're moving to a different project. And searching for OGR seems to be as laudable - and as useless - as searching for Mersenne primes. >I'll try to write a letter in a month or two with my thoughts about >differencies between GIMPS and OGR search. I look forward to that. Cheers, - -- Shot Daran G. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 13 Mar 2001 06:21:25 -0000 From: "Daran" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Security of prime95 - -----Original Message----- From: Nathan Russell <[EMAIL PROTECTED]> To: Daran <[EMAIL PROTECTED]> Date: 12 March 2001 11:39 Subject: Re: Mersenne: Security of prime95 >On Mon, 12 Mar 2001 06:02:48 -0000, Daran wrote: > >(snip) >>Better would be to include in your start-up scripts code to copy the data >>files from your prime95 directory into your mprime directory, while copying in >>the reverse direction when you shutdown. > >I've been considering doing just that, however, after thinking on it >for some time, I can't see any way to be certain that it would work >even if Linux shut down improperly. Neither can I. But you'd only loose the work you'd done since booting into linux. Or you could set up a cron job to copy the files from your mprime directory to prime95 every half hour or so. >Nathan Daran G. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 13 Mar 2001 06:20:59 -0000 From: "Daran" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Security of prime95 - -----Original Message----- From: Brian J. Beesley <[EMAIL PROTECTED]> To: Daran <[EMAIL PROTECTED]> Date: 12 March 2001 21:08 Subject: Re: Mersenne: Security of prime95 On 12 Mar 2001, at 6:03, Daran wrote: >Now I'm not saying it's sensible to ignore risk, or not to take >reasonable measures to reduce it - far from it - but, when the risk >is _very_ small (as I believe it is in the case of running the >Prime95 / mprime client), I believe it makes more sense to be >reassuring than to _risk_ pressing the panic button. By giving out incorrect information? "The network communications between the server and client pose no risk as there is no instruction payload" is simply wrong. I'm not trying to scaremonger. I don't think the risks are that great either, or I wouldn't be running it. I can't speak for anyone else, but what /I/ find reassuring is to be told that security was a primary consideration in the project design, implementation, and testing. I do not find it reassuring to be told that there is "no risk". [...] >I did try _very_ hard to crack into both Windows & linux clients at >about v20.3 and was entirely unsuccessful... That's the most reassuring thing you've said so far. [...] >Aim this message at the server operators. Having said that, I see >several breaches per week which are attributable to badly coded >Microsoft clients, and I haven't noticed them sufferring too much as >a consequence. Microsoft gets away with what it does because of its overwhelmingly dominant market position. And yes they do suffer for it. Unfortunately they don't suffer enough. >Regards >Brian Beesley Daran G. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 13 Mar 2001 08:38:11 -0000 From: "Andy Hedges" <[EMAIL PROTECTED]> Subject: RE: Mersenne: VB primality test program I chucked together a LL agorithm in Java a while back in order to benchmark some JVM's. If anyone is interested I could post the source and bytecode to my website. btw :- It is many many times slower than Prime95 (as expected). Andy > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of John R > Pierce > Sent: 13 March 2001 6:13 am > To: Monte Westlund; [EMAIL PROTECTED] > Subject: Re: Mersenne: VB primality test program > > > > I'm looking for a primality test program source code written in VB, > > for fun and adventure. Just want to mess around a little. Searched a > > little with no luck. > > I'm afraid VB would be awfully slow at any sort of intensive > numerical work > like this, and not very good with precision either, so I > rather doubt anyone > has spent any signficant time on anything much more > sophisticated than a > erathonese sieve program > > -jrp > > > ______________________________________________________________ > ___________ > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers > > _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 13 Mar 2001 06:31:02 -0800 From: Monte Westlund <[EMAIL PROTECTED]> Subject: Re: Mersenne: VB primality test program On Tue, 13 Mar 2001 08:38:11 -0000, you wrote: >I chucked together a LL agorithm in Java a while back in order to benchmark >some JVM's. If anyone is interested I could post the source and bytecode to >my website. > >btw :- It is many many times slower than Prime95 (as expected). > >Andy > Andy, I would be interested. I don't know where your website is. Monte _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 13 Mar 2001 06:29:40 -0800 From: Monte Westlund <[EMAIL PROTECTED]> Subject: Re: Mersenne: VB primality test program On Mon, 12 Mar 2001 22:12:54 -0800, you wrote: > >I'm afraid VB would be awfully slow at any sort of intensive numerical work >like this, and not very good with precision either, so I rather doubt anyone >has spent any signficant time on anything much more sophisticated than a >erathonese sieve program > >-jrp > I know VB would not be the first choice. It's more for benchmarking some machines(Prime95 is not an option on them), and to explore a bit. Monte _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ End of Mersenne Digest V1 #828 ******************************
