La distribution des clés est le problème.

Dans votre scénario, vous utilisez un serveur pour communiquer les tampons à usage unique aux utilisateurs. Mais comment cette communication est-elle protégée? Pas par un pad ponctuel, ou ce ne serait pas nécessaire. Disons que c'est SSL avec AES 128. Ensuite, wham, votre cryptosystème est aussi sécurisé que SSL avec AES 128 - assez sécurisé, mais pas aussi sécurisé qu'un pad ponctuel.

Les mils types que vous référencez apparaissent d'offrir des périphériques physiques sur lesquels vous chargez un flux de clés unique (et à partir duquel vous pouvez l'utiliser). Encore une fois, la distribution des clés est un problème. Vous pouvez acheter deux disques durs, y charger des téraoctets de flux de clés et en envoyer un à votre copain ... comment? Faites-vous confiance à USPS? Fedex? Courrier? Pochette diplomatique? Tous ces éléments peuvent être compromis. Le seul moyen parfaitement chiffré de les envoyer serait de les chiffrer avec un pa ... merde, c'est arrivé à nouveau.

Non, car vous comprenez mal la signification de «meilleur» dans un contexte de sécurité. Contrairement à l'opinion populaire, «le plus sûr» et le «meilleur» ne sont pas des synonymes, mais la sécurité consiste entièrement à trouver un équilibre entre convivialité et sécurité. Il s'agit de la gestion des risques.

Le lecteur le plus sûr de la planète est d'écrire à DevNull (le seau à bits) au fond de l'océan dans une boîte verrouillée dans un tas de béton, dans une cage de Faraday, coulé dans la lave sans câbles ni fils. Absolument personne n'obtiendra jamais de données, mais les utilisateurs légitimes n'obtiendront jamais de données non plus.

Une fois, les tampons ont le luxe d'être prouvés impossible à casser s'ils sont utilisés correctement, mais ils sont encombrants utiliser. S'ils étaient la "meilleure" option, alors aucun des autres systèmes que nous connaissons aujourd'hui n'existerait car ils sont presque tous nés après l'idée de l'unique time pad (qui est un concept vraiment ancien.)

La meilleure option est plutôt celle qui réduit vos risques à des niveaux acceptables tout en maintenant un niveau de convivialité acceptable. Dans de nombreux cas, la meilleure sécurité peut bien être l'absence de sécurité. Par exemple, je me fiche de savoir si vous connaissez mes recettes de biscuits, donc faire tout effort pour les protéger réduirait inutilement la convivialité. Je me soucie de savoir si mes recettes de cuisine se perdent, alors je peux vouloir stocker plusieurs copies et les sauvegarder quelque part, mais je n’aurais pas accès à les contrôler car ce serait une perte de temps.

Le le même processus de pensée n'est pas moins vrai pour les situations de haute sécurité que pour mes recettes de cuisine. Il s'agit d'analyser le risque tel qu'il s'applique à moi (Oreo peut se soucier davantage de la protection de sa recette), puis de décider quelle est ma meilleure option. C'est différent pour chacun et pour chaque situation et il n'y a pas de réponse universelle.

Non. Non seulement un pad ponctuel souffre de problèmes de distribution de clés sécurisée que Mike et gowenfawr ont mentionnés dans leurs réponses, mais:

Même si si vous disposiez d'un mécanisme pour distribuer les clés en toute sécurité, le un tampon horaire (à lui seul) n'a aucun mécanisme pour assurer l'intégrité. Le texte chiffré est ce que nous appelons «malléable», ce qui signifie qu'il peut être manipulé par un attaquant pour modifier le message en clair de manière prévisible et indétectable.

Donc , même si le bloc-notes unique offre une parfaite confidentialité théorique de l'information, il n'est pas, en soi, un chiffrement sécurisé, et dans le monde réel, facile à utiliser authentifié les chiffrements avec des clés de taille raisonnable comme AES-CTR-HMAC ou AES-GCM sont nettement meilleurs.

Vous essayez de comparer une primitive cryptographique et de la comparer au système cryptographique . Il s'agit en fait de comparer des pommes et des oranges.

Les primitives cryptographiques sont rassemblées pour créer un système cryptographique , et vous ne pouvez évaluer que la sécurité d'un système une fois que vous comprenez les cas d'utilisation et l'environnement dans lesquels le système fonctionne, y compris les attaquants, les utilisateurs, les protocoles sur le fil, les mécanismes de stockage, les voies de compromis, les exigences de disponibilité, le nombre d'utilisateurs, de nœuds, de réseaux entre, les services dépendants, etc.

Donc à votre question:

Donc, en dehors du contexte de la primitive One Time Pad, le système devrait probablement introduire d'autres techniques / primitives pour prendre en charge les exigences suivantes.

• Intégrité du message (sommes de contrôle, signature)
• Assurer la synchronisation pour éviter le DOS. (Un attaquant pourrait introduire un faux message pour désynchroniser la communication entre les parties.)
• Empêcher l'homme au milieu de changer un seul bit en transit (pourrait changer la signification d'un texte en clair partiellement connu en retournant un bit. c'est-à-dire "LaunchMissiles = 0" contre "LaunchMissiles = 1"
• Arrêter les attaques de relecture ("Attack at Dawn" rejoué trois jours plus tard)

