Author: Keith Evans
Date: 08:37:39 09/10/04
Go up one level in this thread
On September 10, 2004 at 11:19:39, Robert Hyatt wrote: >On September 10, 2004 at 06:33:16, Sam S wrote: > >>On September 09, 2004 at 21:46:56, Robert Hyatt wrote: >> >>>On September 09, 2004 at 17:54:45, Sam S wrote: >>> >>>>On September 09, 2004 at 10:40:22, Robert Hyatt wrote: >>>> >>>>>On September 09, 2004 at 00:44:57, Sam S wrote: >>>>> >>>>>> >>>>>>>It's a yawn in that the weaknesses have been known for a long time. There are >>>>>>>solutions to much of the problem, using the sort of challenge-response stuff >>>>>>>used in ssh (secure shell) access. But artificial lag is simply impossible to >>>>>>>get rid of... >>>>>> >>>>>>How about this idea: at the beginning of each game, the server generates a >>>>>>one-time executable code and sends it to the client, and for each move this >>>>>>executable code would send back to the server a signature created from (current >>>>>>move, current move number, time spent on making this move) along with the move >>>>>>and time-spent data, so that the server can authenticate this signature for each >>>>>>move. >>>>>>It'd be possible to break each specific one-time executable code that the server >>>>>>sent by finding out how it encrypts the signatures, but if the server generates >>>>>>new executable codes that are completely different from one another for each >>>>>>game before the game starts, it'd be too hard to break in such short amounts of >>>>>>time... >>>>> >>>>> >>>>>Not so easy. How would you generate an executable for a sparc, a cray, a X86, >>>>>and IA64, a HPPA, a MIPS, etc. Particularly when you can't easily find out what >>>>>is on the other end? >>>>> >>>>>ssh has solved this problem. It is open-source. That challenge-response >>>>>approach could easily be used to deal with this. >>>> >>>>With regard to different CPUs, the server could query the client and see under >>>>which CPU it is running, and the client would have to answer if it wants to use >>>>timestamps. But let's assume that there's only one kind of CPU involved, in >>>>order to simplify. >>> >>>What client is it going to query. You can connect to ICC with xboard. Or a >>>plain ascii telnet session. Or with a custom interface you can write (I have >>>one I wrote in fact). There's no way to be sure the "client" will know how to >>>respond, much less how to ask it anything not knowing what it is... >>> >>> >>>> >>>>You said it yourself that ssh doesn't solve the artifical lag issue. It'd be >>>>possible to hack the client and find out where it calls the OS to get the >>>>current time, and modify it so it'd report fake timestamps, while using ssh. >>> >>> >>>I can introduce false lag easily without touching the client software. That is >>>a TCP/IP issue... >>> >> >>Under this idea of one-time executable codes: when the server sends a new move >>to the client, it is encrypted so that only the one-time executable code can >>read it, and record the time when it was received. Therefore, when the client >>would send a move with a timestamp back to the server, if for example the >>timestamp says that the client spent 5 seconds on the move, you can be sure that >>from the moment the client saw his opponent's move that the server sent him, >>until the moment he chose his move in reply to his opponent's move, exactly 5 >>seconds have passed. >>I agree that you can introduce false lag that would give the client more time to >>think e.g. after he made his move and before receiving his opponent's move, but >>this false lag would be the same as if there was real network lag. There's no >>difference between this artifical lag that you introduce and a situation where >>your network really lags. This also means that this kind of false lag would give >>both players the same amount of time to think on their moves, except that you >>are the one who controls what would be to extra time with the artifical lag that >>you'd introduce. On the other hand, currently in ICC the situation is that the >>client can cheat and give a fake timestamp, so for example when it reports to >>the server that it spent 5 seconds on a move, and the servers receives this data >>after 10 seconds, it could be that the client cheated and it actually spent e.g. >>9 seconds on the move and reported it as 5 seconds, and in this situation it's >>not true that both players would have the same amount of time to think on their >>moves. >>So from what I understand, the articial lag you can introduce with TCP/IP would >>be just as if you were on a network with a real lag problem, but providing a >>solution to the problem where the client can cheat and say that he spent less >>time on a move (from the moment he saw his opponent's move) does have >>importance. >>So I'm still interested to know if this one-time executable codes can be a good >>way to handle this, again if we simplify and assume there's only one CPU >>involved, e.g. only x86 for the blitzin client. > > >If you want to totally exclude any OS but windows, any CPU but X86, and any >end-point client but blitzin, then the idea _could_ work. But they would >instantly lose a significant part of their customer base, which would make it a >bad business decision. How about using a virtual machine language?
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.