Discussion :

[GeoffreyOnRails]

Effectivement TropMDR a raison de rappeler que ma première solution ne marche que parceque l'ensemble des valeurs possibles (et même plus précisemment l'ensemble des valeurs "probables") est grand.
En revanche la deuxième ne connaît pas cette limitation.

@DonQuiche : Ta proposition ne fonctionne que si le fait de connaître les futurs jets de dés n'est pas dérangeant. En pratique, je ne suis pas sûr que ça soit le cas : dans beaucoup de jeux, même si je ne peux pas changer les dès, connaître tous les prochains lancers peut-être un avantage substantiel.

[DonQuiche]

@DonQuiche : Ta proposition ne fonctionne que si le fait de connaître les futurs jets de dés n'est pas dérangeant.

Au contraire : tant que tu n'as pas la clé privée de l'autre tu ne peux pas connaître les futurs jets de dés. Or l'accord se fait sur la clé publique avant d'échanger les clés privées.

[TropMDR]

Un système de clés asymétriques : par principe ces algorithmes sont faits pour rendre difficile l'obtention ou la falsification de la clé privée depuis une clé publique.

* A et B forgent chacun de leur côté une paire de clés.
* A et B s'échangent leurs clés publiques et conviennent de les utiliser.
* Une fois l'accord conclu, A et B fournissent les clés privées correspondantes et ils vérifient qu'elles correspondent aux clés publiques.
* En les concaténant ils obtiennent une clé qu'aucun d'entre ne pouvait anticiper dans sa globalité, quel que soit l'ordre de la transaction.
* Puis on obtient des valeurs aléatoires en hachant :
** r0 = sha512(concaténer(Xprivé, Yprivé))
** r[i+1] = sha512(r[i])

Si l'utilisation de sha512 pour chaque "jet de dé" pose un problème de performances alors on peut simplement générer r0, tronquer à la taille désirée et l'utiliser comme graine pour un générateur aléatoire non-cryptographique. Note que l'utilisation d'un hash pour r0 reste obligatoire pour évier qu'un des joueurs tire partie d'une faiblesse d'un générateur aléatoire non-cryptographique via sa moitié de bits de la clé.

Ca me parait bien complique. Plus simplement:

1. Choisis une fonction de hash cryptographique H, avec une taille de block blocksize
2. Joueur 1 choisie une valeur alleatoire V1, joueur 2, V2
3. ils echangent les hash H(V1) et H(V2)
4. Une fois les hash echanges, ils echangent les valeurs
5. Tu seed un generateur alleatoire avec H(V1 + V2), ou + est soit concatenation soit un XOR

[DonQuiche]

Ca me parait bien complique. Plus simplement:

1. Choisis une fonction de hash cryptographique H, avec une taille de block blocksize
2. Joueur 1 choisie une valeur alleatoire V1, joueur 2, V2
3. ils echangent les hash H(V1) et H(V2)
4. Une fois les hash echanges, ils echangent les valeurs
5. Tu seed un generateur alleatoire avec H(V1 + V2), ou + est soit concatenation soit un XOR

Nos deux solutions sont comparables : un processus en deux temps où l'accord se fait sur une valeur dérivée de la valeur finale qui, elle, restera masquée jusqu'à l'accord. Ce n'est donc pas plus compliqué. La seule différence est que je propose d'utiliser une paire clé privée/publique là où tu proposes d'utiliser une paire message/hachis.

Or dans ce cas présent une paire de clés sera beaucoup plus robuste et laissera moins de place au doute : il est plus facile de créer une paire de valeurs satisfaisant la contrainte recherchée que de créer une valeur dérivée d'une autre (le message). Pas besoin de se demander s'il faut un sel, comment choisir ce sel, si ce sel affaiblit le hachis, si le message affaiblit le hachis (interaction entre deux fonctions cryptographiques : celle utilisée pour générer le message et celle pour le hacher), ou de redouter la pelletée d'attaques possibles dans ce cas.

La paire de clés c'est l'application bête et méchante d'un problème P dont la réciproque est NP. Et c'est exactement ce qu'il faut ici. Le hachage n'est pas un choix approprié dans ce cas : il le serait si le message était imposé.

[GeoffreyOnRails]

Au contraire : tant que tu n'as pas la clé privée de l'autre tu ne peux pas connaître les futurs jets de dés. Or l'accord se fait sur la clé publique avant d'échanger les clés privées.

Nous nous sommes peut-être mal compris, mais j'avais l'impression qu'une fois les clés échangées, tu te servais de ça pour tirer tous les futurs jets de dés (les r[i+1])
Or, une fois l'échange de clés et le premier jet de dés résolu (r[0]), tu obtiens toutes les valeurs r[i] avec i>0 des futurs jets. Si il y a des actions entre temps, il faut donc ré échanger une paire de clés.

[DonQuiche]

Nous nous sommes peut-être mal compris, mais j'avais l'impression qu'une fois les clés échangées, tu te servais de ça pour tirer tous les futurs jets de dés (les r[i+1])
Or, une fois l'échange de clés et le premier jet de dés résolu (r[0]), tu obtiens toutes les valeurs r[i] avec i>0 des futurs jets. Si il y a des actions entre temps, il faut donc ré échanger une paire de clés.

Oui mais c'est aussi le cas avec ta solution : c'est propre au fonctionnement d'un générateur pseudo-aléatoire dont toutes les valeurs sont prévisibles depuis la graine (seed). Et c'est d'ailleurs nécessaire pour que l'autre joueur puisse vérifier que son partenaire ne triche pas avec les valeurs tirées.

Tu pensais que le jet dépendait du temps ? En fait c'est seulement la graine par défaut qui est en général dérivée de l'heure à l'initialisation. Et de toute façon même si le temps était utilisé systématique (vie une synchronisation), le résultat resterait prévisible.

Si j'ai précisé la façon dont on tirait les valeurs suivantes c'est parce qu'il faut faire attention en imbriquant les fonctions cryptographiques. Or si tu calcules le hachis avec une fonction H1 et que tu génères les valeurs aléatoires avec une fonction H2 tu te retrouves à imbriquer H1 et H2. La seule différence entre nos deux solutions est que tu n'utilises pas de système cryptographique et que tu ne t'es pas soucié du risque posé par l'imbrication. Mais à part ça le principe reste le même : une graine dont seront tirées les valeurs suivantes.