Question:
Pourquoi même utiliser un pad unique si la distribution des clés est entièrement sécurisée?
Riley Willow
2016-06-11 13:26:35 UTC
view on stackexchange narkive permalink

J'ai eu un entretien d'embauche hier au cours duquel ils m'ont demandé quel serait le seul scénario où un tampon ponctuel pourrait être brisé, ma réponse était "lorsque le processus de distribution des clés n'est pas suffisamment sécurisé".

Ils ont loué ma réponse, mais ils m'ont posé une autre question: pourquoi utiliseriez-vous même un pavé unique si la distribution des clés est sécurisée à 100%? Pourquoi ne pas simplement envoyer le message en texte brut puisque vous êtes sûr que la distribution est sécurisée à 100%?

Quelle est la bonne réponse à cette question?

Je ne suis pas sûr de ce que la définition de "canal sécurisé" implique, mais la distribution des clés est dans un sens (A -> B) et le message est dans l'autre (B -> A).
une mauvaise génération de clé peut également être problématique, voir VENONA et al
Il se peut que vous souhaitiez que quelqu'un gaspille des ressources en essayant de casser votre code (sans savoir qu'il s'agit d'un OTP) sur le canal non sécurisé.
@Bergi dans le canal sécurisé OTP est une méthode permettant de partager beaucoup d'informations entre les parties sans interception (la taille des informations doit être au moins la longueur de tout le message que l'on va envoyer avec cela, et tous les messages si le mêmepad va être utilisé car vous ne pouvez en réutiliser aucune section).La direction de l'échange n'a pas tellement d'importance avec OTP, mais on ne peut pas simplement envoyer le pad avec le message, cela ne fonctionne pas.
En outre, votre méthode de distribution de clé ne peut pas vous permettre de choisir directement la clé réelle.Par exemple, diffie hellman permet à deux parties de créer un secret partagé, mais aucune des parties ne choisit le secret lui-même.
Je remets en question le principe - comment pouvez-vous être sûr à 100% que votre canal de distribution est vraiment sécurisé?Utiliser la clé comme couche de sécurité supplémentaire reviendrait à prendre la même profondeur de mantra de sécurité que le hachage des mots de passe sur votre base de données, même si vous êtes absolument sûr que personne ne pourrait pirater votre serveur.
"100% sécurisé" n'est pas quelque chose qui existe réellement, ce qui vaut la peine d'être gardé à l'esprit.
* Juste une supposition ... * Parce que les pads à usage unique sont simples à implémenter (simple XOR), et donc il est plus facile de vérifier le code.Et cela devrait fonctionner sur des appareils * très * bas de gamme ou même manuellement (si vous gérez l'échange de clés).
À propos de l'entrevue: j'ai appris que les gens s'attendent généralement à ce que vous répondiez «Quand la clé est réutilisée» - même si cela brise le principe même.
Le caractère «unique» du pad signifie que chaque * portion * du pad est utilisée une fois.Par exemple, si vous utilisez deux jeux de cartes comme bloc de temps unique, vous pouvez envoyer 52 caractères avant d'avoir épuisé votre bloc, en supposant que vous considérez qu'il n'est pas sûr de recycler le bloc.Cela peut représenter jusqu'à 52 messages.Et, comme le souligne kaay, le tampon peut être recyclé, ce qui n'est pas terrible si la longueur (et la nature) du tampon lui-même est gardée secrète.Par exemple, vous ne voudriez pas réutiliser un jeu de 52 cartes si les gens * savent * que vous utilisez un jeu de 52 cartes.
Réutiliser un OTP est superbe même si la longueur n'est pas connue, surtout si le flux est décompressé ou a une structure, par exemple des en-têtes.Si vous XOR à chaque quart de travail à tour de rôle, vous obtiendrez un plongeon en 1 lorsque le pad est réutilisé.Les bits définis à A seront corrélés avec les bits définis à B, donc A + B aura plus de zéros, donc (A + K) + (B + K) = A + B aura également plus de zéros.
@Simba Peu importe que nous l'appelions 100% sécurisé ou 50% sécurisé, ou tout autre numéro.La même question que l'OP pose s'applique - pourquoi ne pas simplement envoyer votre message sur ce canal au lieu d'un OTP?Si vous pouvez interrompre le canal et obtenir le message, vous pouvez interrompre le canal et obtenir l'OTP exactement de la même manière.L'OTP n'ajoute aucune profondeur de sécurité - il ajoute uniquement la sécurité par l'obscurité, une fois que le canal lui-même est compromis, c'est-à-dire que votre seul espoir est que l'attaquant ne réalise pas qu'il a un OTP pour un futur message.
@Simba En revanche, votre exemple de hachage de mots de passe ** fournit ** une profondeur de sécurité.Si l'attaquant pirate votre serveur, il n'a toujours pas les mots de passe sans casser le mécanisme de hachage d'une manière ou d'une autre.Avec l'OTP, dès qu'il l'obtient, il a un accès illimité au contenu crypté.
Dix réponses:
Jeff
2016-06-11 14:30:59 UTC
view on stackexchange narkive permalink

Vous pouvez distribuer la clé maintenant et envoyer le message plus tard

Supposons que vous soyez un espion envoyé en mission derrière les lignes ennemies. Vous emportez la clé avec vous (distribution sécurisée) et lorsque vous découvrez un secret, vous pouvez l'envoyer en toute sécurité à l'aide du pavé à usage unique.

la différence entre la taille d'une clé et un message réel est-elle également un point valide?
@user13267 Pas pour un pad ponctuel.Une clé OTP doit être au moins aussi longue que le message;c'est tout l'intérêt du système.
@cpast C'est pourquoi les espions se déploient fréquemment avec de gros OTP pour leur permettre d'envoyer des messages sécurisés plus tard.La distribution des clés dans cette analogie serait le processus que vous avez pour mettre l'OTP entre les mains de votre espion (et d'un gestionnaire ou avec qui il communiquerait).
La [hotline Moscou-Washington] (https://en.wikipedia.org/wiki/Moscow%E2%80%93Washington_hotline) (appelée "téléphone rouge", mais jamais en fait un téléphone) est un autre bon exemple.(Il est rapporté que cela utilisait en fait des OTP, du moins lors de la première mise en place.) Ils ont échangé des OTP par valise diplomatique de temps en temps - très sûr, mais lent et devant être programmé à l'avance.Mais après avoir fait cela, la hotline pouvait être utilisée au moment où cela devenait nécessaire, ce qui était le point essentiel.
Un autre bon exemple est SIGSALY de la Seconde Guerre mondiale tel que décrit dans l'épisode de 99% Invisible [Vox Ex Machina]) http://99percentinvisible.org/episode/vox-ex-machina/).Il a utilisé des enregistrements avec un bruit aléatoire comme tampons ponctuels pour crypter les appels téléphoniques entre la maison blanche et les dirigeants alliés du monde entier.Les enregistrements seraient envoyés en toute sécurité à l'avance.Ils seraient détruits après la fin de la communication pour garantir le secret de transmission.
Baard Kopperud
2016-06-11 20:11:23 UTC
view on stackexchange narkive permalink

Le fait que vous puissiez distribuer quelque chose en toute sécurité aujourd'hui ne garantit pas que vous pourrez le faire demain - ou la semaine prochaine ou l'année prochaine.

De plus, votre chaîne sécurisée était utilisée pour la distribution la clé peut avoir des limites. Cela dépend peut-être du fait qu'une personne se déplace réellement entre les points A et B ... Peut-être que ce n'est disponible qu'à certaines heures - par exemple le week-end ou en hiver ... Peut-être que sa capacité est très limitée - taille maximale par message et / ou nombre total de messages pouvant être envoyés (par exemple, il semblera suspect s'il est utilisé trop souvent avec trop) ... Vous pouvez également vouloir "enregistrer" ce canal pour envoyer des éléments physiques (comme des OneTime-Pads ou des échantillons de virus), qui en fait ne peuvent être transmis par radio ou Internet - contrairement au texte et aux images ...

