Imaginons qu'Alice et Peter ont chacun une clé USB à mémoire flash de 4 Go. Ils se rencontrent et enregistrent sur les deux sticks deux fichiers nommés alice_to_peter.key(2 Go) et peter_to_alice.key(2 Go) qui contiennent des bits générés aléatoirement. Ils ne se rencontrent plus jamais, mais communiquent électroniquement. Alice maintient également une variable appelée alice_pointeret Peter maintient une variable appelée peter_pointer, toutes deux initialement définies sur zéro.
Quand Alice doit envoyer un message à Peter, elle le fait (où nest le nième octet du message):
encrypted_message_to_peter[n] = message_to_peter[n] XOR alice_to_peter.key[alice_pointer + n]
encrypted_payload_to_peter = alice_pointer + encrypted_message_to_peter
alice_pointer += length(encrypted_message_to_peter)
(et pour une sécurité maximale, la partie utilisée de la clé peut être effacée)
Peter reçoit encrypted_payload_to_peter, lit les données alice_pointerstockées au début du message et fait:
message_to_peter[n] = encrypted_message_to_peter[n] XOR alice_to_peter.key[alice_pointer + n]
Et pour une sécurité maximale, après lecture du message effacez également la partie utilisée de la clé.
- EDIT: En fait, cette étape avec cet algorithme simple (sans vérification d'intégrité et authentification) diminue la sécurité, voir le post de Paŭlo Ebermann ci-dessous.
Lorsque Peter a besoin d'envoyer un message à Alice, ils font l'inverse, cette fois avec peter_to_alice.keyet peter_pointer.
Avec ce schéma trivial, ils peuvent envoyer chaque jour pendant les 50 prochaines années 2 Go / (50 * 365) = ~ 115 Ko de données chiffrées dans les deux directions. S'ils ont besoin de plus de données à envoyer, ils pourraient utiliser des clés plus grandes, par exemple avec les HD 2 To actuels (clés 1 To), il serait possible d'échanger 60 Mo / jour pendant les 50 prochaines années! C'est beaucoup de données dans la pratique; par exemple, en utilisant la compression, c'est plus d'une heure de communication vocale de haute qualité.
Il me semble qu'il n'y a aucun moyen pour un attaquant de lire les messages cryptés sans les clés, car même s'ils ont un ordinateur infiniment rapide, avec la force brute, ils peuvent obtenir tous les messages possibles sous la limite, mais c'est un nombre astronomique des messages et l'attaquant ne sait pas lequel d'entre eux est le message réel.
Ai-je raison? Ce schéma de communication est-il vraiment absolument sécurisé? Et s'il est sécurisé, a-t-il son propre nom? Le cryptage XOR est bien connu, mais je recherche le nom de cette application pratique concrète utilisant de grandes clés des deux côtés? J'attends humblement que cette application ait été inventée quelqu'un avant moi. :-)
Remarque: s'il est absolument sécurisé, c'est incroyable, car avec les grands périphériques de stockage à faible coût d'aujourd'hui, il serait beaucoup moins cher de faire une communication sécurisée qu'avec la cryptographie quantique coûteuse, et cela a une sécurité équivalente!
EDIT:
Je pense que ce sera plus pratique à l'avenir que les coûts de stockage diminuent.Il peut résoudre la communication sécurisée pour toujours.Aujourd'hui, vous n'avez aucune certitude si quelqu'un attaque avec succès les chiffres existants, même un an plus tard, et rend ses implémentations souvent coûteuses peu sûres. Dans de nombreux cas, avant la communication, lorsque les deux parties se rencontrent personnellement, c'est le moment de générer les clés. Je pense que c'est parfait pour la communication militaire, par exemple entre les sous-marins qui peuvent avoir des HD avec de grandes touches, et la centrale militaire peut avoir un HD pour chaque sous-marin. Cela peut également être pratique dans la vie quotidienne, par exemple pour contrôler votre compte bancaire, car lorsque vous créez votre compte, vous rencontrez la banque, etc.
la source
Réponses:
Oui, il s'agit d'un bloc à usage unique . Si le matériau clé n'est jamais réutilisé, il est théoriquement sûr.
Les inconvénients sont que vous auriez besoin d'une clé par paire de principaux communicants et que vous auriez besoin d'un moyen sécurisé d'échanger le matériel clé avant de communiquer.
la source
Comme l' indique la réponse de Vatine , votre algorithme est essentiellement un bloc ponctuel.
Cependant, pour commenter une de vos notes:
Ma réponse est non, ce n'est pas étonnant. Le diable est toujours dans les détails, et le diable est ici dans l'échange de clés. Votre méthode repose sur un échange de clés en face à face parfait. Je ne peux pas me permettre d'envoyer James Bond avec un disque flash de 4 Go à chaque commerçant sur Internet chaque fois que je veux acheter quelque chose ou avoir d'autres connexions sécurisées.
Et enfin, l'aspect XOR de votre algorithme n'est pas important. Un chiffrement de substitution simple est très bien avec un OTP. La force de l'OTP est que la clé n'est jamais réutilisée, et elle suppose que James Bond échange parfaitement les clés pour les deux parties (c'est-à-dire un échange de clé sécurisé préalable)
la source
Bien que le tampon à usage unique ait une garantie de confidentialité inconditionnelle (prouvée mathématiquement) contre un attaquant qui ne peut lire que les messages, il présente certaines faiblesses.
Un attaquant interceptant qui devine correctement le texte brut peut manipuler le texte chiffré comme bon lui semble (avec la même longueur).
Si un attaquant insère ou supprime un message (ou une partie de celui-ci), les pointeurs d'Alice et de Bob se désynchronisent et toute communication future est interrompue.
Mise à jour: cela supposait que les deux parties gardent une trace des deux pointeurs. Si vous envoyez la valeur actuelle du pointeur, vous êtes vulnérable aux attaques à deux tampons temporels (si vous autorisez la même plage de clés à être utilisées plusieurs fois) ou aux attaques DOS (si vous n'autorisez pas la même plage de clés à utiliser plusieurs fois, par exemple en les supprimant).
Ces deux problèmes sont dus au manque d'intégrité et de protection d'authentification - vous avez un chiffrement parfait, mais pas de MAC.
Ajoutez un MAC à votre protocole ponctuel pour le rendre réellement sécurisé. Chaque message doit obtenir une «somme de contrôle» qui garantit qu'il a bien été envoyé par l'expéditeur supposé et n'a pas été modifié entre les deux. En outre, vous devez envoyer un numéro de séquence pour que le destinataire sache quelle partie de la clé utiliser lors de la perte d'un message précédent (ou pour rejeter le message s'il est dupliqué) - incluez-le dans le calcul de la somme de contrôle.
Un algorithme MAC habituel ferait l'affaire ici, mais je suppose que vous voudrez peut-être utiliser un MAC polynomial à usage unique pour avoir la sécurité correspondante à votre bloc à usage unique. (Prenez la clé MAC des bits avant ou après votre clé de chiffrement, c'est-à-dire ne réutilisez pas une clé pour les deux objectifs.)
la source
En fait, ce n'est pas entièrement sûr. Ce que fuit votre protocole, c'est la LONGUEUR du message communiqué.
Par exemple, si l'espion sait que vous répondrez par «oui» ou «non» et voit la longueur = 2, il peut déduire que c'est «non».
En fait, il est étonnant de voir combien on ne peut déduire que des longueurs connues si l'on peut deviner le contexte.
la source