Author: Sam S
Date: 14:54:45 09/09/04
Go up one level in this thread
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. 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. BTW, if ssh doesn't solve the artifical lag problem, then which problems exactly does it solve? I wonder whether this idea of using a one-time executable code at the beginning of each game can solve the artifical lag problem, in the sense that it'd be too hard to break it before each game starts by finding out of how this one-time code works and where it calls the OS to get the time etc., so even though in theory it could somehow be broken, in practice it wouldn't be possible to do fast enough. Thanks.
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.