Vérification de l'équivalence d'un secret

voix
4

Alice et Bob sont deux agents secrets quadruple qui pourraient travailler pour les Etats-Unis, la Russie ou la Chine. Ils veulent trouver un système qui:

  1. S'ils travaillent tous les deux pour le même côté, prouver les uns aux autres afin qu'ils puissent parler librement.

  2. Si elles travaillent pour différents côtés, pas exposer des informations supplémentaires sur quel côté ils sont.

Oh, et à cause de la nature sensible de ce qu'ils font, il n'y a pas de tiers de confiance qui peut faire la comparaison pour les deux.

Quel protocole serait en mesure de satisfaire ces deux besoins?

Idéalement, tout protocole serait également en mesure de généraliser à plusieurs participants et multiples états, mais ce n'est pas essentiel.

Je suis perplexe sur elle pendant un certain temps et je ne peux pas trouver une solution satisfaisante, principalement en raison de la condition 2.

edit: Voici le problème original qui m'a motivé à chercher une solution. « Charlie » avait quelques photos personnelles qu'il partageait avec moi et j'ai découvert plus tard qu'il leur avait aussi partagé avec « Bob ». Nous voulions tous les deux savoir si nous avions la même série de photos mais, en même temps, si Charlie avait partagé une certaine photo avec l'un de nous, il avait probablement une bonne raison de ne pas et nous ne voulions pas fuir information.

Ma première pensée serait pour chacun d'entre nous de concaténer toutes les photos et fournir la somme MD5. Si elles correspondent, alors que nous avions les mêmes photos mais si elles ne l'ont pas, aucune des parties ne connaîtrions que les photos avaient l'autre. Cependant, je me suis rendu peu de temps après que ce système serait encore l'information fuite parce que Bob pourrait générer un MD5 pour chaque sous-ensemble de photos qu'il avait et si l'un d'entre eux correspondait ma somme, il connaîtrait que les photos que je n'ai pas. Je n'ai pas encore trouver une solution satisfaisante à ce problème particulier, mais je pensais que je le généraliser pour éviter que les gens se concentrant sur les détails de ma situation.

Créé 26/08/2009 à 23:52
source utilisateur
Dans d'autres langues...                            


9 réponses

voix
-1

Ne fonctionnerait pas ici RSA? Chaque nation connaît sa clé privée, vous publiez votre clé publique, et seuls les pays qui sont les mêmes peuvent déchiffrer les informations. Je suppose que la deuxième personne ne sait que le premier n'est pas du même côté car ils sont, cependant.

Hmm.

Créé 26/08/2009 à 23:57
source utilisateur

voix
-2

Que diriez - vous Cryptographie à clé publique ?

Créé 26/08/2009 à 23:59
source utilisateur

voix
1

Donc, ils sont garantis pour être des agents quadruples? C'est qu'ils sont garantis de travailler secrètement pour une faction en prétendant travailler pour une seconde en prétendant travailler pour un tiers, tout en faisant semblant de travailler pour un quatrième? Ils sont limités à un peu aux États-Unis, la Russie ou la Chine? Si oui, alors cela signifie qu'il y aura toujours au moins une faction, ils sont à la fois faire semblant de travailler et sont en même temps travaillent en fait pour. Cela semble nier leur capacité à être des agents quadruples, parce que sûrement l'un d'entre eux ne peuvent pas travailler pour les Américains tout en travaillant secrètement pour les Américains, tout en travaillant secrètement pour les Américains, tout en travaillant secrètement pour les Américains.

Vous dites que la solution idéale serait de généraliser à un nombre arbitraire d'états et empilements d'espionnage. le degré d'agent-ness secret peut être soit supérieur, égal ou inférieur au nombre d'Etats? Cela pourrait être important. Aussi, est Alice toujours assuré d'avoir le même degré de-ness comme agent Bob? à-dire qu'ils seront toujours à la fois des agents triples, ou toujours à la fois par des agents quintuples? L'opérateur modulo vient à l'esprit ...

Plus de détails,.

En réponse potentielle, vous pouvez énumérer les états dans un champ de bits. US = 1 = 2 Russie, Chine = 4, Madagascar = 8, Touva = 16 etc construire un dispositif qui est essentiellement une porte. Alice construit et apporte une moitié et Bob construit et apporte l'autre. Séparés par un tissu, ils chaque pression sur le bouton de l'état où ils travaillent vraiment. Si la sortie de la porte est élevée, ils sont sur le même côté. Sinon, ils prennent tranquillement le tissu, et partent avec les moitiés respectives de leur machine de telle sorte que le bouton ne peut être déterminée par empreinte digitale.

Ce n'est pas théorique ou rigoureuse, mais pratique.

Créé 27/08/2009 à 00:03
source utilisateur

voix
0

Intéressant.

