Houdini tempted to participate in the coming WCCC in Tilburg

[JcMaTe]

I have read on talk chess that Robert Houdart is tempted to participate in the coming WCCC in Tiburg

[Jeremy Bernstein]

I have read on talk chess that Robert Houdart is tempted to participate in the coming WCCC in Tiburg

He should definitely give it a shot. I would love for the derivative origins of Houdini to be officially established once and for all.

Jeremy

[JcMaTe]

If houdini participate .. have to be free and open-source chess engine for all ?

[hyatt]

If houdini participate .. have to be free and open-source chess engine for all ?

No, but it has to be proven to be original, since there has been quite a bit of evidence posted (Chris Conkie comes to mind first) showing way too much similarity between Houdini and Robo*. I don't believe it can pass that test.

[kingliveson]

I have read on talk chess that Robert Houdart is tempted to participate in the coming WCCC in Tiburg

He should definitely give it a shot. I would love for the derivative origins of Houdini to be officially established once and for all.

Jeremy

[BB+]

For my two cents (maybe I should start a new thread): is the WCCC too long? How many people can easily take a whole week off to "operate" their entry for 9 days [Friday-Saturday]? [And how many consider this a desirable "vacation"?] Given that there will likely be few/zero participants from the Americas [maybe Zach, maybe others, I obviously don't know], having it just be (say) 5 days long probably won't lead to any complaints about such a short stint not being worth the travel effort. Having it be a (very) long weekend might(?) lead to greater participation. The "statistical significance" of 9 or 11 games versus something like 7 can't be that great, though having a round-robin (if possible) is always nice in that everyone gets to play the champion. Of course, there are counter-arguments, but I just wanted to know if anyone had an opinion.

[hyatt]

It has been too long for years. It used to be much shorter, then the ICCA got involved with the WMCCC event, which was primarily commercial, they charged the company a ton and allowed them to submit multiple entries, and they turned that into a vacation. If you look at locations like Jakarta, and such, it is really a 14 day deal. You have to allow two days on either end to arrive and set things up and test whatever hardware you take or allow someone to provide. Too long, period... A 5 day (max) event could work, if it were held in reasonably accessible locations (Major European or North American cities.) Otherwise I don't see how I will ever be able to participate in one again, and even taking a week off from classes is asking a lot...

[BB+]

The question of how to deal with encrypted binaries for future ICGA perusal, etc., was also raised. Here is one scheme (the practical details are a bit different, but the software to implement such a protocol should be easy to develop in a transparent manner).

1. Entrant generates a public/private key pair. [Need some conditions about whose responsibility it is to choose "safe" parameters, but there are many available places to get pair-generation code].
2. Entrant encrypts code (either source or executable) with public key, sends encrypted code E and public key to ICGA.
3. ICGA thinks of a random number R (maybe a hash), and encrypts R with the given public key.
4. ICGA appends this encrypted random number to the encrypted code E and sends this (call it Z) back to the entrant.
5. Entrant applies private key to Z, getting the original unencrypted code with the random number R appended.
6. Entrant checks the decryption worked (e.g., the unencrypted code is indeed recovered), and sends R to ICGA.

At a later date, ICGA makes a demand of the entrant.
7. Entrant sends private key to the ICGA. If the entrant lost this, too bad. [The fact that R was sent to ICGA shows that the private key must have existed and worked at some point].
8. ICGA applies private key to the encrypted code E (or to Z, it doesn't matter). If garbage comes out, it's the entrant's own fault, as sending R back to the ICGA was a promise that the private key did in fact work.

I leave out any "authentication" issues between the ICGA and the entrant knowing they are really talking to each other (and not to a snooper). The practical details also need thought, as usually one encrypts/decrypts by blocks (of 1K size, perhaps), and so one might want to (say) make some pre-determined reversible scrambling in a couple of steps, so that the ICGA-generated R would affect each block.

[kingliveson]

The question of how to deal with encrypted binaries for future ICGA perusal, etc., was also raised. Here is one scheme (the practical details are a bit different, but the software to implement such a protocol should be easy to develop in a transparent manner).

1. Entrant generates a public/private key pair. [Need some conditions about whose responsibility it is to choose "safe" parameters, but there are many available places to get pair-generation code].
2. Entrant encrypts code (either source or executable) with public key, sends encrypted code E and public key to ICGA.
3. ICGA thinks of a random number R (maybe a hash), and encrypts R with the given public key.
4. ICGA appends this encrypted random number to the encrypted code E and sends this (call it Z) back to the entrant.
5. Entrant applies private key to Z, getting the original unencrypted code with the random number R appended.
6. Entrant checks the decryption worked (e.g., the unencrypted code is indeed recovered), and sends R to ICGA.

At a later date, ICGA makes a demand of the entrant.
7. Entrant sends private key to the ICGA. If the entrant lost this, too bad. [The fact that R was sent to ICGA shows that the private key must have existed and worked at some point].
8. ICGA applies private key to the encrypted code E (or to Z, it doesn't matter). If garbage comes out, it's the entrant's own fault, as sending R back to the ICGA was a promise that the private key did in fact work.

I leave out any "authentication" issues between the ICGA and the entrant knowing they are really talking to each other (and not to a snooper). The practical details also need thought, as usually one encrypts/decrypts by blocks (of 1K size, perhaps), and so one might want to (say) make some pre-determined reversible scrambling in a couple of steps, so that the ICGA-generated R would affect each block.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

To be clear, this is not talking about an obfuscated binary/executable, but rather the particular engine that competes in a given tournament. So more or less, an archive. If such be the case, I don't understand the need for sending private keys.

Why couldn’t both the entrant and ICGA generate a key pair and make available the public key?! This way, the entrant can send a signed/encrypted competing engine to the ICGA which then can only be decrypted by the intended receiver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iQIcBAEBAgAGBQJOEctfAAoJEMw1ELMg7SBqZZ0P/iCX/49pGucRM1BOo19AM2I0
r//DSbt3FKd/qHK2ZlhjSiBO9d2aKuIjIvU/3b3XLTcEtqT5lpr1tpEYKLrFsoV/
VJhBjnufV50sAoAze6xgWfFNFx5uZa/tSmti9qEdTY3/lQDhOVmX/0oicVBarMPf
Y/OqhxarMc4HC2+yOVhYGCHekB9NmXavrfEBD1kJGM+1kVgAXhqpZLM10zkIrjjv
6QGNI0Bjiyaof4rojGOvfsWdmSiEXhPMtiid97ejqmL9Wfjp0K2Q9TzEPXHr+taW
6+P6tWLH0+Yw9qZclKmTGZ7nBoW8MkdbG7+WAfPFVgfJp03IjoNRkAY2YhX5vfjl
SmMZuPM1RuM6WBfW5nH0fg3nlaeo9O5uLd1xSUpb0B9Faz0l78po/WeSK7iQkkDz
J+ARjaJ0mLnAIZIXfUFFTkuMSLtSbzSUwThiWRJl2fdz1RUui1/VbXz+F8v/NSyk
17RyfMDT558vNF0jqxEOSCEyl+qM6NJQD7zXdYUuDQBKpjKnKcURoHbHpUwOxoFj
FkPChhvxQzjfPn/jK6WsC05qbuX+UShO/mpW+kIy4UXYM6pBRaaKzl8ynqcWjAjV
MOGiqgAaBcrqN+Azc4C9jiRc0Obq43pmbWxaOQ3nzNzPkz4AQXRtOD9UieHcgVoR
AaowyWCR4pAzUNrmhqWw
=qgLY
-----END PGP SIGNATURE-----

[hyatt]

The question of how to deal with encrypted binaries for future ICGA perusal, etc., was also raised. Here is one scheme (the practical details are a bit different, but the software to implement such a protocol should be easy to develop in a transparent manner).

1. Entrant generates a public/private key pair. [Need some conditions about whose responsibility it is to choose "safe" parameters, but there are many available places to get pair-generation code].
2. Entrant encrypts code (either source or executable) with public key, sends encrypted code E and public key to ICGA.
3. ICGA thinks of a random number R (maybe a hash), and encrypts R with the given public key.
4. ICGA appends this encrypted random number to the encrypted code E and sends this (call it Z) back to the entrant.
5. Entrant applies private key to Z, getting the original unencrypted code with the random number R appended.
6. Entrant checks the decryption worked (e.g., the unencrypted code is indeed recovered), and sends R to ICGA.

At a later date, ICGA makes a demand of the entrant.
7. Entrant sends private key to the ICGA. If the entrant lost this, too bad. [The fact that R was sent to ICGA shows that the private key must have existed and worked at some point].
8. ICGA applies private key to the encrypted code E (or to Z, it doesn't matter). If garbage comes out, it's the entrant's own fault, as sending R back to the ICGA was a promise that the private key did in fact work.

I leave out any "authentication" issues between the ICGA and the entrant knowing they are really talking to each other (and not to a snooper). The practical details also need thought, as usually one encrypts/decrypts by blocks (of 1K size, perhaps), and so one might want to (say) make some pre-determined reversible scrambling in a couple of steps, so that the ICGA-generated R would affect each block.

I much prefer the idea that someone posted a link to in these very discussions. One can create an encryption key of length N (in bits). One can then divide this key up into (say) 5 pieces, and use a pretty clever algorithm (in the link I mentioned) so that you end up with (say) 8 pieces of key. But you only need any 5 of them to reproduce the original key.

The benefit is that the original source is encrypted using the given key. The given key is then broken into the 5 pieces, which is expanded to 8 pieces and given to 8 members of an investigative group. If a question arises, it takes at least 5 of the key fragments to recover the complete key, meaning that one person could not decrypt the source by himself... this also prevents the author from "losing" anything should push come to shove.