Simulateur épuisant de protocoles sans connaissances dans le modèle Oracle aléatoire

Dans un article intitulé «Sur le déni dans la chaîne de référence commune et le modèle Oracle aléatoire», Rafael Pass écrit:

Nous notons que lors de la démonstration de la sécurité selon la définition standard de la connaissance zéro dans le modèle RO [Oracle aléatoire], le simulateur a deux avantages par rapport à un simulateur de modèle simple, à savoir:

1. Le simulateur peut voir sur quelles valeurs les parties interrogent l'oracle.
2. Le simulateur peut répondre à ces requêtes de la manière qu'il souhaite tant que les réponses "semblent" OK.

La première technique, à savoir la capacité de «surveiller» les requêtes au RO, est très courante dans tous les articles faisant référence au concept de connaissance zéro dans le modèle RO.

Maintenant, considérons la définition de la connaissance zéro de la boîte noire ( PPT signifie machine de Turing probabiliste à temps polynomial ):

un simulateur PPT S , tel que ∀ (éventuellement tricher) vérificateur PPT V ∗ , ∀ entrée commune x ∈ L et ∀ caractère aléatoire r , les éléments suivants ne peuvent pas être distingués:$\exists$$S$$\forall$$V^*$$\forall$$x\in L$$\forall$$r$

• la vue de en interagissant avec le prouveur P sur l'entrée x et en utilisant l'aléatoire r ; $V^*$$P$$x$$r$
• la sortie de sur les entrées x et r , lorsque S a accès à la boîte noire à V ∗ . $S$$x$$r$$S$$V^*$

Ici, je veux montrer un vérificateur de triche , dont le travail consiste à épuiser tout simulateur qui essaie de surveiller les requêtes RO:$V'$

Soit le simulateur garanti par le quantificateur existentiel dans la définition de la connaissance zéro de la boîte noire, et q ( | x | ) un polynôme qui limite le temps de fonctionnement de S sur l'entrée x . Supposons que S essaie de surveiller les requêtes de V ∗ au RO.$S$$q(|x|)$$S$$x$$S$$V^*$

Maintenant, considérons un triche , qui interroge d'abord le RO pendant q ( | x | ) + 1 fois (sur des entrées arbitraires de son choix), puis agit arbitrairement avec malveillance.$V'$$q(|x|)+1$

De toute évidence, épuise le simulateur S . Un moyen simple pour S est de rejeter un tel comportement malveillant, mais de cette façon, un différenciateur peut facilement distinguer l'interaction réelle de l'interaction simulée. (Étant donné que dans l'interaction réelle, le prouveur P ne peut pas surveiller les requêtes de V , et ne rejettera donc pas en raison du simple fait que V ' interroge trop.)$V'$$S$$S$$P$$V'$$V'$

Quelle est la solution de contournement pour le problème ci-dessus?

Éditer:

Une bonne source pour étudier ZK dans le modèle RO est:

Martin Gagné, Une étude du modèle Oracle aléatoire, Ph.D. Thèse, Université de Californie, Davis , 2008, 109 pages. Disponible sur ProQuest: http://gradworks.umi.com/33/36/3336254.html

En particulier, il donne des définitions de la boîte noire ZK dans le modèle RO dans la section 3.3 (page 20), attribuée à Yung et Zhao:

Moti Yung et Yunlei Zhao. Zero-Knowledge interactif avec des oracles aléatoires restreints. Dans Theory of Cryptography - TCC 2006 , LNCS 3876, pp. 21-40, 2006.

La question se pose de savoir pourquoi on voudrait définir la boîte noire ZK dans le modèle d'oracle aléatoire. Il y a au moins deux raisons pour lesquelles les gens ont suggéré la définition de la connaissance zéro de la boîte noire:

1) Pour un résultat positif, lorsque vous dites qu'un simulateur est une "connaissance zéro de la boîte noire", il vous donne automatiquement une belle limite sur son temps de fonctionnement (c'est-à-dire, par opposition à p o l y ( t i m e ( V ∗ ) ) ) et il peut également être utile de savoir que le simulateur ne "regarde pas les tripes" de V ∗ et ne se soucie pas si V $poly(|x|) \cdot time(V*)$$poly(time(V*))$$V*$$V*$est implémenté en utilisant de la RAM, un circuit, etc ... Alors qu'un simulateur de modèle à oracle aléatoire peut être efficace, ce n'est évidemment pas une boîte noire, car il est censé en quelque sorte regarder l'exécution de et comprendre à partir de cela lorsque V ∗ évalue une fonction de hachage. Pour cette raison, il y a un sens dans lequel il n'est pas logique de dire qu'un simulateur de modèle d'oracle aléatoire est une "boîte noire".$V*$$V*$

2) Pour un résultat négatif, les gens utilisent un "simulateur de boîte noire" pour capturer une grande classe de techniques de preuve. Dans ce cas, vous pouvez également définir le simulateur de boîte noire dans le modèle d'oracle aléatoire et la définition qui a du sens est ce que David a dit. En fait, pour un résultat négatif même pas dans le modèle de l' oracle aléatoire, il est préférable si le résultat reste valable même si vous permettez le simulateur durée. En effet, bien que cela ne soit pas toujours énoncé, les résultats négatifs que je connais ont tous cette propriété, puisque le vérificateur de triche V $poly(time(V*))$$V*$ est généralement un algorithme polynomial fixe qui exécute certaines fonctions pseudo-aléatoires, tandis que le simulateur peut avoir n'importe quel temps d'exécution polynomial.

Voici mon point de vue sur le problème. Je n'ai récemment lu aucun article traitant de la connaissance zéro de la boîte noire dans le modèle de l'oracle aléatoire (RO), donc je ne fais que deviner ce qu'ils signifient et non ce qui y est écrit. La réponse courte (supposition) est que BB-ZK dans le modèle RO devrait laisser le simulateur fonctionner en polynôme temporel dans | x | et le nombre de requêtes RO émises par V *, le vérificateur de triche.

Essayons de justifier cette supposition. Une première observation est que le terme "preuves de connaissances nulles de boîte noire dans le modèle d'oracle aléatoire" doit être examiné de plus près pour être correctement défini. Les simulateurs de boîte noire sont définis pour fonctionner avec n'importe quel oracle (c'est-à-dire, le vérificateur de triche en tant que boîte noire), et leur seule interface est via l'entrée / sortie oracle. Si nous augmentons simplement ce modèle pour donner un RO à toutes les parties (peut-être en permettant à leurs circuits d'avoir des portes RO), alors nous obtenons un modèle où le simulateur ne peut pas programmer le RO - sur une requête Oracle, tout (y compris les requêtes RO) juste se produit "à l'intérieur" de l'oracle V *, puis il renvoie son message suivant. Si nous voulons autoriser la programmation RO, alors nous devons modifier les interfaces: Le simulateur obtient maintenant un oracle d'entrée / sortie pour V * et pas d'oracle aléatoire. À chaque appel vers l'oracle V *, au lieu de produire le message suivant, l'oracle peut à la place produire la requête suivante au RO, et le simulateur peut lui donner la réponse du RO en appelant à nouveau l'oracle. Maintenant, cela permet la programmation du RO, et nous pouvons également permettre au temps de fonctionnement du simulateur de dépendre du nombre de requêtes au RO.

Toute autre exploration de la signification de ces définitions est laissée au lecteur. Je pense syntaxiquement.