Je pense que, quel que soit le système, il faudra impliquer une composante de défaillance aléatoire. En effet, des exigences contradictoires. Vous auriez besoin d'un système qui, de temps en temps, même quand ils sont sur le même côté, ne fonctionne pas. Parce que si elle a toujours travaillé, ils seraient immédiatement en mesure de déterminer qu'ils ne sont pas du même côté.

Votre point 'B' est aussi vague. Vous dites que vous ne voulez pas exposer de quel côté ils sont. Est - ce que cela signifie que l'info ne peut pas indiquer plus précisément l' un des côtés? Est - il correct si Alice pense Bob est de l'un des autres?

Aussi, avez - vous essayé emailing ceci à la liste de diffusion de la cryptographie ? Peut mieux y répondre. Il est un intéressant de penser à :)

Créé 27/08/2009 à 00:21
source utilisateur

voix
0

Voici le plus proche que je suis venu à une solution:

On suppose il y a une doubleHash fonction telle que

doubleHash(a+doubleHash(b)) == doubleHash(b+doubleHash(a))

Alice génère un 62 secret bits et ajoute le code du pays 2 bits à la fin de celui-ci, et donne hash Bob doubleHash (a).

Bob fait la même chose et donne Alice doubleHash (b).

Alice ajoute le secret d'origine au hachage que Bob lui a donné son, hash et publie comme doubleHash (a + doubleHash (b)).

Bob fait la même chose et publie doubleHash (b + doubleHash (a)).

Si les deux hash correspondent, ils sont du même pays. D'autre part, si elles ne correspondent pas, alors Bob ne peut pas déchiffrer le hachage parce qu'il ne connaît pas le secret d'Alice et vice versa.

Toutefois, un tel système repose sur l'existence d'une fonction doubleHash et je ne sais pas si une telle chose est possible.

Créé 27/08/2009 à 00:28
source utilisateur

voix
1

Pour votre problème de photos, créer des hash pour tous les sous-ensembles de photos; sélectionner de manière aléatoire un sous-ensemble de ceux-ci, et mélanger dans une quantité convenue de valeurs de hachage générées aléatoirement. Bob fait la même chose, et vous échangez ces ensembles. Si la proportion de hash dans ce que Bob vous a envoyé correspondant à ceux que vous pouvez générer en hachant des sous-ensembles de vos photos diffère sensiblement de ce que vous attendez, il est probable que vous avez un corpus significativement différent de photos de lui. Si la proportion de hash au hasard vous êtes d'accord sur est élevé, vous risquez d'être incapable de détecter de petites différences dans vos collections de photos; si la proportion est faible, vous risquez d'exposer des informations sur les photos manquantes; vous devrez choisir un endroit approprié pour le compromis entre.

Créé 27/08/2009 à 00:44
source utilisateur

voix
0

