Author: Robert Hyatt
Date: 18:46:56 09/09/04
Go up one level in this thread
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... > >BTW, if ssh doesn't solve the artifical lag problem, then which problems exactly >does it solve? Secure encryption. _nothing_ is sent "plain-text_ whatsoever. > >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.