Re: computer-go: Authenticating the identity of a remote go-playingcomputer program

[Mika Kojo <mkojo@xxxxxxx>]

Don Dailey writes:
> 
> I think  I  was  accused of  over-engineering,  but I   think  Nicol's
> solution is more than good enough.  It's one of  many possible ways to
> handle time control,  there are also  ones that can be managed locally
> that won't severly cripple your program.
> 
> If  we really wanted  to get paranoid,  we  could use secure protocols
> that are in common use already for network communication.
> 
> No one claimed any of  this was easy, but  it's easy to  make it a lot
> more  commplicated than   it needs  to be by   requiring  more than is
> necessary.

My point was that Nicol's approach is not secure. It indeed makes
cheating rather easy (at least in theory).

Example. Suppose programs are allowed to query once per move the
current time from the server. By keeping local timer the program can
look at the most significant digits of the time and request a server
to record that time when it wishes. Thus if the 7-dan is quick enough
(say, 1 minute per move) then the program just queries at the right
moment to encode the move. Now, when the organizers verify the winner,
which showed remarkable 7-dan ranking, the program just instantly
queries the move from the server and outputs it. Perhaps organizers
are slightly surprised by the fact that the program is so quick now,
but the programmers just state that they runned it on slow machine at
the tournament. 

If the protocol is wanted to be secure, then the method of tracing the
programs execution does not work. (Except in the case where the
tournament program and the program used in verification are exactly
same.)

Usual cryptographical protocols can guard against external cheaters
(e.g. who intercept the connection between the server and the
tournament program), but not against cheating Go playing programs.

-- 
Mika Kojo
SSH Communications Security Corp