Author: Robert Hyatt
Date: 14:10:53 09/10/04
Go up one level in this thread
On September 10, 2004 at 11:37:39, Keith Evans wrote: >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? OK. I am going to connect via telnet. How is that going to work?
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.