rbarreira wrote:
The problem that I'm thinking of is two users who are in fact the same person sending matching results for a work unit they did not calculate at all. This is the easiest cheat I can think of, if it's possible then it's really easy to be malicious.
It's not possible to 100% prevent that two results end up with the same user, he could use different IP and accounts etc.. (unless the screening process is a lot more strict somehow) but I think that if
1) a user can only send a result to a work unit assigned to him and
2) the verification unit is not sent out until the first result has been returned.
So technically it is still possible to cheat but you'd be taking a risk since you cannot be certain if you corrupt a package that you will also get the verification package, and if you don't you will get detected and exposed. So in a way probability is against the cheater the more honest clients there are. And I think that if we get massive amounts of wrong results we will know that someone out there is not playing fair and simply redo all their work.
rbarreira wrote:
The problem that I'm thinking of is two users who are in fact the same person sending matching results for a work unit they did not calculate at all. This is the easiest cheat I can think of, if it's possible then it's really easy to be malicious.
It's not possible to 100% prevent that two results end up with the same user, he could use different IP and accounts etc.. (unless the screening process is a lot more strict somehow) but I think that if
1) a user can only send a result to a work unit assigned to him and
2) the verification unit is not sent out until the first result has been returned.
So technically it is still possible to cheat but you'd be taking a risk since you cannot be certain if you corrupt a package that you will also get the verification package, and if you don't you will get detected and exposed. So in a way probability is against the cheater the more honest clients there are. And I think that if we get massive amounts of wrong results we will know that someone out there is not playing fair and simply redo all their work.
I agree that measure 1) is necessary, and some variation of 2) may also be a good idea (there has to be some timeout on the assignment otherwise someone who stops contributing would be hogging their unfinished work units forever).
rbarreira wrote:
The problem that I'm thinking of is two users who are in fact the same person sending matching results for a work unit they did not calculate at all. This is the easiest cheat I can think of, if it's possible then it's really easy to be malicious.
It's not possible to 100% prevent that two results end up with the same user, he could use different IP and accounts etc.. (unless the screening process is a lot more strict somehow) but I think that if
1) a user can only send a result to a work unit assigned to him and
2) the verification unit is not sent out until the first result has been returned.
So technically it is still possible to cheat but you'd be taking a risk since you cannot be certain if you corrupt a package that you will also get the verification package, and if you don't you will get detected and exposed. So in a way probability is against the cheater the more honest clients there are. And I think that if we get massive amounts of wrong results we will know that someone out there is not playing fair and simply redo all their work.
I agree that measure 1) is necessary, and some variation of 2) may also be a good idea (there has to be some timeout on the assignment otherwise someone who stops contributing would be hogging their unfinished work units forever).
Right true, but then you can no longer accept that particular result from that particular user, otherwise he could just wait for the timeout.
rbarreira wrote:
The problem that I'm thinking of is two users who are in fact the same person sending matching results for a work unit they did not calculate at all. This is the easiest cheat I can think of, if it's possible then it's really easy to be malicious.
It's not possible to 100% prevent that two results end up with the same user, he could use different IP and accounts etc.. (unless the screening process is a lot more strict somehow) but I think that if
1) a user can only send a result to a work unit assigned to him and
2) the verification unit is not sent out until the first result has been returned.
So technically it is still possible to cheat but you'd be taking a risk since you cannot be certain if you corrupt a package that you will also get the verification package, and if you don't you will get detected and exposed. So in a way probability is against the cheater the more honest clients there are. And I think that if we get massive amounts of wrong results we will know that someone out there is not playing fair and simply redo all their work.
The point is that I'm not approaching this from the point of view of trying to build an impregnable fortress. This is a cooperative perft project. I'm not going to try to seal off every possible window and door or I would be at this forever ....
However I am taking some reasonable measures so that if some malicious idiot wants to sabotage the result, he will have to work at it and it won't be completely trivial for him.
There will at least be some measure of safety in the fact that all users will have to make personal contact with me to negotiate a password. That may not sound like much, and maybe it isn't, but in practice people are far more likely to be malicious when they can do it anonymously. There have been studies that show that a guard posted at the door of a company can reduce theft and other crimes by a significant amount, even though the guard is oblivious to what is allowed to come and go out or even what is in your briefcase or pockets. It's just the fact that have to look him in the eye.
Don
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
conflict |rnb1kbnr/1pp1pppp/3q4/p2p4/8/3BPQ2/PPPP1PPP/RNB1K1NR w KQkq -|
conflict |rnb1kbnr/p1pp1ppp/8/1p2P1q1/8/2P5/PP2PPPP/RNBQKBNR w KQkq -|
conflict |rnb1kbnr/p1ppqppp/8/1p2P3/4P3/8/PPP2PPP/RNBQKBNR w KQkq -|
conflict |rnb1kbnr/p1qppppp/8/1pP5/8/3Q4/PPP1PPPP/RNB1KBNR w KQkq b6|
conflict |rnb1kbnr/pp1p1ppp/2p5/4p1q1/8/2BP4/PPP1PPPP/RN1QKBNR w KQkq -|
conflict |rnb1kbnr/pp1p1ppp/2p5/4p1q1/8/2N1P2N/PPPP1PPP/R1BQKB1R w KQkq -|
conflict |rnb1kbnr/pp1p1ppp/2p5/4p1q1/8/3P2PP/PPP1PP2/RNBQKBNR w KQkq -|
conflict |rnb1kbnr/pp1p1ppp/2p5/4p1q1/8/3P2PN/PPP1PP1P/RNBQKB1R w KQkq -|
conflict |rnb1kbnr/pp1p1ppp/2p5/4p1q1/8/3P3N/PPPNPPPP/R1BQKB1R w KQkq -|
conflict |rnb1kbnr/pp1pppp1/8/q1p4p/P6P/8/1PPPPPPR/RNBQKBN1 w Qkq -|
conflict |rn1qkbnr/p1p1pppp/3p4/1pP2b2/8/5P2/PP1PP1PP/RNBQKBNR w KQkq b6|
conflict |rn1qkbnr/p1p1pppp/3p4/1pP5/6b1/7N/PP1PPPPP/RNBQKB1R w KQkq b6|
conflict |rn1qkbnr/p1p1pppp/3p4/Pp6/8/1P5b/2PPPPPP/RNBQKBNR w KQkq b6|
conflict |rn1qkbnr/p1p1pppp/8/1pPp1b2/8/5P2/PP1PP1PP/RNBQKBNR w KQkq b6|
conflict |rn1qkbnr/p1p1pppp/8/Pp1p1b2/8/3P4/1PP1PPPP/RNBQKBNR w KQkq b6|
conflict |rn1qkbnr/pp1bpppp/2p5/P2p4/8/2N5/1PPPPPPP/R1BQKBNR w KQkq -|
conflict |rn1qkbnr/ppp1p1pp/4bp2/3p4/7P/5N2/PPPPPPP1/RNBQKB1R w KQkq -|
conflict |rn1qkbnr/ppp1p1pp/5p2/3p1P2/2P5/8/PP1PPP1P/RNBQKBNR w KQkq -|
conflict |rn1qkbnr/ppp1pppp/8/3p4/8/3P4/PPPBPPbP/RNQ1KBNR w KQkq -|
conflict |rn1qkbnr/ppp1pppp/8/3P4/8/8/PPPPbP1P/RNBQKBNR w KQkq -|
conflict |rn1qkbnr/ppp2ppp/8/3Ppb2/6Q1/8/PPPP1PPP/RNB1KBNR w KQkq -|
conflict |rn1qkbnr/pppb1ppp/8/3pp3/3P4/4P3/PPPK1PPP/RNBQ1BNR w kq -|
conflict |rn2kbnr/ppp1pppp/3q4/1P1p1b2/8/7P/P1PPPPP1/RNBQKBNR w KQkq -|
conflict |rn2kbnr/ppp1pppp/3q4/1P1p1b2/8/5P2/P1PPP1PP/RNBQKBNR w KQkq -|
conflict |rn2kbnr/ppp1pppp/3q4/1P1p1b2/8/8/P1PPPPPP/RNBQKBNR w KQkq -|
conflict |rnb1k1nr/pppp1ppp/5q2/4p3/P1P5/b7/1PQPPPPP/RNB1KBNR w KQkq -|
conflict |rnb1k1nr/pppp1ppp/8/2b1p1q1/P7/6R1/1PPPPPPP/1NBQKBNR w Kkq -|
conflict |rnb1k1nr/ppppbppp/8/4p3/3P3q/BP6/P1P1PPPP/RN1QKBNR w KQkq -|
conflict |rnb1kb1r/pp1ppppp/1q3n2/2P5/8/8/PPPNPPPP/R1BQKBNR w KQkq -|
Total conflicts = 29
Perft(6) with JetChess 1.0.0.0:
rnb1kbnr/1pp1pppp/3q4/p2p4/8/3BPQ2/PPPP1PPP/RNB1K1NR w KQkq -
3315082223
rnb1kbnr/p1pp1ppp/8/1p2P1q1/8/2P5/PP2PPPP/RNBQKBNR w KQkq -
1835451058
rnb1kbnr/p1ppqppp/8/1p2P3/4P3/8/PPP2PPP/RNBQKBNR w KQkq -
1790086075
rnb1kbnr/p1qppppp/8/1pP5/8/3Q4/PPP1PPPP/RNB1KBNR w KQkq b6
2254547105
rnb1kbnr/pp1p1ppp/2p5/4p1q1/8/2BP4/PPP1PPPP/RN1QKBNR w KQkq -
812662030
rnb1kbnr/pp1p1ppp/2p5/4p1q1/8/2N1P2N/PPPP1PPP/R1BQKB1R w KQkq -
1448550061
rnb1kbnr/pp1p1ppp/2p5/4p1q1/8/3P2PP/PPP1PP2/RNBQKBNR w KQkq -
708533378
rnb1kbnr/pp1p1ppp/2p5/4p1q1/8/3P2PN/PPP1PP1P/RNBQKB1R w KQkq -
754866403
rnb1kbnr/pp1p1ppp/2p5/4p1q1/8/3P3N/PPPNPPPP/R1BQKB1R w KQkq -
637587332
rnb1kbnr/pp1pppp1/8/q1p4p/P6P/8/1PPPPPPR/RNBQKBN1 w Qkq -
226693975
rn1qkbnr/p1p1pppp/3p4/1pP2b2/8/5P2/PP1PP1PP/RNBQKBNR w KQkq b6
419333070
rn1qkbnr/p1p1pppp/3p4/1pP5/6b1/7N/PP1PPPPP/RNBQKB1R w KQkq b6
423634751
rn1qkbnr/p1p1pppp/3p4/Pp6/8/1P5b/2PPPPPP/RNBQKBNR w KQkq b6
298109009
rn1qkbnr/p1p1pppp/8/1pPp1b2/8/5P2/PP1PP1PP/RNBQKBNR w KQkq b6
380098486
rn1qkbnr/p1p1pppp/8/Pp1p1b2/8/3P4/1PP1PPPP/RNBQKBNR w KQkq b6
734331322
rn1qkbnr/pp1bpppp/2p5/P2p4/8/2N5/1PPPPPPP/R1BQKBNR w KQkq -
361743836
rn1qkbnr/ppp1p1pp/4bp2/3p4/7P/5N2/PPPPPPP1/RNBQKB1R w KQkq -
312633074
rn1qkbnr/ppp1p1pp/5p2/3p1P2/2P5/8/PP1PPP1P/RNBQKBNR w KQkq -
215706565
rn1qkbnr/ppp1pppp/8/3p4/8/3P4/PPPBPPbP/RNQ1KBNR w KQkq -
616218339
rn1qkbnr/ppp1pppp/8/3P4/8/8/PPPPbP1P/RNBQKBNR w KQkq -
491805797
rn1qkbnr/ppp2ppp/8/3Ppb2/6Q1/8/PPPP1PPP/RNB1KBNR w KQkq -
3697774672
rn1qkbnr/pppb1ppp/8/3pp3/3P4/4P3/PPPK1PPP/RNBQ1BNR w kq -
1762051143
rn2kbnr/ppp1pppp/3q4/1P1p1b2/8/7P/P1PPPPP1/RNBQKBNR w KQkq -
792891681
rn2kbnr/ppp1pppp/3q4/1P1p1b2/8/5P2/P1PPP1PP/RNBQKBNR w KQkq -
735725885
rn2kbnr/ppp1pppp/3q4/1P1p1b2/8/8/P1PPPPPP/RNBQKBNR w KQkq -
882196772
rnb1k1nr/pppp1ppp/5q2/4p3/P1P5/b7/1PQPPPPP/RNB1KBNR w KQkq -
1637710540
rnb1k1nr/pppp1ppp/8/2b1p1q1/P7/6R1/1PPPPPPP/1NBQKBNR w Kkq -
1188224142
rnb1k1nr/ppppbppp/8/4p3/3P3q/BP6/P1P1PPPP/RN1QKBNR w KQkq -
1123877293
rnb1kb1r/pp1ppppp/1q3n2/2P5/8/8/PPPNPPPP/R1BQKBNR w KQkq -
564361197
I did this test very fast so it may contain errors although i do not expect them. Good luck!
rbarreira wrote:
The problem that I'm thinking of is two users who are in fact the same person sending matching results for a work unit they did not calculate at all. This is the easiest cheat I can think of, if it's possible then it's really easy to be malicious.
It's not possible to 100% prevent that two results end up with the same user, he could use different IP and accounts etc.. (unless the screening process is a lot more strict somehow) but I think that if
1) a user can only send a result to a work unit assigned to him and
2) the verification unit is not sent out until the first result has been returned.
So technically it is still possible to cheat but you'd be taking a risk since you cannot be certain if you corrupt a package that you will also get the verification package, and if you don't you will get detected and exposed. So in a way probability is against the cheater the more honest clients there are. And I think that if we get massive amounts of wrong results we will know that someone out there is not playing fair and simply redo all their work.
I agree that measure 1) is necessary, and some variation of 2) may also be a good idea (there has to be some timeout on the assignment otherwise someone who stops contributing would be hogging their unfinished work units forever).
Right true, but then you can no longer accept that particular result from that particular user, otherwise he could just wait for the timeout.
I'm not sure I understand your point. My idea was that the server would not accept results for a timed out work unit (i.e. after the timeout the server forgets that this work unit was assigned to that user). Does this address your concern?
Don wrote:
The point is that I'm not approaching this from the point of view of trying to build an impregnable fortress. This is a cooperative perft project. I'm not going to try to seal off every possible window and door or I would be at this forever ....
I agree that there has to be some limit to the effort expended on security, but in my opinion, the measures that I and Sune are discussing have a high return-on-investment as they're (probably) not so hard to implement and close off a basic vulnerability.
To be honest I can't imagine any security feature that is more important than this in a distributed computing project, but then again I'm not a security expert and maybe my imagination is failing me.
rbarreira wrote:
The problem that I'm thinking of is two users who are in fact the same person sending matching results for a work unit they did not calculate at all. This is the easiest cheat I can think of, if it's possible then it's really easy to be malicious.
It's not possible to 100% prevent that two results end up with the same user, he could use different IP and accounts etc.. (unless the screening process is a lot more strict somehow) but I think that if
1) a user can only send a result to a work unit assigned to him and
2) the verification unit is not sent out until the first result has been returned.
So technically it is still possible to cheat but you'd be taking a risk since you cannot be certain if you corrupt a package that you will also get the verification package, and if you don't you will get detected and exposed. So in a way probability is against the cheater the more honest clients there are. And I think that if we get massive amounts of wrong results we will know that someone out there is not playing fair and simply redo all their work.
I agree that measure 1) is necessary, and some variation of 2) may also be a good idea (there has to be some timeout on the assignment otherwise someone who stops contributing would be hogging their unfinished work units forever).
Right true, but then you can no longer accept that particular result from that particular user, otherwise he could just wait for the timeout.
I'm not sure I understand your point. My idea was that the server would not accept results for a timed out work unit (i.e. after the timeout the server forgets that this work unit was assigned to that user). Does this address your concern?
The server does not maintain connections and it does not know who was assigned or when it was assigned. it gets the assignment then exits. When it's posted then I check the credentials. So all I'm saying is that what seems easy requires yet another protocol change, more bookeeping and so on. This was designed for the specific purpose of getting the work done and to be as simple and troublefree as possible - but it's gradually becoming an exercise in security instead of perft. I'm check summing the binaries, authenticating the user, having files that store passwords and such and it's not what I really had in mind for this. It's one of those things that when I do one thing I want to do "just one more" thing which then leads to "why not go ahead and do this too" and so on. I feel the same way you do about this because no matter what I do I can imagine another security hole. But this is perft, not an exercise in cryptography security and not a banking application.
Don wrote:
The point is that I'm not approaching this from the point of view of trying to build an impregnable fortress. This is a cooperative perft project. I'm not going to try to seal off every possible window and door or I would be at this forever ....
I agree that there has to be some limit to the effort expended on security, but in my opinion, the measures that I and Sune are discussing have a high return-on-investment as they're (probably) not so hard to implement and close off a basic vulnerability.
To be honest I can't imagine any security feature that is more important than this in a distributed computing project, but then again I'm not a security expert and maybe my imagination is failing me.
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
We finished the calculation, but most of the way through one of the authors of the binaries realized there was a serious hashing bug. But that was a big part of the reason to do this trial run, to shake out bugs.
The bug affects a tiny fraction of the positions and of course made the calculation incorrect. We have now correct some of the results and are doing a pass, first focused on the positions run with this particular binary. As records are corrected the web page updates with the new results.
Don wrote:
The server does not maintain connections and it does not know who was assigned or when it was assigned. it gets the assignment then exits. When it's posted then I check the credentials. So all I'm saying is that what seems easy requires yet another protocol change, more bookeeping and so on. This was designed for the specific purpose of getting the work done and to be as simple and troublefree as possible - but it's gradually becoming an exercise in security instead of perft. I'm check summing the binaries, authenticating the user, having files that store passwords and such and it's not what I really had in mind for this. It's one of those things that when I do one thing I want to do "just one more" thing which then leads to "why not go ahead and do this too" and so on. I feel the same way you do about this because no matter what I do I can imagine another security hole. But this is perft, not an exercise in cryptography security and not a banking application.
Is it at least possible for the server to log who receives each work unit, or is there no authentication for that part of the protocol?
If such a log is easy to implement, at least it would be possible to (later) code a script which flags suspicious returned work by checking it against the log of submitted work.
SuneF wrote:
Right true, but then you can no longer accept that particular result from that particular user, otherwise he could just wait for the timeout.
I'm not sure I understand your point. My idea was that the server would not accept results for a timed out work unit (i.e. after the timeout the server forgets that this work unit was assigned to that user). Does this address your concern?
If by that you mean that the server will no longer accept a result from this user then yes it should work. Otherwise he could hang on to the unit, wait for a timeout and hope one of his other fake clients gets the timed-out unit. At that point he would then corrupt them both and turn in them in together. The server would end up with two results from independent users and thus a fully verified (but wrong) result.
