Pouvez-vous dire qu'étant donné que le chiffrement ponctuel est incassable, il est préférable s'il est utilisé correctement?
Je suis en train de lire sur le chiffrement ponctuel, et j'ai une question. Ils disent que le cryptage OTP est incassable, et cela peut être prouvé mathématiquement. Ceci à condition que la clé utilisée soit vraiment aléatoire et ne soit utilisée qu'une seule fois, non? Que se passe-t-il si je viens avec un système entier (logiciel ou matériel ou une combinaison des deux) pour forcer ces deux conditions? Aurai-je la meilleure solution de cryptage idéale?
Disons par exemple que les deux parties désireuses d'échanger des informations obtiennent les clés en se connectant à un serveur qui est en ligne tout le temps. Le serveur s'assurera que les clés générées sont aléatoires et s'assurera qu'une clé n'est plus jamais utilisée. Les utilisateurs de chaque côté n'auront qu'à disposer d'une connexion Internet et d'un mécanisme d'échange d'informations. Les informations circuleront via Internet cryptées à l'aide de la clé unique générée au hasard par le serveur.
Suis-je logique ici? Je viens de commencer à lire sur un bloc de temps et j'ai commencé à me poser des questions à ce sujet. Il existe de nombreux sites Web qui vous diront qu'un bloc de temps n'est pas du tout pratique, car vous ne pouvez pas vraiment trouver un nombre vraiment aléatoire ou quelque chose comme ça.
Une addition:
Ces gars-là offrent-ils quelque chose de spécial dans la distribution des clés? Ils disent avoir perfectionné la mise en œuvre du protocole OTP au fil du temps.
La distribution des clés est le problème.
Dans votre scénario, vous utilisez un serveur pour communiquer les pads à usage unique aux utilisateurs. Mais comment la communication est-elle protégée? Pas par un tampon unique, 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 à usage unique.
Les gars de mils que vous référencez semblent offrir des appareils physiques sur lesquels vous chargez un flux de clés unique (et pouvez l'utiliser à partir de). 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 ami ... comment? Faites-vous confiance à USPS? Fedex? Courrier? Pochette diplomatique? Tout cela peut être compromis. La seule façon parfaitement cryptée de les envoyer serait de les crypter avec une pa ... merde, c'est arrivé à nouveau.
Non, parce que vous comprenez mal le sens de "meilleur" dans un contexte de sécurité. Contrairement à l’opinion populaire, "le plus sûr" et le "meilleur" ne sont pas synonymes, mais plutôt la sécurité consiste à équilibrer l’utilisabilité et la sécurité. Il s'agit de gestion des risques.
Le lecteur le plus sûr de la planète est d'écrire à DevNull (le seau à mors) 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 de la lave sans aucun câble ni fil. Absolument, personne n'en obtiendra jamais, mais les utilisateurs légitimes n'en obtiendront jamais non plus.
Les tampons à usage unique ont le luxe d'être impossible à briser s'ils sont utilisés correctement, mais ils sont lourds à 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 apparus après l'idée du bloc de temps unique (qui est un concept vraiment ancien).
Au contraire, la meilleure option est celle qui atténue vos risques à des niveaux acceptables tout en maintenant un niveau d'utilisation acceptable. Dans de nombreux cas, la meilleure sécurité peut être sans sécurité. Par exemple, je me fiche que vous connaissiez mes recettes de cookies, donc tout effort pour les protéger réduirait inutilement la convivialité. Je m'inquiète si mes recettes de cuisine se perdent, donc je peux vouloir stocker plusieurs copies et les sauvegarder quelque part, mais je ne voudrais pas les contrôler car ce serait une perte de temps.
Le même processus de réflexion n'est pas moins vrai pour les situations de haute sécurité que pour mes recettes de cuisine. Cela revient à analyser les risques lorsqu'ils s'appliquent à moi (Oreo peut se soucier davantage de protéger leur recette), puis à 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 seulement un bloc unique souffre de problèmes de distribution de clés sécurisées 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 pavé unique (en lui-même) 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.
So, même si le pavé unique offre un secret théorique parfait de l'information, ce n'est pas, en soi, un chiffrement sécurisé, et dans le monde réel, des chiffrements authentifiés faciles à utiliser avec des clés de taille raisonnable telles que AES-CTR-HMAC ou AES-GCM sont clairement meilleurs.
Vous essayez de comparer un Cryptographic Primitive et de le comparer à Cryptographic system. C'est vraiment comparer des pommes et des oranges.
Cryptographic Primitives sont rassemblés pour créer un Cryptographic system, et vous ne pouvez évaluer la sécurité d'un système qu'une fois que vous comprenez les cas d'utilisation et l'environnement dans lesquels le système fonctionne, y compris attaquants, utilisateurs, protocoles sur le câble, mécanismes de stockage, voies de compromis, exigences de disponibilité, nombre d'utilisateurs, nœuds, réseaux entre, 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)
- Assurez la synchronisation pour éviter DOS. (Un attaquant peut introduire un faux message pour désynchroniser la communication entre les parties).
- Empêcher Man in the Middle de modifier un seul bit en transit (pourrait changer la signification d'un texte en clair partiellement connu en inversant un bit. Par exemple, "LaunchMissiles = 0" contre "LaunchMissiles = 1"
- Arrêter les attaques de rejeu ("Attack at Dawn" rejoué trois jours plus tard)
Et autres exigences facultatives
- Vérification de l'expéditeur (signature)
- Vérification du récepteur (certificats)
Vous ne pouvez donc tenter d'évaluer la sécurité d'un système cryptographique qu'une fois qu'il est raisonnablement articulé.
Le problème avec un bloc unique est de le distribuer aux deux parties. Vous ne pouvez pas simplement le mettre sur un serveur pour les télécharger tous les deux, car si vous aviez un canal sécurisé pour le faire, les deux parties pourraient simplement utiliser ce canal sécurisé pour communiquer de toute façon. Vous devez à peu près réunir physiquement les deux parties, ce qui est évidemment très limitatif.
Un problème persistant avec tout le cryptage est trust. Vous devez avoir confiance que la personne à qui vous envoyez un message est de votre côté et ne remettra pas le message ou la clé à quelqu'un qui ne devrait pas l'avoir. Vous devez avoir confiance 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 d'accident. 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 partie qui peut remettre la clé à le destinataire. Ce problème existe toujours aujourd'hui avec le cryptage moderne ainsi que l'authentification.
Si j'étais un utilisateur potentiel, je ne ferais jamais confiance à un tiers 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 bonne utilisation d'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 vrai OTP peut fournir et vous pourriez tout aussi bien opter pour AES-256.
Je pense qu'il est sûr de dire que OTP est techniquement le meilleur cryptage de transport, le mot "meilleur" se référant à la sécurité. Cela ne signifie pas qu'il est "le meilleur" pour la plupart des cas d'utilisation, et OTP a 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é du Bureau du Procureur, c'est la paresse des êtres humains; nous sommes naturellement poussés à faire ce qui est le plus facile, et cela a historiquement conduit les gens à prendre des décisions vraiment osées qui leur ont coûté la sécurité de leur canal de communication. Parfois, des humains paresseux décident de réutiliser des clés une fois que leur livre de clés ou de code est épuisé et qu'ils n'ont pas les moyens d'en générer et de transporter un nouveau. Le résultat de cela peut être bien pire que de cesser complètement la communication.
Définissez le mieux et la réponse peut être oui ou non.
Le principal problème est l'échange de clés sécurisé! Si vous pouvez en quelque sorte vous connecter à un serveur toujours en ligne et communiquer avec ce serveur 100% sécurisé - pourquoi ne pas simplement relayer votre message sur ce serveur?
Un scénario parfaitement valable est le suivant: vous rencontrez quelqu'un en personne et échangez des OTP avec lui. Après cela, vous pouvez communiquer en toute sécurité avec lui aussi longtemps que dureront les OTP. Pour garantir l'intégrité des messages, vous ajouterez N octets aléatoires à votre texte en clair, puis hacherez tout avant de chiffrer avec le protocole OTP (je compresserais également le texte en clair avant le chiffrement pour garantir une taille plus petite et une densité d'informations plus élevée). Cela garantira à la fois l'authentification et le cryptage. Parce que l'authentification consiste essentiellement à vérifier que l'autre partie connaît un secret, que lui seul peut connaître. Mais avec les clés secrètes symétriques, la clé est déjà un secret que seuls deux d'entre vous connaissent, donc si un message déchiffre avec succès 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 souhaitez utiliser OTP contre les approches de force brute, vous pouvez tout aussi bien utiliser un cryptage symétrique suffisamment grand (comme AES) qui est également assez impossible à briser. La partie intéressante de la cryptographie est l'échange de clés. Comment puis-je faire tout ce cryptage/authentification sans rencontrer tout le monde en personne avec qui je veux communiquer en toute sécurité? C'est pourquoi le cryptage asymétrique existe.
Donc OTP résout un problème assez bon qui est déjà assez bien résolu (cryptage symétrique) mais ne résout pas du tout les vrais problèmes, qui sont la raison du cryptage asymétrique!