Author: Sam S
Date: 03:33:16 09/10/04
Go up one level in this thread
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. I'm also interested about other ideas to handle this? I.e. ideas that'd handle the specific issue where a client can report a fake timestamp while in fact the player spend move time on the move (since seeing the opponent's move) than the client is reporting. (I realize that it's not possible to solve the artifical lag that you can introduce which is the same as real network lag.) > > > > >> >>BTW, if ssh doesn't solve the artifical lag problem, then which problems exactly >>does it solve? > >Secure encryption. _nothing_ is sent "plain-text_ whatsoever. > You mean for credit cards etc. on ICC? Or can ssh help with regard to the specific issue of timestamps? > > >> >>I wonder whether this idea of using a one-time executable code at the beginning >>of each game can solve the artifical lag problem, in the sense that it'd be too >>hard to break it before each game starts by finding out of how this one-time >>code works and where it calls the OS to get the time etc., so even though in >>theory it could somehow be broken, in practice it wouldn't be possible to do >>fast enough. >>Thanks.
This page took 0.01 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.