mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > PrimeNet

Reply
 
Thread Tools
Old 2019-02-26, 18:09   #12
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

1110111010012 Posts
Default

Quote:
Originally Posted by Mark Rose View Post
16 KB/s up... that's painful! Reminds me of the 90's.
Yes. Frontier DSL. Which while it nominally stands for digital subscriber link, darn slow link seems to fit when it's working, or dubious stability likely when it's not, as in recently. The line was physically cut for a week last summer. There are times where decent dialup might be faster. Currently it seems to take approximately the timeout period to DNS resolve. Getting a reply to thread window or ordinary web page retrieval can take minutes.A utility subcontractor crew was marking neighborhood utilities the other day. Hopefully that means fiber to the home may actually happen eventually. Original schedule for that was last year. I've been tracking the signups and projecting when my neighborhood would reach the threshold for implementation. Looks like another year plus currently. Ugh.
kriesel is offline   Reply With Quote
Old 2019-02-26, 20:06   #13
preda
 
preda's Avatar
 
"Mihai Preda"
Apr 2015

3F516 Posts
Default

Quote:
Originally Posted by Mark Rose View Post
What does a trusted client actually mean for us?

I gather what we're doing is validating that the work is actually done.

Couldn't we just submit the penultimate state for LL and PRP and rerun the final iteration on the server instead?
Unfortunately that doesn't verify that "work was done": the cheater would just start with random data as "the penultimate iteration", do one iteration, send the residue and the penultimate value, and everything would check ok.
preda is offline   Reply With Quote
Old 2019-02-26, 21:43   #14
Mark Rose
 
Mark Rose's Avatar
 
"/X\(‘-‘)/X\"
Jan 2013
Ͳօɾօղէօ

278610 Posts
Default

Quote:
Originally Posted by preda View Post
Unfortunately that doesn't verify that "work was done": the cheater would just start with random data as "the penultimate iteration", do one iteration, send the residue and the penultimate value, and everything would check ok.
Hmm, you're right. It only works with (probable) prime results.
Mark Rose is offline   Reply With Quote
Old 2019-02-27, 04:20   #15
Madpoo
Serpentine Vermin Jar
 
Madpoo's Avatar
 
Jul 2014

3×1,087 Posts
Default

Quote:
Originally Posted by Mark Rose View Post
What does a trusted client actually mean for us?...
"trusted" in the sense that the developer is given a secure key and knowledge of what calculations need to take place in order to magically turn the CPU guid into the hash used when communicating via the API.

In theory then, each 3rd party client would get their own key (and maybe even have their own algorithm to generate the hash), and if we ever had a situation where the secret sauce got out, we just issue them a new key for their next version and we don't have to accept results from the old versions if it was bad enough (or we play it by ear and try to get people to upgrade to a new version ASAP).

Anyway, that's kind of the theory.

Honestly, this was all the system developed years ago by Scott and while it worked at the time and was groundbreaking, there are more well developed ways of securing client/server communications these days, whether it's public-key crypto, common API endpoints, etc. Could it be modernized? Yeah... is it worth a big rewrite of things? Well, maybe if it solved some real issues...
Madpoo is offline   Reply With Quote
Old 2019-02-27, 05:36   #16
ewmayer
2ω=0
 
ewmayer's Avatar
 
Sep 2002
República de California

2×52×223 Posts
Default

Quote:
Originally Posted by Madpoo View Post
I've been working with Ernst on exploring some of the finer points of using the API.
...
So in my grand scheme, I thought of some kind of thing to create a "Third Party Client" cpu through the website which would show you the GUID, and you could cut/paste that GUID into whatever config file the client uses to talk to the API. That special type wouldn't check the freshness of the last time it was updated because it doesn't make sense.

Essentially this is no different, security-wise, than accepting 3rd party client results through the manual result page... those don't even have the checksum on LL/PRP that can be used to weed out bogus submissions.
Yes, this sort of minimal enhancement would allow for a lot of useful experimentation without breaking open-sourceness or requiring major upgrades to one of the untrusted clients. For instance, the assignment-progress-update stuff I want to add to my primenet.py script needs just the GUID, after that things are easy.

So the question is, would it be useful to make the server-generated GUID in the above simple schema more than a random 128-bit string? For instance, maybe require/use a valid priment ID and password to trigger the GUID-generation? That way, a user porting e.g. Mlucas to a new machine would be prompted to enter those 2 primenet credentials the first time they run the py-script on the new hardware, the script then checks those credentials with the server and the server only returns a GUID if they check out. The py-script then stores the GUID in a local file and uses that cached datum from then onward.

I guess the question is, are there any obvious kinds of gaming-of-the-system we want to guard against in this kind of untrusted-client/v5-server interaction? If the create-GUID call also required, say, the submitter to supply a hardware MAC address, maybe also some HW specs? The server might be able to use those to flag fake submissions, say an unreasonable rate of production from a single PC. OTOH, I use my Mac to collect & submit Mlucas results from several non-networked machines, which would argue against such output-rate checks, except maybe of the extreme-level variety.

