Secret de clé vs secret d'algorithme

c'est une déclaration bien connue

" La sécurité cryptographique doit reposer sur une clé secrète au lieu d'un algorithme secret ."

Je voudrais poser des questions à ce sujet. Et quelles sont leurs différences?

Je vois la chose évidente que pour un système multi-utilisateurs, la génération d'une clé est extrêmement simple que la génération d'un alghorithme distinct pour chaque paire d'utilisateurs (et même pour une seule paire d'utilisateurs, on pourrait affirmer que la mise à jour de la clé est plus facile)

Mais, est-ce le seul argument?

Je veux dire, si nous définissons

AlgorithmA = AlgorithmX + key A
AlgorithmB = AlgorithmX + key B

Ensuite, un changement sur la clé n'est pas différent d'un changement dans l'algorithme.

La seule différence que je vois est que pour une nouvelle paire d'utilisateurs / clés

• La majeure partie de la structure de l'algorithme reste constante dans le cas d'une clé secrète,

• La plupart de la structure de l' algorithme doit changer dans le cas de l'algorithme secret

Mais où est la limite? "la plupart de" sens?

J'aimerais avoir plus de vues et d'indices pour comprendre pourquoi cette distinction est généralement mentionnée.

Définition du problème

Le but de la cryptographie est d'approcher un processus par lequel

crypt(x)

ne transmet aucune information sur x mais il existe une fonction decrypttelle que

decrypt(crypt(x)) == x

Si le déchiffrement et le chiffrement n'ont été effectués que dans la même exécution du même programme, vous pouvez parfaitement implémenter cela en utilisant l'état caché:

var map = {};  // A hidden hashmap.

function crypt(x) {
  var k = unique_unforgeable_value();
  map[k] = x;
  return k;
}

function decrypt(k) { return map[k]; }

En pratique cependant, cryptet decryptsont appelés par différents programmes ou différentes exécutions du même programme, nous devons donc approximer en cryptutilisant une fonction déterministe dont la sortie ne peut pas être distinguée de bits aléatoires - elle doit être incompressible (au sens du codage Shannon) donc aucun bit de structure supplémentaire ne peut être utilisé pour glaner des informations sur x.

Les algorithmes sont très structurés donc compressibles. Nous avons donc besoin d'un moyen d'obtenir un caractère aléatoire apparent tout en conservant le déterminisme requis pour .$decrypt \circ crypt = identity$

Réponse

En curry un algorithme compressible simple avec un secret incompressible

crypt = crypt_algo(secret)
decrypt = decrypt_algo(secret)

nous pouvons approximer l'objectif ci-dessus. cryptet decryptont un contenu d'informations élevé en raison du contenu d'informations élevé de secret même si crypt_algoet decrypt_algoont un contenu d'informations faible.

secretdoit être tenu à l'écart des attaquants pour que cela fonctionne, car sinon un attaquant pourrait simplement faire le curry ci-dessus. L'algorithme n'a pas besoin d'être gardé secret car il ne fournit qu'une petite partie du contenu informationnel de la fonction curry.

Caveat

"La sécurité cryptographique doit reposer sur une clé secrète au lieu d'un algorithme secret."

Je suis en désaccord avec la place d'une partie.

Vous pouvez obtenir une certaine défense en profondeur en gardant les deux secrets, mais les tests crypt_algosont difficiles, donc historiquement, les algorithmes secrets développés en interne par des amateurs ont fait pire lorsqu'ils sont soumis à une attaque que ceux qui ont été soigneusement examinés par un grand nombre de cryptographes professionnels. C'est pourquoi la sécurité par obscurité a obtenu une mauvaise réputation à juste titre. L '"obscurité" se réfère ici aux tentatives de garder l'algorithme secret comme substitut pour protéger correctement les clés.

La distinction que vous voulez faire entre la clé et l'algorithme proprement dit n'est pas basée sur le fait que la majeure partie de l'opération soit contenue dans l'un ou l'autre, mais sur la complexité. Je ne parle pas ici de complexité algorithmique, mais de complexité au quotidien: difficulté à comprendre et à raisonner.

L'algorithme proprement dit est complexe et difficile à raisonner. Il effectue généralement tout un tas de manipulations de bits d'apparence arbitraire, d'opérations logiques et arithmétiques et de mélange général des données. Il est très difficile pour un profane ou même pour un cryptographe de savoir à quel niveau de confidentialité toutes ces manipulations vous achètent réellement, et à quel type de cryptanalyse il pourrait être vulnérable. Donc, la meilleure façon d'avoir confiance en la sécurité de l'algorithme est de le mettre à découvert et de le faire réviser par des experts le plus largement possible. RENDRE PUBLIC.

La clé, d'autre part, est un concept simple: c'est un tas de bits qui doivent être aléatoires. Il n'est pas nécessaire de revoir la clé pour garantir l'exactitude de la cryptographie. Toute clé est censée être aussi forte que toute autre clé (et si ce n'est pas le cas, elle peut en principe être découverte en examinant l'algorithme, pas la clé). Nous savons que la qualité du caractère aléatoire disponible pour générer des clés est loin d'être parfaite, donc dans la pratique, certaines clés peuvent être faibles en raison du manque de caractère aléatoire, mais au moins tout le monde peut le savoir sans avoir besoin d'être un cryptographe expert et sans avoir à faire une analyse difficile de la clé qu'un bon caractère aléatoire mènera à une bonne clé. Donc, utilisez le meilleur caractère aléatoire dont vous disposez, vous n'avez pas besoin (NE DOIT PAS!) De partager la clé avec tout le monde afin d'avoir confiance en votre crypto.

J'ai posé la même question il y a quelques années à l'un des experts bien connus de la cryptographie.

Le point le plus intéressant ici est que vous pouvez penser à la clé pour contenir le code de l'algorithme et l'algorithme étant une simple machine de Turing universelle (UTM). N'oubliez pas que nous voulons faire est d'avoir un algorithme fixe pour la tâche cryptographique qui ne change pas d'une exécution de l'algorithme à une autre exécution, si vous considérez que la clé fait partie de l'algorithme, alors l'algorithme doit changer à chaque fois pour assurez-vous qu'il est sécurisé. Avec un algorithme fixe et une clé choisie au hasard, nous n'avons pas ce problème.

La différence d'origine est plus claire si vous pensez à la cryptographie pré-moderne. Si l'adversaire connaissait l'algorithme, tout était perdu, cela ne servirait à rien, garder l'algorithme était essentiel. Si dans un cas particulier, l'algorithme était connu, tout serait perdu pour toutes les utilisations futures. Dans la cryptographie moderne, la clé ne fait pas partie de l'algorithme , elle est choisie au hasard , révélant que l'algorithme cryptographique (et même les clés précédemment utilisées) ne compromet pas la sécurité de ses utilisations futures car à l'avenir, la clé sera juste une autre chaîne choisie au hasard et qui garantirait la sécurité, les clés utilisées précédemment ne sont d'aucune aide pour interrompre la nouvelle exécution.

Alors, que se passe-t-il si nous considérons UTM plus une clé aléatoire? À moins que la clé ait une belle structure, vous ne pouvez pas prouver que l'algorithme sera sécurisé, par exemple une clé choisie au hasard dans la distribution uniforme ne fonctionnera pas. La clé devrait être "essentiellement" un algorithme fixe plus une chaîne aléatoire, auquel cas elle n'est pas vraiment différente du déplacement de la partie algorithme fixe de la clé en UTM, elle ne change pas d'une exécution à l'autre.