Author: Keith Evans
Date: 20:58:02 09/10/04
Go up one level in this thread
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.
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.