Author: Robert Hyatt
Date: 21:33:49 09/11/04
Go up one level in this thread
On September 11, 2004 at 22:24:53, Keith Evans wrote: >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. OK. With Java, you need a VM to run it. The problem is that too many clients won't deal with that at all. IE basic "telnet chessclub.com 23". How to inject a Java upload in there? If you stipulate a specific client, you become playchess.com which I consider to be 100% worthless since I can't run the fritz GUI here on linux, nor would I want to. I don't see how a dynamic client upload can work. Period.
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.