[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



   There is no way to authenticate a program running remotely.  
   In fact, there's no way to authenticate a program running locally
   to not be receiving instructions through some covert channel.

No,  actually we can  authenticate   programs  remotely, it's only   a
question of how practical is this.  First of all,  we have to view the
game played  as a kind of "signature"  identifying a program.   In the
same way that a cryptographic signature  is based on the very unlikely
possibility that  two keys will  "sign" to the  same value, we can say
that  a program's signature    is  based  on the  extremely   unlikely
possibility that any other  program will play  ALL the same   moves as
some other program will.  This is EXTREMELY unlikely, so the rest is a
"small" matter of protocol but how do you set this up?

First of all, you must checksum your executable (in a crytographically
secure way.)  Your program must be deterministic in the sense that you
can identify  and checksum the state of  your  program BEFORE you have
access to  each of your   opponents replies.  Taken together,  with  a
move,  you have encapsulated  everything needed  to (weakly) sign each
move.   Each move your   program   makes is a cryptographically   weak
"signature."  But 100  moves   put together is  an   incredibly strong
signature, which is (at least in the cryptographical sense) proof that
the set of moves indeed belong to your program.

In practice, this is a royal pain  to implement, and it seems unlikely
we will be seeing  it done.  It may  be much more difficult with  some
programs that others   due to several technical  implementation issues
that I won't go into but it's certainly not an impossible task either,
any good programmer  could implement  the protocol  if the  effort was
deemed worthwhile.

The programs would not have to be sent to an arbiter, unless a disptue
occured.   Then the program  itself along with  any and  all the state
captured in  advance by the  referee  program watching  the game  will
prove or disprove whether a program is authentic.

There are other problems this doesn't neccesarly address.  One of them
is that we have to view the hardware a program runs on  as part of the
programs "state" if  the program itself  takes advantage of additional
memory (for instance.)  And what if I take  YOUR program and represent
it as my  own?  Using  the method I   just  outlined, I can give   the
arbiters a version that checks out fine in every way.  However if this
was every suspsected, then other methods could  be used to resolve the
matter (like, let's see your source code you cheater!!)

In practice, I don't see this as ever happening unless the process can
be greatly simplified.  In principle, however, full authentication can
be achieved and requires no technology we don't  already have, so it's
implementable right now.

Don