La chose la plus simple que je peux penser avec les photos qui peut travailler est aussi ainsi:

  1. Hash toutes les photos avec un hachage 4096 bits.
  2. Trier les photos par valeur de hachage. (Hashes sont afterall, juste une représentation de chaîne d'un grand nombre)
  3. en utilisant cet ordre de tri, utilisez un système de diffusion en continu à la conduite et hachage, ces photos, comme si elles étaient un fichier singulier.
  4. Partagez vos hash.
  5. Si les hash correspondent, vous avez les mêmes fichiers. (Faible à faible risque de résultat positif incorrect, mais 4K hash, il est un peu improbable)

Il y a bien sûr, quelques faiblesses ici:

  1. Ne partagez pas combien de photos que vous avez. Cela pourrait permettre à la partie avec le plus grand nombre de photos faire permutation intelligente des données et supprimer des photos du hachage défini soupçonnent probable que vous n'avez pas, en utilisant le numéro de guide, et trouver (au grand esprit de frais de calcul) un ensemble d'images qui correspond à votre hachage.
  2. Ils peuvent faire 1 sans le nombre, mais son plus dur, et ils sont hors de la chance si elles ont effectivement moins de photos.
  3. Ils pourraient créer un hachage faux, simplement avec un générateur de nombres aléatoires, et vous envoyer, vous donnant l'impression que vous avait différents ensembles de données lorsque vous aviez vraiment la même chose.

Les faiblesses ci - dessus sont également répandus dans votre système d'identification de code de pays, sauf bien sûr, vous avez beaucoup moins d' entropie pour obtenir de la manière, et son beaucoup plus facile à la fraude du système. (Et donc, bien loin beaucoup plus facile de travailler qui ils sont par la force brute pure, ou avez vous - même travaillé par la force brute, quelle que soit la fantaisie de votre algorithme de hachage est) Si tel était le cas contraire , vous auriez déjà été trouvé par les mêmes agences qui vous travaillez, parce que quelque chose qui serait fiable et sûr que feu moyen de faire une vérification des antécédents sécurisé.

Créé 27/08/2009 à 02:06
source utilisateur

voix
0

Le scénario photo est impossible à réaliser:

Votre système est impossible pour les raisons que le nom que vous.

Considérons une fonction f, qui prend deux séries de photos, s1 et s2. f (s1, s2) renvoie true si s1 = s2 et faux si s1! = s2. Autrement dit, cette fonction met en œuvre le système que vous voulez.

Bob peut toujours fournir un sous-ensemble des années photo qu'il a, et d'apprendre que charlie de photo n'a pas. Il n'y a pas moyen de contourner cela, une fonction qui a la propriété que vous voulez ne peut pas avoir la sécurité que vous voulez.

Le scénario de Spy est encore plus impossible:

Comme Kent Fredric a souligné le scénario d'espionnage a encore plus les faiblesses inhérentes. Il a tous les problèmes du scénario de photo, ainsi que la faiblesse supplémentaire d'avoir quatre secrets.

Dans le scénario de photo, il serait très peu probable que Bob devinerait au hasard une des photos Charlies. Il est trivial dans le scénario d'espionnage pour Bob à deviner Alices choix (1/4). Les spys ont seulement quatre pays, ils peuvent appartenir à, car ils sont les deux agents quadruples, ils savent tous les deux tous les mots de code secret pour chaque pays. Ainsi, Bob pourrait prétendre travailler pour les Chinois pour tester Alice.

Un autre type de solution:

Des affiches ont noté, la sécurité peut être augmentée si vous affaiblissez la précision de f. Bien sûr, si ce n'est pas précise quel est le point. Je propose un autre type de solution.

  • Ne laissez pas les comparer les mêmes photos plus d'une fois.

La partie qui souhaite engager la comparaison doit d'abord démontrer que cela est une nouvelle comparaison et ne pas utiliser l'une des images d'avant.

EDIT: Problèmes avec Double Hash

Je fais quelques hypothèses sur le protocole doublhash, mais ...

  1. Pour le système de photographie, le protocole doublehash est pas mieux que f, parce que le secret 62 bits doit être construit à partir d'un ensemble de photographies pour la comparaison à meaningfull. L'attaque de sous-ensemble mentionné dans la question initiale est toujours valable ici. Essayez tous les sous-ensembles de photographies à la force brutale des secrets que vous pouvez générer, ainsi Bob peut voir s'il peut générer le même secret que Alice.

En utilisant la propriété doublehash Bob peut la force brute encore le secret.

doubleHash(s1+doubleHash(b)) != doubleHash(aliceSecret+doubleHash(a))

doubleHash(s2+doubleHash(b)) != doubleHash(aliceSecret+doubleHash(a))

doubleHash(s3+doubleHash(b)) == doubleHash(aliceSecret+doubleHash(a))

Bingo, aliceSecret == s3.

DoubleHash est aussi forte qu'il est difficile de bruteforcer a ou b

Implementating DoubleHash

Au lieu de cela doubleHash (a + doubleHash (b)), essayez doubleHash (a, md5 (b)). DoubleHash (a + doubleHash (b)) est mauvaise parce que Bob pourrait générer entrer en collision hash comme ceci:

doubleHash((12 + doubleHash(34)) + doubleHash(5678))  
= doubleHash((34 + doubleHash(12)) + doubleHash(5678))
= doubleHash(5678 + doubleHash(12 + doubleHash(34)) 
= doubleHash(5678 + doubleHash(34 + doubleHash(12)) 

Voici une implémentation de doubleHash en utilisant la nouvelle formulation,

Doublehash(a, hashOfB){
   hashOfA = md5(a)
   combinedHash = hashOfA xor hashOfB
   return md5(combinedHash)
}

On pourrait aussi utiliser les mathématiques derrière les signatures aveugles à impliment version de doubleHash.

Créé 28/08/2009 à 06:58
source utilisateur

voix
1

Pour les deux problèmes, vous pouvez utiliser un calcul bipartite sécurisé égalité algorithme. Il existe de nombreux programmes, par exemple par ce Damgard, Fitzi, Kiltz, Nielsen et Toft: Unconditionally Sécurisez constante ronde multipartite calcul pour l' égalité, Comparaison, Bits et Exponentiation .

Bien sûr, un agent pourrait essayer de poser comme un agent d'un autre côté pour obtenir un tiers chance de découvrir le vrai côté d'un autre agent, mais qui semble inévitable.

Un beaucoup plus simple schéma pour la photo-problème, qui devrait être presque aussi bon que le calcul multipartisme sécurisé, est le suivant:

  1. Alice et Bob trie leurs images et de générer un hachage SHA-512.
  2. Alice envoie le premier bit de son hachage à Bob.
  3. Bob compare le bit au premier bit de son hachage. Si elle est différente, ils savent qu'ils ont reçu des photos différentes. Sinon, ils continuent.
  4. Bob envoie le second bit de son hachage à Alice.
  5. Alice vérifie ce bit et décide de continuer.
  6. Continuez jusqu'à ce que le protocole avorte ou tous les bits ont été vérifiés.
Créé 09/09/2009 à 11:24
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more