Et autre facultatif Exigences

• Vérification de l'expéditeur (signature)
• Vérification du destinataire (certificats)

Vous ne pouvez donc tenter d'évaluer que la sécurité d'un Crypto-System une fois qu'il est raisonnablement articulé.

Le problème avec un pad unique est de le distribuer aux deux parties. Vous ne pouvez pas simplement le mettre sur un serveur pour qu'ils le téléchargent tous les deux, car si vous disposiez d'un canal sécurisé pour le faire, les deux parties pourraient simplement utiliser ce canal sécurisé pour communiquer de toute façon. Il faut quasiment réunir les deux parties physiquement, ce qui est évidemment très contraignant.

Un problème persistant avec tout chiffrement est la confiance . Vous devez avoir confiance que la personne à qui vous envoyez un message est de votre côté et ne livrera pas le message ou la clé à quelqu'un qui ne devrait pas l'avoir. Vous devez être sûr que les personnes qui ont inventé le schéma de cryptage que vous utilisez n'ont pas inclus de porte dérobée ou de défaut accidentel. Avec OTP, vous avez le problème de la confiance avec le destinataire, mais si vous ne pouvez pas donner la clé au destinataire vous-même physiquement, vous devez maintenant faire confiance à une entité tierce qui peut livrer la clé à le destinataire. Ce problème existe encore aujourd'hui avec le cryptage moderne ainsi que l'authentification.

Si j'étais un utilisateur potentiel, je ne ferais jamais confiance à une tierce partie qui générerait une clé et la transmettrait via une connexion réseau. Il n'y a également aucun moyen pour un utilisateur de s'assurer que vous générez des clés vraiment aléatoires ou si vous avez été compromis. Ce n'est certainement pas une utilisation appropriée de l'OTP, car le cryptage n'est aussi fort que sa pire faiblesse. Si vous envoyez la clé sur Internet, vous avez perdu tout avantage que le véritable OTP peut offrir et vous pourriez aussi bien opter pour AES-256.

Je pense qu'il est prudent de dire que OTP est techniquement le meilleur cryptage de transport, le mot «meilleur» faisant référence à la sécurité. Cela ne veut pas dire que c'est "le meilleur" pour la plupart des cas d'utilisation, et OTP présente de sérieux inconvénients. La clé doit être stockée quelque part, ce qui signifie que la clé peut tomber entre de mauvaises mains. Les chiffrements par blocs modernes ont généralement des clés plus courtes qu'un être humain peut mémoriser, ce qui rend beaucoup plus difficile pour un tiers de les extraire. Il est également très difficile de mal implémenter quelque chose comme AES avec le bon logiciel.

Ce sur quoi vous pouvez compter plus que la sécurité d'OTP, c'est la paresse des êtres humains; nous sommes naturellement poussés à faire ce qui est le plus simple, et cela a toujours conduit les gens à prendre des décisions vraiment irréfléchies qui leur coûtent la sécurité de leur canal de communication. Parfois, les humains paresseux décident de réutiliser les clés une fois que leur clé ou leur livre de codes est épuisé et qu'ils n'ont pas les moyens de générer un nouveau transport &. Le résultat peut être bien pire que de cesser complètement de communiquer.

Définissez le mieux, et la réponse peut être oui ou non.

Le principal problème est l'échange sécurisé des clés! Si vous pouvez d'une manière ou d'une autre vous connecter à un serveur toujours en ligne et communiquer avec ce serveur 100% sécurisé - pourquoi ne relayez-vous pas simplement votre message sur ce serveur?

Un scénario parfaitement valide est le suivant: Vous vous rencontrez quelqu'un en personne et échanger des OTP avec lui. Après cela, vous pouvez communiquer en toute sécurité avec lui tant que les OTP durent. Pour assurer l'intégrité des messages, vous allez ajouter N octets aléatoires à votre texte en clair, puis tout hacher avant de chiffrer avec l'OTP (je compresserais généralement également le texte en clair avant le chiffrement pour assurer une taille plus petite et une densité d'informations plus élevée). Cela garantira l'authentification et le cryptage à la fois. Parce que l'authentification consiste essentiellement à vérifier que l'autre partie connaît un secret, que lui seul peut connaître. Mais avec des clés secrètes symétriques, la clé est déjà un secret que seuls vous deux connaissent, donc si un message réussit à déchiffrer avec la clé secrète partagée et est toujours intact (décompresser + vérifier le hachage), l'intégrité et l'authentification ont été vérifiées.

Mais si vous voulez utiliser OTP contre les approches de force brute, vous pouvez tout aussi bien utiliser un cryptage symétrique assez grand (comme AES) qui est également assez impossible à casser. La partie intéressante de la cryptographie est l'échange de clés. Comment puis-je faire tout ce cryptage / authentification sans rencontrer toutes les personnes avec lesquelles je souhaite communiquer en toute sécurité? C'est pourquoi le chiffrement asymétrique existe.

Donc, OTP résout assez bien un problème qui est déjà assez bien résolu (chiffrement symétrique) mais ne résout pas du tout les vrais problèmes, qui en sont la raison cryptage asymétrique!