Le choix de l'algorithme de chiffrement n'ajoute-t-il pas l'entropie par lui-même?
Disons que quelqu'un a mes données chiffrées et qu'il veut les déchiffrer. Les gens parlent toujours de la façon dont la longueur de la clé (par exemple 256 bits) décide de l'entropie du cryptage, ce qui est totalement logique. Si l'attaquant essaie tous les 2256 possibilités, ses arrière-arrière-… -grand-enfants auront mes données.
Mais que faire si toutes les années il utilisait le mauvais algorithme? Le choix de l'algorithme lui-même n'ajoute-t-il pas aussi l'entropie ou ai-je tort de supposer cela? Donc, au lieu de nommer mon fichier super_secret.aes256 Je voudrais juste le nommer super_secret.rsa256 ou peut-être même ne pas lui donner un fichier se terminant du tout?
Si vous concevez un cryptosystème, la réponse est Non . principe de Kerckhoffs déclare "Un cryptosystème doit être sécurisé même si tout ce qui concerne le système, à l'exception de la clé, est de notoriété publique." Redéfinie comme la maxime de Shannon, cela signifie "il faut concevoir des systèmes en supposant que l'ennemi se familiarisera immédiatement avec eux".
Faire l'hypothèse que l'attaquant n'apprendra pas votre algorithme est la sécurité par l'obscurité , une approche de la sécurité considérée comme inadéquate.
S'appuyer sur l'attaquant pour ne pas connaître l'algorithme n'ajoutera aucun travail de son côté, car selon Kerckhoff, il ou elle le sait, ou on peut raisonnablement s'attendre à ce qu'il le découvre. S'il n'ajoute aucune incertitude, il n'ajoute aucune entropie. Et leurs capacités ne sont pas quelque chose que vous pouvez quantifier.
Dans le cas d'un cryptosystème perdu, comme vous le décrivez, il y a généralement suffisamment d'informations historiques ou statistiques pour déterminer la nature de l'algorithme (sinon la clé elle-même). Mais vous ne pouvez pas concevoir un système en supposant qu'il sera perdu dès qu'il est utilisé. C'est OpSec, pas de cryptographie.
[~ # ~] modifier [~ # ~] Les commentaires ont mentionné l'utilisation de la sélection d'algorithmes comme partie de la clé. Le problème avec cette approche est que la sélection de l'algorithme doit nécessairement être déterminée avant le décryptage des données. C'est exactement ainsi que fonctionnent aujourd'hui les protocoles tels que TLS.
Si vous cherchez vraiment à mélanger les algorithmes ensemble et à utiliser un facteur clé pour déterminer des choses comme la sélection de la S-box, etc., vous créez efficacement un nouvel algorithme singulier (en adoptant tous les risques bien connus que le roulage du vôtre) implique.) Et si vous avez créé un nouvel algorithme, alors tous les bits de la clé font partie de ce calcul d'entropie. Mais si vous pouvez indiquer des bits spécifiques qui déterminent l'algorithme au lieu du matériel clé, vous devez toujours les traiter comme des bits de protocole et les exclure.
En ce qui concerne la confidentialité des algorithmes, votre protocole peut être secret aujourd'hui, mais si l'un de vos agents est découvert et que son système est copié, même si aucune clé n'est compromise, les anciens messages n'utilisent plus d'algorithmes secrets. Toute "entropie" que vous leur avez attribuée est perdue et vous ne la connaissez peut-être même pas.
En termes pratiques, non, comme réponse de John explique clairement.
En théorie, si vous disposiez de suffisamment de méthodes de cryptage sécurisées parmi lesquelles choisir, vous pourriez potentiellement sélectionner une méthode au hasard et l'utiliser pour crypter les données en utilisant - par exemple - une clé 256 bits. Le choix de l'algorithme utilisé devrait être "ajouté" à la clé et faire partie du " à ne pas révéler secret " (en prenant l'entropie combinée à 259 bits s'il y avait huit algorithmes de chiffrement à choisir).
Les problèmes avec cela incluent:
Seul un petit nombre de bits est ajouté: huit algorithmes n'ajoutent que trois bits d'entropie. Pour ajouter huit bits (pour un total de 264 bits avec une clé de 256 bits), il faudrait 256 algorithmes de chiffrement différents. Trouver assez d'algorithmes sécurisés pour faire une différence pratique est presque certainement beaucoup plus difficile que d'étendre simplement la longueur de clé d'un seul attaquant connu de l'attaquant , algorithme.
Il faut "étendre" la clé avec le choix de l'algorithme: cela signifie passer le choix à "l'utilisateur" à "mémoriser" à côté de la clé normale. Cela complique grandement le processus de gestion des clés. Le stockage du choix dans les données chiffrées est un non-démarreur, car un attaquant ayant une "connaissance totale" serait en mesure de trouver les informations et de savoir quel algorithme utiliser.
Si l'un des algorithmes choisis laisse une sorte d '"empreinte digitale" qui permet à un attaquant d'identifier l'algorithme utilisé (ou au moins de réduire la gamme d'algorithmes possibles), cela annulera (partiellement) les bits supplémentaires d'entropie.
Dans l'ensemble, il est beaucoup plus facile d'étendre la longueur de la clé utilisée et ne vous inquiétez pas qu'un attaquant connaisse la méthode de cryptage.
Les réponses de @John Deter et @TripeHound expliquent très bien les choses, mais je voulais donner un exemple qui mettrait le principe de Kerckhoffs en contexte. Il est naturel d'aborder ces questions du point de vue d'un attaquant extérieur, mais ce n'est pas le seul modèle de menace pertinent. En fait, environ la moitié de toutes les violations de données proviennent d'agents internes (alias employés, sous-traitants, etc.), avec un mélange de fuites accidentelles et intentionnelles.
Vecteurs de menace plus réalistes
Avoir un algorithme de chiffrement caché peut aider un attaquant extérieur s'il ne peut pas facilement déduire quel système vous avez utilisé. Cependant, il n'offre aucune protection supplémentaire contre un attaquant interne qui aurait accès à votre code. À titre d'exemple extrême, si votre système conserve des informations d'identification personnelle (PII) critiques dans votre base de données, mais que les informations d'identification d'accès à la base de données de production, les algorithmes de cryptage et les clés de cryptage sont stockés directement dans votre référentiel de code, vous avez effectivement donné à tous ceux qui y ont accès à votre référentiel de code accès à tous les PII de vos clients.
Bien sûr, vous ne voulez pas faire cela, donc vous gardez les systèmes de production séparés de tout le monde attend des administrateurs, vous gardez les clés de chiffrement stockées dans un système de gestion de clés séparé accessible (autant que possible) uniquement à l'application, etc. les développeurs savent quels algorithmes de chiffrement sont utilisés (car ils peuvent le voir dans le référentiel de code), mais ils n'ont pas accès à la base de données de production, et même s'ils avaient un accès en lecture à la base de données, ils n'auraient pas les clés décrypter les données qui s'y trouvent.
Appliquer le principe de Kerckhoff
C'est tout l'intérêt du principe de Kerckhoffs - la seule chose que vous devez garder un secret est le secret réel (aka votre clé de cryptage). Tout le monde peut être connu de tout le monde et vous êtes toujours en sécurité. Ce qui est bien, car garder un seul secret est déjà assez difficile. Essayer de concevoir un système qui cache non seulement les clés mais aussi les algorithmes de cryptage et d'autres détails du plus grand nombre de personnes possible est un peu plus difficile et plus susceptible d'échouer.
Bref, les gens ne savent pas garder le secret. Par conséquent, la conception de votre système afin que vous ayez moins de secrets à garder vous rend plus plus sûr, même si cela semble contre-intuitif. Après tout, ce que vous proposez a du sens à un certain niveau: pourquoi devrions-nous seulement crypter nos données? Cachons aussi la méthode de cryptage et soyons plus sûrs! Dans la pratique cependant, cacher plus de choses vous donne plus de place pour faire des erreurs et un sentiment de fausse sécurité. Il est préférable d'utiliser une méthode de cryptage efficace qui rend la conservation des secrets aussi simple que possible - cachez la clé et le message est sécurisé.
De manière abstraite, s'il y avait 2 ^ n schémas de cryptage qui étaient exactement aussi difficiles à casser et avaient le même espace de clés possibles, alors bien sûr, vous pourriez définir un nouveau schéma de cryptage comme "choisir au hasard l'un de ces 2 ^ n schémas" et considérer efficacement ces n bits à ajouter à la clé.
Mais dans la pratique, même si cela était possible, cela représente beaucoup de complexité inutile lorsque vous pouvez simplement choisir un seul algorithme et rendre la clé un peu plus longue.
Je pense que la question des PO fait preuve de perspicacité et la réponse est, du moins en théorie, oui. Il y a quelque chose ici. Je pense que c'est le premier point à souligner. Les réponses données sont principalement du point de vue: dans la pratique, cela ne fonctionne pas comme ça. Ceux-ci ne sont pas faux mais je pense qu'ils ratent la validité/l'intérêt du point d'OP.
La façon dont je raisonne ceci: D'un point de vue théorique de la boîte noire, le choix entre 2 systèmes de cryptage est analogue au choix du premier bit de la clé. En fait, c'est vraiment la même chose (si vous ajoutez le bit en arrière). Dans une boîte noire, la clé n'a vraiment rien de spécial. Ils sont juste un bon moyen d'énumérer vos options dont les transformations de chiffrement que vous souhaitez utiliser.
Pour voir ceci:
Supposons que je crée une nouvelle variante d'AES128, appelons-la JES_0_128. La façon dont cela fonctionne est la suivante: j'ajoute un codage binaire de 0 (dans ce cas, 128 zéros) à l'avant de la clé fournie et je l'utilise dans (standard) AES256. Ensuite, j'en fais un autre appelé JES_1_128: un encodage de 1 etc jusqu'à JES_ (quel que soit 2 ^ 128 en base 10) _128. Tous ces algorithmes de cryptage à clé 128 bits sont parfaitement valides. Mais si vous ne savez pas lequel ... c'est un algorithme de cryptage à clé de 256 bits. AES256 pour être précis. Ce qui est en effet beaucoup plus d'entropie.
Les différences signalées par les autres réponses sont qu'en pratique une clé est un très bon moyen de choisir lequel des 2 ^ 256 algorithmes de chiffrement AES-256 utiliser. Il est flexible, bien compris et laisse la génération et la confiance du secret mutuel aux utilisateurs. Pourquoi utiliser autre chose?
D'un autre côté, choisir une des quelques familles d'algorithmes de chiffrement à 256 bits à utiliser et le coder en dur n'est pas un très bon moyen. Même par rapport à une très petite augmentation de la taille des clés. Ou pas du tout. Autant le dire à tout le monde. D'un point de vue pratique/logiciel d'écriture/type, il n'est pas du tout sûr de s'en remettre à un attaquant de tout intérêt. Il y a une multitude de raisons. Notamment parce que si un attaquant avait une copie de la valeur que vous avez choisie, il serait facile de la tester. Mais ce ne sont que des considérations pratiques ...
Je pense que c'est une bonne façon de voir les choses:
Vous avez un secret, qui peut être une clé de 256 bits, ou un mot de passe à partir duquel vous dérivez cette clé, ou l'un de ces plus d'autres informations comme l'algorithme de chiffrement que vous avez utilisé.
L'attaquant veut deviner votre secret. Ils le font en essayant diverses possibilités jusqu'à ce qu'ils trouvent la bonne ou qu'ils manquent de temps, d'argent ou de motivation.
Vous n'avez aucune idée des possibilités qu'ils essaient . Dans votre question, vous dites "et si toutes les années il utilisait le mauvais algorithme?" et la seule réponse à cela est "et s'il ne l'était pas?" Vous n'avez aucun contrôle sur cela. Si vous saviez quelles possibilités l'attaquant allait essayer, vous pourriez simplement choisir tout ce qui ne figure pas sur leur liste comme votre secret, et le problème de sécurité serait trivialement résolu.
Ce que vous pouvez faire, cependant, est d'estimer approximativement le nombre de possibilités qu'ils peuvent essayer avant de manquer de temps et/ou d'argent, en fonction de l'état de la technologie informatique. Cela suppose qu'ils n'ont pas secrètement accès à une technologie que le reste du monde n'a pas, comme l'informatique quantique ou une porte dérobée dans AES - ce qui est probablement une hypothèse sûre car ils auraient mieux à faire dans ce cas que essayez de déchiffrer votre mot de passe. (Cf Couper Lex Luthor un chèque , mais voir aussi cette réfutation .)
Vous pouvez également prouver le résultat suivant: si vous choisissez votre secret uniformément au hasard (en utilisant un RNG de haute qualité) à partir de n possibilités, et l'attaquant essaie k possibilités, quoi qu'il arrive ils sont , la chance qu'ils devineront votre secret est au plus k / n .
La bonne chose est que n croît de façon exponentielle avec la quantité d'informations que vous devez stocker/mémoriser, tandis que k ne croît que de manière linéaire avec le temps/argent qu'ils dépensent, il n'est donc pas difficile de faire k / n très petit.
Donc, vous devez choisir votre secret de manière uniforme au hasard parmi un large éventail de possibilités. Une clé symétrique aléatoire de 256 bits est choisie uniformément dans un ensemble de taille 2256, qui est (bien plus que) assez grand.
Vous pouvez également choisir au hasard dans un sac de paires (algorithme, clé), mais cela est inutile car tout algorithme unique offre déjà beaucoup de choix.
Vous pouvez choisir un algorithme obscur et espérer que l'attaquant ne l'essayera pas, mais ce n'est plus le choix aléatoire , et donc vous ne pouvez pas prouve que cela aide du tout. S'il n'y avait pas d'autres options, ce serait mieux que rien, mais il y a d'autres options.
C'est la raison fondamentale pour laquelle les cryptographes vous conseillent de ne traiter que la clé comme votre secret: il y a beaucoup de clés et les clés sont la chose la plus facile à choisir au hasard. Vous n'avez besoin de rien d'autre.
Si vous cryptez simplement quelque chose avec un algorithme et prétendez qu'un autre a été utilisé, le principe de Kerckhoff s'applique comme indiqué dans d'autres réponses, donc c'est un peu inutile, au moins contre un attaquant connaissant notre implémentation. Cela "fonctionnera" toujours contre un attaquant qui, par ex. vole le fichier crypté de votre OneDrive ou de n'importe quel magasin cloud sans rien savoir à ce sujet.
Si vous avez besoin que le choix de l'algorithme de chiffrement soit inclus dans le processus de déchiffrement (c'est-à-dire que votre outil choisit un parmi plusieurs algorithmes, en fonction de ce que vous saisissez), alors vous ajoutez effectivement des bits à votre longueur de clé. Le principe de Kerckhoff s'applique pas ici. Il est cependant un peu difficile d'ajouter une quantité importante de bits - il faudrait choisir parmi de nombreux algorithmes - et cela n'a aucun sens (voir le dernier paragraphe).
Dans les deux cas, tout ce que vous voulez faire est à peu près inutile. L'hypothèse selon laquelle les arrière-arrière-petits-enfants de quelqu'un peuvent avoir vos données s'ils investissent quelques milliards dans l'équipement et la facture d'élictricité est sans doute vraie pour les clés dans la plage 90-100 bits. Bien qu'en réalité, personne (pas même la NSA) ne ferait cela. Le rapport coût-bénéfice ne le révèle pas. L'ingénierie sociale ou la torture suivie d'un meurtre est une approche beaucoup moins chère, plus rapide et plus pratique.
Pour tout ce qui est sensiblement supérieur à 110 bits environ, une attaque par force brute n'est pas réaliste même si vous négligez le rapport coût-bénéfice. Vous devriez être plus préoccupé par les portes dérobées intégrées à AES, ce qui est plus susceptible d'être le cas que vous ne voyez une seule clé de 128 bits brisée par la force brute pendant votre durée de vie.
Maintenant, la simple idée de casser une clé de 256 bits via la force brute est carrément ridicule, et l'idée d'ajouter des bits en plus est absurde, cela ne fait aucune différence. Impossible ne vaut pas mieux que "impossible".