Last fiddled with by ewmayer on 2019-02-27 at 05:42
ewmayer is offline   Reply With Quote
Old 2019-02-27, 08:34   #17
SELROC
 

3·5·7·31 Posts
Default

Quote:
Originally Posted by Madpoo View Post
"trusted" in the sense that the developer is given a secure key and knowledge of what calculations need to take place in order to magically turn the CPU guid into the hash used when communicating via the API.

In theory then, each 3rd party client would get their own key (and maybe even have their own algorithm to generate the hash), and if we ever had a situation where the secret sauce got out, we just issue them a new key for their next version and we don't have to accept results from the old versions if it was bad enough (or we play it by ear and try to get people to upgrade to a new version ASAP).

Anyway, that's kind of the theory.

Honestly, this was all the system developed years ago by Scott and while it worked at the time and was groundbreaking, there are more well developed ways of securing client/server communications these days, whether it's public-key crypto, common API endpoints, etc. Could it be modernized? Yeah... is it worth a big rewrite of things? Well, maybe if it solved some real issues...

That sound OK. However, requiring people to upgrade version ASAP is subject to a number of issues, for example backward-compatibility for checkpoint files, if we are asked to change version in the middle of computation.
I personally have set a plan to upgrade only if it is relevant to the computation, that is if there is an evident performance improvement.

Last fiddled with by SELROC on 2019-02-27 at 08:35
  Reply With Quote
Old 2020-01-25, 23:41   #18
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

11·347 Posts
Default

Quote:
Originally Posted by ewmayer View Post
So the question is, would it be useful to make the server-generated GUID in the above simple schema more than a random 128-bit string? For instance, maybe require/use a valid primenet ID and password to trigger the GUID-generation? That way, a user porting e.g. Mlucas to a new machine would be prompted to enter those 2 primenet credentials the first time they run the py-script on the new hardware, the script then checks those credentials with the server and the server only returns a GUID if they check out. The py-script then stores the GUID in a local file and uses that cached datum from then onward.
In the context of a separate helper application, which I'm working on, that supports MULTIPLE gpu application instances on multiple gpus on a single system, how about something like this:
XOR the 128 lsb's of each gpu application instance's unique working directory path string with a server generated key. Or with the prime95/mprime instance's GUID on the same system if there is one.
Or instead of XOR, something like MD5 hash. https://en.wikipedia.org/wiki/MD5

The cryptographic uselessness of MD5 or XOR is a feature. I want it to be something that US export controls don't affect. I prefer simplicity too, both for implementation and for use.
This could allow the helper app to manage addition of and update of several distinct gpu/application/instance-count combos with one user interaction for primenet ID and password. One example system (on which the GTX1070 is subsequently RIP) is described at https://www.mersenneforum.org/showpo...95&postcount=7

I guess a separate question is how PrimeNet would respond to a rapid fire registration of about a dozen new "computers" from one PrimeNet ID in such a scenario. And several on the next system. And the next...

Last fiddled with by kriesel on 2020-01-26 at 00:03
kriesel is offline   Reply With Quote
Old 2020-01-26, 00:06   #19
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

1110111010012 Posts
Default

Quote:
Originally Posted by ewmayer View Post
I guess the question is, are there any obvious kinds of gaming-of-the-system we want to guard against in this kind of untrusted-client/v5-server interaction? If the create-GUID call also required, say, the submitter to supply a hardware MAC address, maybe also some HW specs? The server might be able to use those to flag fake submissions, say an unreasonable rate of production from a single PC. OTOH, I use my Mac to collect & submit Mlucas results from several non-networked machines, which would argue against such output-rate checks, except maybe of the extreme-level variety.
A well run Radeon VII gpu will look like an unreasonable rate of production from a single system. A mining rig with several mounted will look like a quite unreasonable rate of production.
Long ago I ran 2 primenet (V1 or 2?) servers, one at work and another at home, and periodically manually reported the results in to George by email.
kriesel is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Primenet and GMP-ECM ET_ PrimeNet 9 2018-07-04 20:28
Hello PrimeNet!! SeeD419 PrimeNet 7 2011-07-11 18:09
56.0-57.x on PrimeNet v5 ckdo Lone Mersenne Hunters 0 2008-09-04 05:54
47.0-48.0 on PrimeNet ckdo Lone Mersenne Hunters 0 2008-02-14 20:05
New stats on PrimeNet! ET_ PrimeNet 18 2008-01-24 01:21

All times are UTC. The time now is 11:28.

Sat May 30 11:28:58 UTC 2020 up 66 days, 9:02, 2 users, load averages: 2.12, 1.94, 1.69

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.