Sans preuve de sécurité, un algo n'est jamais garanti.
La notion d'algorithme "sûr" telle que je l'ai entendue pratiquer en séminaires/groupes de travail, c'est:
* la force brute va mettre potentiellement des millions d'années à le casser avec les machines actuelles;
* tous les trucs que l'on connaît et qui permettent d'affaiblir au moins une méthode de crypto ancienne, n'apportent pas d'amélioration fulgurante sur cette force brute.
Cette notion de sécurité non garantie est pratique, mais a quelques inconvénients puisqu'une méthode sûre dans ce sens peut tomber:
* par chance: vous commencez votre attaque d'une clef à un endroit choisi au hasard, et vous tombez pile à côté de la clef réelle (très improbable);
* par progrès technologique: les machines deviennent des millions de fois plus puissantes soudainement (relativement improbable);
* par progrès scientifique: on trouve une nouvelle attaque (c'est souvent)
Pour info, les labos de crypto jouent à "la mienne est meilleure" (de méthode de cryptage); certains proposent une nouvelle méthode (ou une variante d'une méthode existante), et les autres rétorquent "Non, en faisant comme ci, comme ça, on la casse, ta méthode, essaie plutôt ça..."; bref, c'est assez amusant d'être assis dans les tribunes et d'admirer le spectacle.
Si vous voulez perdre votre confiance mal placée dans les méthodes de crypto actuelles, allez lire les conditions qu'on se donne sur les nombres premiers avant de les utiliser pour crypter, et dites-vous que chaque condition est apparue en réponse à une attaque possible...
Snark
PS1: si vous trouvez une liste qui se contente de demander "p, q: deux grands nombres premiers", vous n'avez pas trouvé une bonne page, les bonnes commencent par ça, puis enchainent sur:
* pas trop près l'un de l'autre
* pas congrus à bidule modulo machin
* p-1 ne doit pas se décomposer avec des nombres premiers trop petits
* ...
PS2: avant qu'on me pose la question, oui, j'utilise ssh et pas telnet, parce qu'entre rien du tout et une passoire, je préfère encore la passoire!
[^] # Re: plusieurs algos avec grosses clés
Posté par Snark_Boojum . En réponse à la dépêche Tentative d'insertion d'une porte dérobée dans le noyau Linux. Évalué à 3.
La notion d'algorithme "sûr" telle que je l'ai entendue pratiquer en séminaires/groupes de travail, c'est:
* la force brute va mettre potentiellement des millions d'années à le casser avec les machines actuelles;
* tous les trucs que l'on connaît et qui permettent d'affaiblir au moins une méthode de crypto ancienne, n'apportent pas d'amélioration fulgurante sur cette force brute.
Cette notion de sécurité non garantie est pratique, mais a quelques inconvénients puisqu'une méthode sûre dans ce sens peut tomber:
* par chance: vous commencez votre attaque d'une clef à un endroit choisi au hasard, et vous tombez pile à côté de la clef réelle (très improbable);
* par progrès technologique: les machines deviennent des millions de fois plus puissantes soudainement (relativement improbable);
* par progrès scientifique: on trouve une nouvelle attaque (c'est souvent)
Pour info, les labos de crypto jouent à "la mienne est meilleure" (de méthode de cryptage); certains proposent une nouvelle méthode (ou une variante d'une méthode existante), et les autres rétorquent "Non, en faisant comme ci, comme ça, on la casse, ta méthode, essaie plutôt ça..."; bref, c'est assez amusant d'être assis dans les tribunes et d'admirer le spectacle.
Si vous voulez perdre votre confiance mal placée dans les méthodes de crypto actuelles, allez lire les conditions qu'on se donne sur les nombres premiers avant de les utiliser pour crypter, et dites-vous que chaque condition est apparue en réponse à une attaque possible...
Snark
PS1: si vous trouvez une liste qui se contente de demander "p, q: deux grands nombres premiers", vous n'avez pas trouvé une bonne page, les bonnes commencent par ça, puis enchainent sur:
* pas trop près l'un de l'autre
* pas congrus à bidule modulo machin
* p-1 ne doit pas se décomposer avec des nombres premiers trop petits
* ...
PS2: avant qu'on me pose la question, oui, j'utilise ssh et pas telnet, parce qu'entre rien du tout et une passoire, je préfère encore la passoire!