Author: Keith Evans
Date: 19:24:53 09/11/04
Go up one level in this thread
On September 11, 2004 at 10:19:55, Robert Hyatt wrote: >On September 10, 2004 at 23:58:02, Keith Evans wrote: > >>On September 10, 2004 at 17:10:53, Robert Hyatt wrote: >> >>>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? >> >>I was only addressing the x86 issue. But maybe something could be done with Java >>that would be more portable. I think that people would be most concerned with >>security, portability, and of course ease of setup and use. If you choose telnet >>then you give up security (referring to eavesdropping and taking over >>connections, not executing arbitrary code on your computer) and probably ease of >>use, but you sure get portability. > > >You are not completely addressing the X86 issue. I run linux. Your windows >executable will not work here. My linux executable will not work there. Even >different versions of the O/S don't "share" executables completely. It is a >_huge_ problem.. I said a virtual machine like Java, not x86 code.
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.