Author: Robert Hyatt
Date: 07:19:55 09/11/04
Go up one level in this thread
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..
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.