Mais le plus gros obstacle est probablement l'aspect temporel. Le renseignement - le type d'espions rassemble et qui est utilisé dans la guerre et la politique - a une durée de vie très limitée. Si vous ne pouvez pas obtenir l'information immédiatement, elle perd de sa valeur - soit parce que la légère longueur d'avance a disparu, parce que tout ce dont il a été averti s'est produit, ou parce que les mêmes informations proviennent d'autres sources.

Donc, utiliser les canaux de communication sûrs - acheminer personnellement, courriers, lettres passées par des officiers sur des navires ou des avions, relayer l'information à travers une chaîne de personnes - est probablement trop lent. Cela laisse les méthodes rapides - mais dangereuses et faciles à surveiller - comme la radio, le télégraphe, le téléphone et Internet. Grâce à ces canaux non sécurisés, les informations peuvent être envoyées très rapidement, mais elles ne sont pas sûres ... Donc, vous cryptez d'abord les informations, avec le pad unique que vous avez obtenu via le canal sécurisé garanti.

Et contrairement à votre chaîne sécurisée, il est presque 100% garanti que les téléphones, la radio et Internet seront également disponibles l'année prochaine.

Si la capacité est limitée, OTP ne fonctionne pas car OTP a besoin d'une clé de la taille du message et la même clé ne peut pas être utilisée pour plusieurs messages, nous avons donc besoin de suffisamment de clé pour couvrir tous les messages futurs avant la prochaine actualisation de la clé (plus grande que lemessages).
@ewanm89 Je faisais référence à des problèmes de capacité avec le "canal sécurisé" - celui utilisé pour transporter le OneTime-pad en premier lieu.Par définition, il ne serait pas nécessaire de crypter le message s'il était envoyé via un canal sécurisé garanti.Cependant, ce canal peut encore limiter la capacité du support envoyé: c'est peut-être un courrier avec un talon creux qui ne peut prendre que dix feuilles de papier.C'est peut-être un moyen de faire passer * un * microfilm - ou une carte mémoire.Peut-être - pour devenir old school - c'est un pigeon voyageur qui ne peut transporter qu'une petite feuille de papier.OTP + radio pas de limite!
Oui, mais l'OTP lui-même ** doit ** être envoyé par un tel canal sécurisé.Lorsque vous utilisez un OTP, vous envoyez autant ou plus de données via ce canal sécurisé que d'envoyer le message directement, donc la capacité ne peut pas être le problème pour pourquoi ne pas utiliser ce canal sécurisé pour envoyer des messages directement.Le reste est très bien, et les limites de temps ou l'absence d'accès fiable à ce canal sécurisé sont des raisons valables d'utiliser OTP plutôt que le canal sécurisé.
Maintenant, vous voudrez peut-être ajouter, si le canal sécurisé transmet les informations lorsque vous revenez au QG et que vous êtes en territoire ennemi, eh bien, il n'y a aucune garantie que vous reviendrez, mieux vaut chiffrer et envoyer au QG parradio maintenant plutôt que de le remettre en personne plus tard, car vous pourriez être abattu avant d'y arriver.
@ewanm89 Mais est-ce alors un canal * sécurisé *?Mais oui, je comprends votre point.Vous pouvez vous assurer que le message serait détruit - un film non développé ou un conteneur qui brûlerait le contenu s'il était ouvert de manière incorrecte.Il pourrait être envoyé par braconnage diplomatique.Il pourrait être transporté sur un navire - qui est le territoire de la nation où le navire est immatriculé - par le capitaine du navire.Mais oui, il serait prudent de crypter les messages au cas où.Mais si le message était suffisamment court pour être envoyé par un canal aussi limité en premier lieu, il ne deviendrait pas beaucoup plus long en le cryptant avec OTP.
@ewanm89 En ce qui concerne l'OTP et le canal sécurisé utilisé pour le délivrer, je pense que la meilleure solution serait que l'agent le porte lui-même sur sa personne.S'il avait été arrêté à son entrée, le BdP aurait été compromis ... Mais avec l'agent que j'ai emprisonné, il ne serait jamais utilisé en premier lieu - du moins en supposant que l'agent était censé appeler chez lui et signaler qu'il était prêt avant d'êtrecontacté.
Je ne dis pas que le message serait plus long, la clé doit être aussi longue ou plus longue et je souligne directement que la capacité du canal sécurisé n'est pas une raison pour laquelle OTP serait utilisé à la place comme la question le demande, toutes les autres raisonsla réponse est saine.Oui, la méthode courante serait de l'emporter avec vous en tant que canal sécurisé couvert par toutes les raisons de temps données.
@ewanm89, si la limite de capacité est le nombre de messages plutôt que la taille du message (pensez: si vous envoyez un CD, peu importe qu'il soit à moitié plein ou complètement plein, mais cela importe si vous en envoyez un parjour contre un par an), la distribution d'une clé OTP sur un canal limité peut encore être pratique.
user2483352
2016-06-11 20:18:08 UTC
view on stackexchange narkive permalink

Il existe des scénarios pratiques où vous échangez une clé et savez seulement qu'elle n'a pas été interceptée (c'est-à-dire que l'échange était 100% sécurisé) après que vous l'avez envoyée. Si vous aviez transmis directement le message secret, il aurait pu être compromis, mais comme vous n'avez échangé que la clé, vous pouvez simplement la supprimer. C'est d'ailleurs l'idée de la cryptographie quantique.

Une autre caractéristique de la cryptographie quantique est que vous ne pouvez pas choisir la clé. Elle est juste aléatoire et ne contient aucune information en elle-même. En fait, vous n'êtes même pas en mesure d'envoyer des informations non générées de manière aléatoire via le canal quantique 100% sécurisé, ce qui signifie que vous ne pouvez pas envoyer votre message secret directement. Si vous souhaitez en savoir plus sur le sujet, je peux vous recommander la page Wikipédia sur la distribution des clés quantiques.

Bon point sur la distribution des clés quantiques.
Bien que ce soit une bonne information à avoir, je ne suis pas sûr qu'il s'agisse d'un scénario pratique pour une interview, car QKD n'est pas exactement répandu dans l'industrie.Comme je le mentionne dans un commentaire ci-dessous - il s'agit d'un entretien d'embauche, pas d'une dissertation sur les universitaires de la cryptographie.
+1.Vous pouvez ajouter à cette réponse des systèmes historiques qui utilisaient des sceaux inviolables sur les paquets utilisés pour envoyer des tampons à usage unique, comme le [système canadien OTFP / OTLP] (http://www.jproc.ca/crypto/otfp_otlp.html);le [système OTP DDR et URSS] (http://www.cryptomuseum.com/crypto/otp/ddr/index.htm);etc.
Mike Maxwell
2016-06-13 01:12:26 UTC
view on stackexchange narkive permalink

Les réponses à l'effet que la distribution sécurisée aujourd'hui ne garantit pas une distribution sécurisée demain sont correctes, je suppose, mais n'y a-t-il pas une autre raison: la distribution des clés se fait généralement à partir d'un site central aux "espions", alors que les espions envoient leurs messages dans le sens inverse? (En supposant que les espions sont ceux qui génèrent les messages; bien sûr, les messages peuvent être envoyés dans les deux sens.) La sécurité dans un sens n'implique pas nécessairement la sécurité dans l'autre sens.

Un cas évident serait l'envoi de sous-marins en mission. Ils reçoivent des tampons uniques avant de partir, mais utilisent ces tampons pour crypter les messages qu'ils renvoient à la base. (La base leur renvoie peut-être des messages, ce qui revient bien sûr à l'autre réponse: vous ne voulez pas que les sous-marins aient à revenir au port pour récupérer en toute sécurité les messages de la base.)

C'est une très bonne chose que la marine allemande ait utilisé Enigma, plutôt que des tampons uniques, pendant la Seconde Guerre mondiale.

Mais les sous-marins utilisent-ils réellement des OTP?L'utilisation d'un OTP limiterait la quantité de texte qu'ils pourraient crypter (ou décrypter) sur une mission particulière.
Un pavé unique sous la forme d'un CD / bande / disque dur à lecture unique puis à effacer donnerait une assez grande quantité de communications totalement sécurisées.
La compression basée sur le dictionnaire @DavidRicherby est utilisée de toute façon dans les [communications sous-marines] (https://en.wikipedia.org/wiki/Communication_with_submarines) (par exemple, la radio VLF, pour la côte au navire).Il a toujours été utilisé pour les communications navales à la fois pour masquer le contenu du message et pour l'encoder efficacement (le débit binaire même d'un opérateur morse efficace était plutôt faible).Au début des années 70, vous pourriez obtenir un lecteur de bande stockant 20 Mo (et vous n'avez pas besoin de 8 bits / symbole, 6 est assez facilement)
dr_
2016-06-13 20:00:00 UTC
view on stackexchange narkive permalink

J'ai eu un entretien d'embauche hier au cours duquel ils m'ont demandé quel serait le seul scénario où un tampon ponctuel pourrait être brisé, ma réponse était "lorsque le processus de distribution des clés n'est pas suffisamment sécurisé".

Je ne veux pas vous donner des insécurités au sujet de votre entretien, mais je suis sûr que ce n'est pas la bonne réponse - ou, sinon, je n'ai pas compris votre réponse. En effet, votre réponse s'applique à toute méthode de chiffrement - si vous ne pouvez pas communiquer en toute sécurité une clé symétrique, la partie est terminée.

Le seul scénario dans lequel un OTP peut être cassé ( en laissant de côté les erreurs évidentes des parties qui communiquent, telles que la réutilisation de parties du bureau du Procureur ou le fait de laisser l'ennemi mettre la main dessus), c'est quand il a été généré à l'aide d'une source qui n'est pas vraiment aléatoire . Cela permettrait à l'ennemi de lancer une analyse de fréquence et d'essayer de déduire le texte échangé.

En fait, un pad unique garantit une sécurité parfaite et est théoriquement incassable. La seule raison pour laquelle il n'est pas largement utilisé est à cause de son impraticabilité.

Pourquoi utiliseriez-vous même un pad unique si la distribution des clés est sécurisée à 100%? Pourquoi ne pas simplement envoyer le message en texte brut puisque vous êtes sûr que la distribution est sécurisée à 100%?

La réponse à cette question est: parce que le canal sécurisé pourrait ne pas être toujours disponible, pourrait avoir une bande passante limitée ou pourrait être trop coûteuse à utiliser. Il peut donc être utilisé pour échanger (une fois) une clé de petite taille mais pas (souvent) de longues communications privées.

"une clé de petite taille mais pas (souvent) de longue communication privée" - mais une clé OTP doit être au moins aussi longue que le message qu'elle crypte.La disponibilité limitée est une raison valable, mais pas la bande passante.
Par définition, la clé OTP est générée par une source véritablement aléatoire.Il est impossible d'être prouvé incassable sans cette hypothèse.Par conséquent, ne pas être généré par une source vraiment aléatoire n'est pas un moyen valide de rompre OTP.La seule façon de le casser est de connaître la clé.Pour cette raison, sa réponse est correcte (car la clé n'est aussi sécurisée que l'échange et les protections au repos. Dans ce cas, on suppose que les protections au repos sont impraticables à attaquer).
Je suis d'accord avec @Qwerty01 - profiter d'une implémentation imparfaite d'un schéma de cryptage ne signifie pas que vous avez cassé le schéma de cryptage lui-même.
@Qwerty01 Pourriez-vous citer la définition qui exclut la génération non vraiment aléatoire?Je demande parce que l'article de Wikipédia sur OTP a une histoire de> 10 ans de changements appelant des clés vraiment aléatoires "un défi", ou utilisant conditionnel "si la clé est vraiment aléatoire" alors impossible à casser.Si c'est une question de définition, les enquêteurs pourraient en utiliser une autre.
La raison pour laquelle ils le mentionnent est qu'il est difficile de générer des données vraiment aléatoires.Pour cette raison, les gens ont tendance à utiliser les CSPRNG afin de générer les données nécessaires plutôt que des données vraiment aléatoires.Si les données ne sont pas vraiment aléatoires, vous attaquez l'algorithme qui a généré la clé et non OTP.Une autre façon de penser est la suivante: si vous utilisez un RNG qui renvoie le même nombre à chaque fois pour générer une clé RSA, la clé sera facilement cassée: pas à cause d'un problème dans RSA, mais à cause d'un problème dans votreRNG.
Jon Bentley
2016-06-14 17:19:58 UTC
view on stackexchange narkive permalink

Voici une autre raison que les autres réponses ne mentionnent pas:

Vous pouvez utiliser votre canal sécurisé une fois pour transmettre des OTP, puis envoyer des messages sécurisés plusieurs fois plus tard jusqu'à ce que vos OTP soient épuisés.

Cela peut être utile car la réalisation d'un canal 100% sécurisé (ou proche de celui-ci) peut être très difficile et / ou coûteux, alors que les canaux non sécurisés sont bon marché et rapides , et facilement disponible, il est donc avantageux de minimiser la fréquence de votre utilisation du canal sécurisé.

Exemple: vous transportez 1 téraoctet de données OTP en transportant physiquement un disque dur jusqu'à la destination (opération coûteuse et peu pratique). Vous pouvez ensuite envoyer 1 téraoctet de messages cryptés via Internet au fur et à mesure que vous en avez besoin. C'est mieux que d'utiliser à plusieurs reprises le canal sécurisé pour envoyer vos messages manuellement.

Grant
2016-06-14 23:19:54 UTC
view on stackexchange narkive permalink

Un pavé unique peut être cassé si le message à chiffrer est beaucoup plus long (comme plusieurs fois) que le nombre de caractères / octets du pavé. Cela équivaut à une utilisation répétée du même "pad unique" et est également vulnérable au décryptage.

Si vous répétez le pad, ce n'est plus un pad ponctuel.
Jesse Williams
2016-06-14 23:33:55 UTC
view on stackexchange narkive permalink

Honnêtement, je pense qu'une réponse plausible est que vous ne pouvez pas garantir une sécurité à 100%. Ou du moins ce serait ma réponse, probablement suivie par "quiconque assume une sécurité à 100% ne comprend pas la sécurité. De plus, quiconque assume une sécurité à 100% est autant à risque, et peut-être plus, que quelqu'un assumant moins de 100% de sécurité."

Cela n'a aucun rapport avec la question.Que vous ayez 100% de sécurité, 99% de sécurité ou 50% de sécurité sur le canal que vous avez choisi, la question demeure: devrais-je envoyer un OTP sur ce canal puis envoyer un message crypté plus tard, ou devrais-je simplement envoyer le message à ce sujetcanal?La sécurité du canal ne fait aucune différence - s'il existe un moyen de rompre le canal et d'obtenir le message, la même manière vous permettra d'obtenir l'OTP.
Je ne suis pas d'accord - ce n'est pas une thèse sur la sécurité, c'est une question d'entrevue.Ayant été responsable du recrutement dans la R&D en sécurité, je m'attendrais à ce qu'un candidat me donne une réponse qui montre une injection de réflexion du monde réel sur une telle question.Si je cherchais une réponse académique, j'affirmerais volontiers qu'après qu'une telle réponse ait été donnée.
Si j'étais responsable du recrutement et que j'obtenais cette réponse, je serais moins préoccupé par la validité de la réponse et plus préoccupé par le fait qu'ils ne comprennent pas correctement la question.Cela indique des problèmes d'attention aux détails et de capacité à suivre les instructions.Je préfère une mauvaise réponse qui tente au moins la question (après tout, on ne peut s'attendre à ce qu'aucun être humain sache tout), qu'une information «correcte» qui n'est pas pertinente.
En regardant la question - * "Pourquoi utiliseriez-vous même un pavé unique si la distribution des clés est 100% sécurisée? Pourquoi ne pas simplement envoyer le message en texte brut puisque vous êtes sûr que la distribution est 100% sécurisée?" * - c'esttrès clair que la sécurité du canal est supposée, et ils veulent savoir pourquoi vous devriez vous embêter avec un OTP.Ils ne demandent pas s'il est possible ou non qu'un canal soit sécurisé à 100%.
Je ne suis pas d'accord, mais ... cela montre simplement que lorsque vous répondez à une question dans une interview, vous êtes à la merci de la position des intervieweurs sur une question.Ce n'est pas comme si cette question était "résoudre pour x" ou "quels sont les composants de la pile de protocoles TCP / IP".Je préfère voir un sceptique en matière de sécurité que quelqu'un avec un nouveau diplôme et un livre intelligent qui pense pouvoir déjouer le système - ledit système étant que la sécurité, même dans des conditions idéales, est imparfaite.
Alors votre question devrait être: "Pensez-vous qu'il est possible d'atteindre une sécurité à 100%?"si vous voulez cette réponse.Poser une question sans rapport et espérer votre réponse ne fait que créer un processus d'entrevue déroutant.
Ce qui, en ce qui concerne l'attention aux détails, est probablement la réponse la plus détaillée.Je comprends ce que vous dites, et je suppose qu'une réponse comme celle que j'ai proposée entraînerait des questions complémentaires ou une demande de réponse plus théorique, ce qui est bien.Mais je préférerais en fait que cet échange ait lieu en premier.
Count Iblis
2016-06-15 11:28:05 UTC
view on stackexchange narkive permalink

La question:

Pourquoi utiliseriez-vous même un pad unique si la distribution des clés est sécurisée à 100%? Pourquoi ne pas simplement envoyer le message en texte brut puisque vous êtes sûr que la distribution est sécurisée à 100%?

Cela suppose qu'au moment de la distribution de la clé, il y a des informations à envoyer qui ne peuvent pas être le cas. D'autres réponses données ici ont abordé ce point. Un autre problème est que même en principe, la distribution des clés peut être suffisante uniquement pour la distribution des clés, alors qu'elle peut ne pas être sécurisée pour le transfert souhaité d'informations.

Un exemple est le problème de la façon dont Edward Snowden peut vous envoyer informations en toute sécurité. Nous supposons que toutes les communications de Snowden sont surveillées, si vous le rencontrez en face à face, vous serez surveillé, tout ce que vous lui reprenez ne sera pas sécurisé. Donc, il n'y a aucun moyen que Snowden puisse vous donner un fichier texte brut sans que cela soit compromis. Tout au plus, vous pouvez apporter quelque chose à Snowden en toute sécurité. Pour implémenter la méthode OTP, c'est tout ce que vous avez à faire.

Un protocole sécurisé utilisant l'OTP pourrait alors fonctionner comme suit. Je fais des copies des images que j'ai sur mon disque dur et les mets sur une clé USB. Je demande à quelqu'un en qui j'ai confiance de donner cette clé USB à Snowden. Après que cette personne a rencontré Snowden, il est repéré l'avoir fait, tous ses biens sont fouillés, la CIA le surveille, sa maison finit par cambrioler régulièrement, des logiciels espions sont installés sur son ordinateur. Donc, évidemment, il ne peut rien recevoir de Snowden en toute sécurité.

Mais Snowden peut m'envoyer des informations en toute sécurité en appliquant la méthode OTP pour diviser les messages en deux parties de bruit blanc et en ajoutant ce bruit en tant que faux bruit ISO élevé à deux photos qu'il a obtenues de moi et en téléchargeant ces deux photos sur Flickr. Tout ce que j'ai à faire est de télécharger ses deux dernières publications Flickr, de soustraire les fichiers image des images sur mon disque dur et d'ajouter les deux parties de bruit pour obtenir le message.

Je pense que vous n'avez pas compris la question.Le PO est conscient de ce qu'est un OTP et de son fonctionnement.En suivant votre exemple, la question est la suivante: si vous pouvez remettre en toute sécurité à la personne la clé USB contenant l'OTP, alors pourquoi ne pas simplement lui remettre le message en premier lieu, puisque vous disposez déjà d'un canal sécurisé par lequel lui donner le pouceconduire.
@JonBentley J'ai bien compris la question, je l'ai abordée sur le point déjà soulevé dans d'autres réponses sur le transfert d'informations se produisant plus tard quand il n'y a pas de canaux sécurisés disponibles.
@CountIblis Comment répondez-vous à la question "Pourquoi utiliseriez-vous un OTP si vous êtes sûr à 100% que la distribution des clés est sécurisée?" Il est clair que vous n'avez pas compris la question.Ceci répond à une question du type "Comment pouvez-vous rendre la distribution des clés plus sécurisée?"
@Qwerty01 J'ai bien compris la question, c'est juste que dans le contexte du Bureau du Procureur de la manière dont on l'utiliserait dans la pratique, c'est une chose extrêmement triviale.La distribution des clés n'est pas le point où les informations sont transférées, il peut même ne pas être possible de transférer des informations en toute sécurité via ce canal.Le Guardian pourrait envoyer un journaliste à Snowden et lui donner une clé USB contenant des images.Mais sur le chemin du retour, tous ses biens peuvent être fouillés.Il n'y a alors aucun canal sécurisé pour les communications entre Snowden et le Guardian, mais l'OTP peut être utilisé.
Ainsi, la clé OTP ne peut être envoyée de manière sécurisée que dans un sens, car lorsque je vais à Snowden, les services de renseignement ne savent pas que j'ai l'intention de le rencontrer.Mais après l'avoir rencontré, j'ai peut-être été repéré par des agents secrets surveillant son appartement, donc tout ce que je lui reprends n'est pas sécurisé.
Je vois à quoi vous voulez en venir, mais il manque toujours l'intention de la question.Il ne s'agit pas de _comment_, mais de _pourquoi_ (ce qui, dans ce cas, serait que vous devrez peut-être transférer des fichiers vers Snowden _later_ et n'obtenir qu'une seule chance sur un canal 100% sécurisé _ maintenant_)
@Qwerty01 Ok., Je vais réécrire cette réponse en me basant sur l'exemple Snowden.
Duszek Smsaczek
2016-06-11 21:24:00 UTC
view on stackexchange narkive permalink

Si vous envoyez un texte vraiment confiant qui ne peut en aucun cas être intercepté par les ordinateurs, vous devez utiliser OTP et remettre la clé en face à face, mais vous pouvez envoyer un message chiffré via le bureau de poste. S'il est utilisé correctement, personne ne peut interrompre les messages. Même en 1'028'526'910 an.

La question ne concerne pas les OTP ou leur fonctionnement.La question est la suivante: si vous pouvez livrer l'OTP en face à face, alors pourquoi ne pas livrer le message en face à face et éviter la complication supplémentaire de l'utilisation d'un OTP.Pour répondre à la question, vous devez aborder spécifiquement les raisons d'utiliser un OTP au lieu du message lui-même.
@JonBentley Sûrement, le problème n'est pas de savoir comment communiquer en toute sécurité avec votre femme à la maison ....
@CountIblis Je ne comprends pas vraiment votre commentaire.Ce que je veux dire, c'est que si vous avez un moyen de livrer en toute sécurité l'OTP, vous auriez pu utiliser cette méthode pour remettre le message à la place, et l'OP vous demande pourquoi vous vous embêteriez à utiliser un OTP dans ce cas.
@JonBentley Qui a dit qu'il y a un message à livrer par moi au destinataire de la clé OTP?C'est peut-être l'inverse et ce chemin inverse peut ne pas être sûr du tout.Snowden veut m'envoyer un message sécurisé mais il n'est pas en mesure de me livrer une clé OTP.Je peux lui remettre une clé OTP, mais je ne peux lui reprendre aucun message car je serai repéré en train de lui rendre visite et je serai fouillé.
@CountIblis Oui ... c'est une réponse possible à la question.Où veux-tu en venir?Vous semblez penser que je pose la question, mais je ne le suis pas.Je clarifie ce qu'est la question **, car cette réponse ne comprend pas la question.
Je déteste les détestables!


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...