Delivered-To: luke@ndatech.com Date: Sat, 10 Nov 2001 07:04:19 -0800 From: mersenne-digest-invalid-reply-address@base.com (Mersenne Digest) To: mersenne-digest@base.com Subject: Mersenne Digest V1 #903 Reply-To: mersenne@base.com Sender: mersenne-digest-invalid-reply-address@base.com Mersenne Digest Saturday, November 10 2001 Volume 01 : Number 903 ---------------------------------------------------------------------- Date: Thu, 8 Nov 2001 10:59:11 +0100 (MET) From: Wojciech Florek Subject: Mersenne: Re: 10M-digit prime Hi again! BTW, some `guesses' and `trial approximations' show that a Mersenne prime should occur for p between 26,000,000-32,000,000. I'm afraid that we'll have similar effect as for 1M-digit prime, when M37 occured to have a few digits less than 1M. If the factor 2, mentioned some days ago, is correct, then the next Mersenne prime will be found for p about 55M, so it will have about 18M (decimal) digits. Nevertheless, HAVE A GOOD HUNTING (AND FUN) to all people testing numbers near 33-34M (I'm one of them). Regards Wojciech Florek (WsF) Adam Mickiewicz University, Institute of Physics phone: (++48-61) 8273033 fax: (++48-61) 8257758 email: florek@amu.edu.pl _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Thu, 08 Nov 2001 11:58:45 +0100 From: Henk Stokhorst Subject: Mersenne: issue #18 of Mersenne newsletters seems to have caused an explosion! L.S., The primenet stat pages indicate a sharp sudden increase in issued exponents over the last 24 hours. Particularly the amount of PIII and PIV have gone up against the trend of the last months. Study of the status.txt page shows no change in the ratio computers per user accounts between recent and earlier issued exponents. In other words, something attracted of lot of new machines. Looks like it was the latest issue of the newsletter. Maybe it gave them some communityfeeling. By the way how many people were mailed? YotN, Henk Stokhorst. _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Thu, 8 Nov 2001 19:58:37 -0000 From: bjb@bbhvig.uklinux.net Subject: Re: Mersenne: number of processors participating On 6 Nov 2001, at 16:09, Gerry Snyder wrote: > In a recent ethics briefing I was told that running seti@home on work > PC's was a no-no because there had been three break-ins to computers > using that program as a back door. > > No idea whether that is really the case, and no idea what > communication scheme seti@home uses. Anyone familiar with this > perceived problem? I went & checked this out. There do appear to have been a few incidents involving seti@home. In one of these the server was hacked & details of the participants were "stolen"; at least some of the e-mail addresses were subsequently used by spammers. This is of course a serious incident, but nowhere near as serious as the disclosure of credit card numbers and other personal information which happened last weekend due to a security breach of the Microsoft Passport system. In at least one other case a number of systems at a site were compromised by installation of the seti@home client - but only because a "Back Orifice" type trojan had somehow become attatched to the copy of the client concerned - N.B. _not_ a direct download from the seti@home site. This sort of thing has reportedly also happened several times with the RC5 client. Note that the risk of "unofficial replacement" of clients downloaded from the net can be virtually eliminated by computing the MD5 checksum of "official" binary images and posting this somewhere _before_ the binary itself is made available. The point is that it is almost impossible to modify a binary image without changing the MD5 checksum - in fact, to the best of my knowledge, this has not been demonstrated, even in a laboratory environment - a very great deal of trial and error would be required to match the 256 bit checksum; unlike some checksum algorithms, MD5 was designed to be reasonably quick to compute once, but impossibly expensive to compute a very large number of times. Virus checkers are pretty effective at detecting trojans, provided the virus database is kept up to date. Finally, reasonable configuration of a firewall (even a personal firewall product installed on the workstation itself) will prevent exploitation of a Back Orifice type trojan, even if one does manage to sneak in unnoticed - these work by creating a listener which allows those "in the know" to connect to the system using telnet, ssh or a similar protocol, using a non-standard port number. I have been unable to trace any instances of security breaches of user systems due to running "official" copies of the seti@home client, or dependent in any way on client/server communications. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Thu, 8 Nov 2001 12:59:45 -0800 From: "John R Pierce" Subject: Re: Mersenne: number of processors participating > Finally, reasonable configuration of a firewall (even a personal > firewall product installed on the workstation itself) will prevent > exploitation of a Back Orifice type trojan, even if one does manage > to sneak in unnoticed - these work by creating a listener which > allows those "in the know" to connect to the system using telnet, > ssh or a similar protocol, using a non-standard port number. many of the newer remote control trojans connect out to a IRC (Internet Relay Chat) server (often using non-standard ports) and 'offer' themselves to the hackers rather than passively waiting for the hackers to connect to them. This will slip past a lot of firewalls. _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Thu, 8 Nov 2001 22:06:37 +0100 From: "Steinar H. Gunderson" Subject: Mersenne: Re: number of processors participating On Thu, Nov 08, 2001 at 07:58:37PM -0000, bjb@bbhvig.uklinux.net wrote: >The point is that it is >almost impossible to modify a binary image without changing the >MD5 checksum - in fact, to the best of my knowledge, this has not >been demonstrated, even in a laboratory environment - a very great >deal of trial and error would be required to match the 256 bit >checksum First, MD5 is only a 128-bit checksum (SHA1, which is intended to replace it, is 160 bits). Second, there _are_ known weaknesses in MD5 -- as far as I remember, it is possible (although not without a great deal of work) to produce two messages/files with the same checksum -- but I don't think you can decide the checksum for yourself, and you certainly can't modify a file, add a few bytes and retain the checksum. Just that there are weaknesses, though (and they could be viewed as rather serious), would probably mean it's best to leave MD5 alone and instead use SHA1, which is (as far as I've heard -- I'm certainly no cryptography expert) extremely well-designed, and free from any known weaknesses. Except for the MD5 weakness, though, hashes are generally extremely difficult to fake -- that's their main purpose, after all :-) /* Steinar */ - -- Homepage: http://www.sesse.net/ _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 09 Nov 2001 13:24:15 +0000 From: Gareth Randall Subject: Re: Mersenne: Re: SMT George Woltman wrote: > I agree with Steinar's intriguing observation. Intel's SMT looks > like two CPUs to the operating system but the two CPUs share > one core. Oh no, they're not going to cobble something together like that are they? This looks like another forthcoming disaster where the chance to make a real technological leap is squandered in the name of "compatibility" with some OS that firstly didn't deserve such an effort, and secondly could have been patched anyway. I hope they leave a mechanism for proper OSs to take full control and assign the parallel threads themselves, otherwise this will be another PC architectural compromise that blights performance or otherwise adds timewasting complexity like say: register sharing for MMX and FPU, cascaded IRQs, FPU IRQ, polled gameport, the whole of real mode(!), shite DMA, that "pretend the boot CD is actually a floppy disk" crap, and many others. The idea of SMT is to be able to feed all execution pipelines simultaneously, by allowing instructions to be drawn from several threads. So for example, when an application has nothing but integer instructions to execute, then floating-point instructions can be drawn from a process waiting to execute these and fed down the then idle floating point pipelines. For computational applications this is significantly different from having two processors. Prime95/mprime should be saved by accident rather than design - It executes mostly floating point, so will not compete head-on with "ordinary" apps which are mostly or entirely integer. The following article explained SMT (on the proposed Alpha EV8) for me: http://www.realworldtech.com/page.cfm?ArticleID=RWT122600000000 Yours, ======= Gareth Randall ======= _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 10 Nov 2001 10:52:08 CET From: lorenzini.guido@tin.it Subject: Mersenne: timings Hi all! Something quite strange is going on here! Recentely I've installed Prime95 v21 on a PC powered by a PIII 650 Mhz with Win98SE and 128 Mb RAM. It's LL-testing M12582013, so it's using FFT sized 640Kb and, therefore, I should get roughly 190ms per iteration as reported in the Mersenne benchmark web-page. Well, I don't know why but Prime95 says that it takes 305ms each iteration, which is the time needed for 1024Kb FFT with this kind of processor. Moreover I've reached this timing after having disabled all the programs and services usually loaded at system startup but Prime95... I'm sure that the system tray of this Pc has never been so "clean"! Before doing this I was getting 335ms!! To have some more data I've tryed timing some exp.s using different FFT sizes and it is evident that the performance of this pc aren't at the level it should be: 256K: 110ms, instead of 71 320K: 143ms, instead of 92 384K: 173ms, instead of 111 448K: 207ms, instead of 131 512K: 237ms, instead of 146 640K: 305ms, instead of 190 Well, this means almost 58% slower than expected. Since the data showed by Prime95 are absolutely correct, nothing else to think but there is another cpu type on board... But even this explanation is to be taken witha grain of salt!. The MoBo is a MSI MS 6199VA. When you boot up the system you may read: "PIII CPU at 650E Mhz". What does it mean 650 "E"? Does anybody how to check the Cpu frequency without opening the case? Any suggestion about what's probably going on is welcome!! Thanks in advance to everyboy who will help me. Regards from Italy Guido72 _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 10 Nov 2001 10:01:36 -0500 From: Jud McCranie Subject: Re: Mersenne: timings At 10:52 AM 11/10/2001 +0100, lorenzini.guido@tin.it wrote: > ...Well, this means almost 58% slower than expected. ... Is your video on the motherboard or do you have an actual video card? I had the same problem with my new computer that has video on the motherboard. My speed was roughly half what the benchmarks said they should be. I found that changing to lower resolution or fewer colors speeded up prime95. Also, if I had the monitor set to cut off under properties/screen saver / power then while it was off, Prime95 ran full speed. +---------------------------------------------------------+ | Jud McCranie | | | | Programming Achieved with Structure, Clarity, And Logic | +---------------------------------------------------------+ _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ End of Mersenne Digest V1 #903 ******************************