Dans son article, il propose aussi une application pratique permettant de construire un "RSA breaker" 4x plus performant à coût égal. En conséquence, les clés PGP/RSA de taille plus petite que 2048 bits seraient cassables "facilement".
Et certains en profitent pour ajouter que "nos amis" de la NSA ont déjà ça dans leur carton (gravés dans le silicium) depuis un moment :-(
Aller plus loin
- Mail dans la liste Cryptography (41 clics)
- Article NfsCircuit de DJ Berstein (47 clics)
# euh
Posté par Troy McClure (site web personnel) . Évalué à 10.
Si on prend en compte le ton alarmiste du mail, l'avancée doit être plus importante qu'une division par 4 du temps de cassage, enfin je pense.
[^] # Re: euh
Posté par GP Le (site web personnel) . Évalué à 9.
considérait n assez grand pour dire que la clef était secure... il n'en faut plus maintenant que n/4 et on s'affole !?
Certe
j'imagine que n étant suffisament grand pour rester grand quand on le divise
par quatre, non ?
Oui, mais non ! Il faut choisir :
Tu comprendras qu'il faut alors parfois choisir n pas trop grand !
bref n/4 peut devenir trops petits
[^] # Re: euh
Posté par Benoit Rousseau . Évalué à 3.
Est ce qu'il faut vraiment que le cryptage/decryptage de mails se fasse en instantane ?
[^] # Re: euh
Posté par boubou (site web personnel) . Évalué à 3.
[^] # Re: euh
Posté par gabuzo . Évalué à 5.
Ceci dit un facteur 4 ne change pas vraiment l'ordre de grandeur. S'il faut 1000 ans pour "casser" une clé il en faudra 250 avec cette nouvelle méthode et s'il fallait 4 secondes il n'en faudra plus que 1. Suivant la loi de Moore ce facteur 4 se traduit pas 3 ans d'avance en terme de puissance CPU. Pour donner un ordre d'idée de la durée de vie d'un algo on peut, par exemple s'inpirer du DES qui a été adopté en novembre 1976 il y a bientôt 26 ans. Cet algo est maintenant dépassé, certes mais sa durée de vie est sans commune mesure avec les 3 ans d'avance que donne cette nouvelle méthode de factorisation.
# A vos GPG
Posté par Anonyme . Évalué à 10.
Une petite aide pour ceusses qui n'en veulent -> http://www.vilya.org/gpg/(...)
[^] # Re: A vos GPG
Posté par Jean-Yves B. . Évalué à 10.
[^] # Re: A vos GPG
Posté par Anonyme . Évalué à 6.
[^] # Re: A vos GPG
Posté par Annah C. Hue (site web personnel) . Évalué à 10.
coin@mare $ gpg --version
gpg (GnuPG) 1.0.6
[...]
Algorithmes supportés:
Cipher: 3DES, CAST5, BLOWFISH, RIJNDAEL, RIJNDAEL192, RIJNDAEL256, TWOFISH
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG
Hash: MD5, SHA1, RIPEMD160
[^] # Re: A vos GPG
Posté par Cédric Foll . Évalué à 10.
A ma connaissance Diffie-Helman c'est un échange de clef (cf http://www.rsasecurity.com/rsalabs/faq/3-6-1.html(...)).
Je ne connais pas d'algo de chiffrement DH, peut être que je me trompe mais je doute qu'un algo de chiffrement porte le même nom qu'un algo d'échange de clefs.
DH permet à deux personne ne possédant aucune information l'une sur l'autre d'avoir une connection chiffrée. La force est qu'une personne capable de sniffer la connection (y compris l'échange de clefs) est incapable de déchiffrer la transmission. Ceci repose sur le concept de clef publique.
En fait les deux partis génères un couple de clef pour la connection et s'envie leur clef publiques.
A noter qu'un pirate qui en plus de pouvoir chiffrer est capable de rediriger les paquets IP peut faire une attaque de type man in the middle. Pour éviter ça on doit avoir en plus une autorité de certification. Mais là faut oublier le joli modèle ou aucun des deux partis ne connais quoi que ce soit sur l'autre avant le début de la comm.
[^] # Re: A vos GPG
Posté par Jean-Yves B. . Évalué à 10.
Le « Diffie » était resté gravé dans ma mémoire, ça et le fait de m'intérésser aux VPN en ce moment, j'ai sorti le premier mot-clef avec « Diffie » dedans qui me venait à l'esprit (pas bien).
Il faut lire DSA+ElGamal bien sûr. Cela dit, après lecture du papier de djb et des commentaires associés, ce serais plus du côté des versions sur courbes elliptiques qu'il faudrait chercher.
# A quand les clés 16384 bits ?
Posté par David Bober (site web personnel) . Évalué à -4.
Autant viser tres haut tout de suite que se poser des question apres... Dans la limmite de l'utilisable tout de meme, mais la plupart des document cryptés sont legés..., et pour les communications constantes (je pense aux reseaux sans fil, ou le cable) va faloir crypter encore plus fort, d'autant plus que les clés ne changent parfois que tres rarement, voir jammais (cable docsis) :/
[moua]
[moua]
[^] # Re: A quand les clés 16384 bits ?
Posté par Julien Mulot (site web personnel) . Évalué à 10.
je vous rappels ou vous apprends que quand l'on ajoute un seul et unique bit a la clef, cela double (x2) l'espace des possibilite et donc theoriquement le temps de cassage.
Donc dans ce cas il suffirait de rajouter 2 bits a la clef.
[^] # Re: A quand les clés 16384 bits ?
Posté par boubou (site web personnel) . Évalué à 7.
[^] # Re: A quand les clés 16384 bits ?
Posté par cornofulgur . Évalué à 4.
Pour multiplier par 4, il faut juste rajouter 2 bits au bon bout. C'est pas dramatique. On passera de 128 bits à 130.
Notons au passage qu'il y a déja eu beaucoup de FUD à propos de la crypto, alors méfions nous. :)
[^] # Re: A quand les clés 16384 bits ?
Posté par Boa Treize (site web personnel) . Évalué à 10.
Bonne vieille réaction sécuritaire. Si on n'analyse pas les problèmes, on s'aperçoit généralement beaucoup plus tard qu'on a mal agi, ou q'un a porté ses efforts au mauvais endroit. Dans ton cas, j'espère que tu as un bon Pentium Cinq, parce que rien ne dit que les calculs sont proportionnels à la taille de la clé. Par exemple, ça te dit de multiplier les temps de calcul par 256 ?
Ce genre de protocoles est surtout connu pour certaines grosses failles de sécurité. Bref, il s'agit de cas où l'on peut casser la sécurité quelle que soit la taille de clés. Le fait qu'une clé ne soit pas changeable prouve une mauvaise conception du système.
[^] # Un peu de maths
Posté par Cédric Foll . Évalué à 10.
Une exponentionation ça se fait en O(ln(n)).
Donc en passant de 1024 à 16384 tu multiplies juste par 16 le temps de calcul. Ça reste très correct mais c'est interdi dans à peu prêt tous les pays et je ne pense pas que PGP authorise plus de 4096 bits, GnuPG oui par contre (bien que je n'ai jamais essayé d'aussi grosse clef).
Pour le cassage d'une clef en RSA il faut factoriser un nombre, ça se fait avec un algo naif en O(racine(N)) pas en O(N). J'ai parcouru l'article sans trouver la complexité de son algo mais je doute que ce soit mieu que du O(racine(N)) vu qu'il nous donne un facteur 4, si c'était mieu plus le chiffre serai grand et plus le gain de temps serai important.
La conséquence de ça c'est qu'ajouter 2 bits ne multiplie pas par quatre le temps de cassage.
mais par racine(4)=2. Il faut ajouter 4 bits pour arriver au même résultat qu'avant cette découverte.
J'ai peut être dis qq conneries que l'on me reprenne si c'est le cas.
[^] # Re: Un peu de maths [correction]
Posté par Mouns (site web personnel) . Évalué à 3.
Pour factoriser naïvement un nombre N, il faut avoir prealablement factoriser les N-1 nombres precedents, parce que sinon, tu ne peux pas decomposer les nombres en facteurs premiers puisque tu n'a pas appliquer de test total de primalité sur ces nombres. Donc la factorisation d'un nombre N se fait en O( N^N ).
La solution erronée que tu proposais, etait en temps polynomial ce qui est aujourd'hui peu couteux, alors que la borne que je t'expose est plus que polynomiale ; c'est d'ailleurs comme ça que l'on definit les problemes NP & NP-complets, ce sont les problemes qui se traitent en un temps plus que polynomial.
[^] # Re: Un peu de maths [correction]
Posté par boubou (site web personnel) . Évalué à 6.
D'abord, on peut tester raisonnablement rapidement si un nombre est premier, et surtout on ne fait pas ça en factorisant le nombre, car c'est très coûteux (cf en dessous). On utilise un test de primalité genre Miller-Rabin.
De plus, pour le problème qui nous intéresse, on sait qu'une partie de la clé RSA (la partie intéressante) est un produit de deux nombres premiers. Il suffit donc de trouver un diviseur de la clé, sans se soucier si ce diviseur est premier. Bien entendu, c'est tout aussi coûteux.
L'algorithme proposé dans le post auquel tu réponds est effectivement mal évalué, mais ça n'a aucun rapport avec ton argument incorrect. Si on divise un nombre par un autre, le temps de calcul naïf est en (log n)^2, où n désigne le plus grand des deux nombres. Pour tester naïvement si un nombre est premier (et non pas pour le décomposer en facteurs, mais on s'en fout pour RSA), il faut donc en gros sqrt(n)(log n)^2 opérations. Le gros problème, c'est que dans cette analyse, n désigne la VALEUR de la clé, pas son nombre de bits. Or, pour une clé de p bits, la valeur de la clé est au minimum de 2^{p-1}. On a donc une complexité qui est bien exponentielle avec le nombre de bits de la clé. D'ailleurs on ne sait pas faire mieux, cf le post de CNS plus bas.
Enfin, je te conseille vivement la lecture d'un bon cours d'informatique, car les problèmes NP et NP-complets ne sont pas définis comme non polynomiaux, vu qu'il s'agit seulement d'une conjecture. La définition est assez technique et je ne vois pas trop l'intérêt de la donner ici, mais bon, ce n'est pas non polynomial.
[^] # Re:theorie des nombres, algorithmique de base, et algo de RSA
Posté par Mouns (site web personnel) . Évalué à 4.
Commençons par la fin.
NP signifie Non Polynomial, plus exactement non deterministe en un temps polynomial. On sait deja que P et NP sont des ensembles disjoint, mais la conjecture est que NP et NP-complet soit disjoint aussi, ce qui n'arrange rien, mais tous laisse penser que cela est vrai meme si il n'y a aucune demonstration.
Je parlais de factorisation pas d'autre chose. Pour factoriser un nombre N, il faut connaitre les nombres premiers qui peuvent le composer, donc il faut factoriser tous les nombres avant pour savoir si ils sont premiers ou non.
De plus, je parlais de test total de primalité, hors il n'existe aucun test total de primalité qui soit dans P, cad qui soit calculable en un temps polynomiale.
Le test de Rabin-Miller n'est pas fiable à 100%, il existe une marge d'erreur fonction du nombre d'iteration, plus il y a de tests et plus la precision est grande mais elle n'est jamais de 100%. Les autres tests comme Solovay-Strassen et Lehmann sont moins performant.
Les seules methodes fiable à 100% sur un test de primalité reste la factorisation, et cela passe par un de ces algorithmes déja connus :
- le crible quadratique
- les courbes elliptiques
- l'algorithme de monte carlo
- les fractions continues
- la tentative de division
je donne l'algo de RSA pour le principe :
soit 2 nombres premiers p et q, soit n tel que :
n= p * q
soit e un nombre aleatoire tel que e soit premier avec (p-1)*(q-1) , soit d tel que :
e * d = 1 mod (p-1)*(q-1)
pour chiffrer m en c, il suffit de faire :
c = m^e mod n
pour dechiffrer c en m, il suffit de faire :
m = c^d mod n
Mes references sont introduction à l'algorithmique de Cormen Leiserson et Rivest , Course in Number Theory and Cryptography de Koblitz, et the art of computer programming de Knuth.
voila ;-p
[^] # NP/=non-P
Posté par boubou (site web personnel) . Évalué à 6.
---------------
J'ai bien l'impression que les notions de NP etc. te posent quelques problèmes...
Commençons donc par le commencement (ça n'a rien à faire sur linuxfr, mais bon). Un problème P est un problème qu'on peut résoudre en temps polynomial, c'est-à-dire en un temps d'exécution qui dépend comme un polynome de la taille des données. Pour une définition formelle, cf http://www.claymath.org/prizeproblems/p_vs_np.pdf(...) (qui est excellent).
Deuxième définition : non-P. Un problème non-P est un problème pour lequel on sait prouver qu'il n'existe pas de résolution en temps polynomial. Il est extrêmement difficile de démontrer qu'un problème est non-P, mais ça a déjà été fait et donc on est bien entendu sûr que P /= non-P (ce qui est évident) et surtout que les deux ensembles ne sont pas vides.
Troisième définition : NP. Effectivement, NP signifie nondeterministic polynomial time, ce qui ne veut en aucun cas dire non-P. Ca veut dire polynomial sur une machine non déterministe (c'est-à-dire pas sur un ordinateur classique). La définition moderne est donnée dans l'article que j'ai cité au dessus (http://www.claymath.org/prizeproblems/p_vs_np.pdf(...)). Avec les mains, ça donne la chose suivante : un problème est NP si répondre à la question "cette donnée est elle une solution du problème ?" peut se faire en temps polynomial.
Propriété triviale : P est contenu dans NP.
Quatrième définition : NP-complet. On dit qu'un problème est NP-complet si tout problème NP peut se ramener en temps polynomial au problème étudié. En gros pour résoudre un problème NP, on bidouille l'énoncé du problème (en temps polynomial) et on donne l'énoncé bidouillé au programme qui résout le problème NP-complet : la réponse du programme est bonne pour le problème d'origine.
Bien entendu (et c'est tout l'aspect fun du problème), personne ne sait si P=NP (ou si P/=NP) (cf toujours le même papier).
Comme tu n'as pas l'air très fort, tu peux aussi lire la version pour les enfants du papier, i.e. http://www.claymath.org/prizeproblems/milliondollarminesweeper.htm(...)
Deuxième point :
----------------
Pour décomposer un nombre en facteurs premiers, il suffit d'appliquer récursivement le "cassage" à ses facteurs. J'appelle "cassage" un algorithme qui trouve un facteur non trivial d'un nombre p (i.e. différent de 1 et p). Si tu veux décomposer 20 en facteurs premiers, il te suffit de le casser, c'est-à-dire de trouver que 20=2x10 (à priori tu devrais d'abord trouver 2). Ensuite, tu casses récursivement 2 et 10 (soit 2x5) et donc 5. Moralité, tu as cassé 2,5,10 et 20, et non pas tous les nombres avants. Moralité de la moralité : arrêtes de dire des conneries.
Troisième point :
-----------------
Il existe un algorithme de cassage (cf après) polynomial, mais cet algorithme n'est juste que si la conjecture de riemann (un truc bien compliqué...) est vraie. La plupart des spécialistes pensent que la factorisation en temps polynomial est cependant peu probable. Donc ACTUELLEMENT il n'existe pas d'algo de factorisation en temps polynomial. MAIS CE N'EST PAS LE PROBLEME POUR RSA PUISQU'ON SE CONTENTE D'UN CASSAGE !!!!!!!!! Or, il se trouve qu'il n'existe pas pour l'instant d'algorithme de cassage en temps polynomial, ce qui est le bon argument pour RSA (tu fais de nouveau l'erreur pour la primalité). Bien entendu, la factorisation et le cassage sont dans NP, mais comme ils ne sont pas NP complets (enfin, on pense qu'ils ne le sont pas), les conjectures basés sur les gros problèmes NP-complets peuvent très bien ne pas s'appliquer à eux. En d'autres termes, même si tout le monde pense que les problèmes NP-complets demandent un temps exponentiel, ça n'apporte pas trop d'information sur le cassage.
Disclaimer : je suis maître de conférences en informatique. Oui, ça aide.
[^] # Re: NP/=non-P
Posté par Mouns (site web personnel) . Évalué à 4.
un probleme P est un probleme solvable en un temps polynomiale sur une machine de Turing deterministe, je pense que l'on est d'accord.
NP comme son nom l'indique, est resolvable en un temps polynomiale sur une machine de Turing non deterministe.
un probleme NP-complet est un probleme dont la resolution reste NP quelque soit son formalisme au sens de Turing. donc tout probleme NP derive d'un probleme NP-complet.
La methode exposée au point 2, me pose un probleme dans ton enoncé ... comment as tu determiné que 2 et 5 était les bons nombres ? le savais tu avant ? ce qui est faux, n'est ce pas ? il faut le verifier pour ces nombres ! C'est clair qu'il existe des heuristiqures pour simplifier la recherche, mais la methode que tu expose est la plus vieille, la plus connue et la une des moins performante pour factoriser des grands nombres.
La conjecture de Reimann, n'est ce pas celle qui dit à propos de la fonction zeta du même Reimann, que mis à part les zeros triviaux, tous les zeros sont sur la droite sigma = 1/2 ? ;-)
Quelque soit tes fonctions, expliquer est une chose, dénigrer en est une autre ;-) .
[^] # Re: NP/=non-P
Posté par Zorro (site web personnel) . Évalué à 0.
Rien qu'à vous lire, j'entrevois vaguement les encyclopédies entières qui doivent traiter de la question. Vous êtes à Polytechnique ?
Je me demande si la crypto sera un jour facilement accessible. Le gouffre me semble tellement immense entre la façade commerciale de PGP, l'utilisation en aveugle, sans comprendre, et vous...
Bon, je vais quand même terminer l'Histoire des Codes Secrets, histoire d'avoir quelques modestes bases... Un Que sais-je, peut-être, après...
Chapeau à vous deux quand même, pour le frisson abyssal, descartien, que votre lecture m'a procuré.
[^] # Introduction à la cryptographie
Posté par Mouns (site web personnel) . Évalué à 3.
Sinon, un bouquin simple dessus en etant tres partique pour le développeur, c'est cryptographie appliqué de Bruce Schneier.
[^] # Re: Introduction à la cryptographie
Posté par Cédric Foll . Évalué à 1.
C'est pas pour le développeur, juste pour le curier, c'est bien expliqué didactique, pas si compliqué que ça mathématiquement (niveau math sup bio ;-)).
Et écrit par une star de la crypto qui est aussi directeur du labo d'informatique d'Ulm.
[^] # Re: NP/=non-P
Posté par Cédric Foll . Évalué à 0.
Voila ce que je fais
prem_fact(n)
pour i de 2 à racine(n) faire
si i divise n
retourne i
fin
retourne 0
fin
Voilà, je fais dans le pire des cas (si n est premier ou carré de nb premier) racine(n) tests.
on multiplie par la complexité de l'opearation 'i divise n' et c'est fini.
On a pas besoins d'un crible d'hérastotruc.
[^] # Re: NP/=non-P
Posté par Mouns (site web personnel) . Évalué à 1.
Pour coder un chiffre de type RSA, il faut faire des tests de primalités, pour determiner les nombres principaux de l'algorithme. Pour casser RSA, il faut factoriser des nombres pour obtenir les nombres principaux qui ont été determinés par les tests de primalités, donc c'est plus complexe.
[^] # Re: NP/=non-P
Posté par Cédric Foll . Évalué à 1.
c'est une factorisation.
N=p*q (parce que l'on bosse sur RSA)
Le résultat retourné (i) est égal soit à p soit à q.
[^] # Re: Un peu de maths [correction]
Posté par Cédric Foll . Évalué à 3.
Autant pour moi. J'avais oublié le temps nécessair à la division.
Je n'avais compté que le nb de test à faire qui lui est en racine(n).
Par contre c'est quoi cet algo en log(n)^2 pour une division?
Je connaissais juste qq chose en O(n*log(n)) (je crois) via une FTT (transformé de fourier rapide).
Sinon, je pense que Mous il mouline un peu dans la choucroute ce matin ;-)
Pour factoriser N, un algo naif reviens à essayer de le diviser par tous les nombres inférieurs à sa racine (pour aller plus vite on vire les multiples de 2 et de 5).
Ça sert à rien avant de faire chaque test de voir si le n par lequel on va essayer de diviser est premier ou pas.
[^] # Re: Un peu de maths [correction]
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Pas sûr de moi...
Posté par Denis Bodor (site web personnel) . Évalué à 3.
Ceci ne peut-il pas jouer en augmentant simplement le nombre de bits d'une clef ?
# Keep cool
Posté par Boa Treize (site web personnel) . Évalué à 10.
Monsieur Bernstein aurait par ailleurs affirmé qu'il était trop tôt pour dire si ses idées pourront être mises en pratique sur les "grosses" clés en usage courant actuellement. Il cherche actuellement des fonds pour poursuivre ses recherches dans cette direction.
Enfin bref, ce n'est pas la première fois que l'amélioration des techniques de calcul et des technologies informatiques repousse la taille des clés jugées sures. Le principe de fonctionnement des algorithmes et des clés RSA n'a pas été remis en cause, et ces technologies restent parfaitement fiables. La vraie crise se produira le jour où un mathématicien un peu plus fou que les autres arrivera à casser l'algorithme, quelle que soit la taille des clés.
En attendant, on se retrouve avec un problème intéressant : nos logiciels sont-ils suffisamment flexibles pour permettre de changer à volonté la taille des clés, ou d'intégrer, par des plugins, de nouvelles versions de méthodes de chiffrement ? Ou allons-nous devoir racheter/attendre la prochaine version ?
Il serait immoral de ma part de ne pas citer slashdot, source d'idées pour ce commentaire. Voire notamment cette discussion : http://slashdot.org/article.pl?sid=02/02/26/179206(...)
[^] # Re: Keep cool
Posté par Julien Mulot (site web personnel) . Évalué à 10.
Peut-etre que cela ne se produira jamais. Peut-etre que la factorisation simple de grands nombres n'a pas d'existence mathematique. Peut-etre que les cryptographes avec la cryptographie asymetrique a clef publique ont atteint le Saint Graal.
nos logiciels sont-ils suffisamment flexibles pour permettre de changer à volonté la taille des clés
Le probleme pour changer sa taille de clef il faut revoquer l'ancienne de preference et ainsi perdre toute les signature de tiers de confiance que l'on avait durement acquis pour recommencer a zero !
[^] # Re: Keep cool
Posté par Olivier M. . Évalué à 10.
Si j'ai bon souvenir, un algo quantique permettrait de le faire en un temps raisonnable... reste à attendre un processeur quantique capable de faire tourner un algo ;)
[^] # Re: Keep cool
Posté par Le Pnume . Évalué à 1.
[^] # Re: Keep cool
Posté par bmc . Évalué à 0.
Je dis ça gratuitement, mais ça ressemble un peu à un coup de pub: "waaaah, j'ai trouvé un moyen de casser les clés 4 fois plus vite ! À propos, si t'as un franc ou deux..."
Bon, il est tard, ne m'en veuillez pas...
[^] # Re: Keep cool
Posté par jcat . Évalué à -1.
euh...
Tu voulais surement dire "un euro ou deux"... non ?
Bon, je sors.
[^] # Re: Keep cool
Posté par vjm . Évalué à 10.
http://www.research.att.com/~shor/papers/#quantum(...)
Par ailleurs, il existe d'excellents algorithmes pour les ordinateurs classiques factorisant de grands entiers en des temps "raisonnablement" exponentiels comme le ECM (basé sur les courbes elliptiques, très étudiées en théorie des nombres et en théorie des codes) bien que trop lent pour s'attaquer à RSA, et surtout le Number Field Sieve (NFS) de Pollard (et d'autres) qui a effectué de nombreux travaux depuis 20 ans sur les algorithmes de factorisation. Le NFS s'exécute en un temps O(e1.9(ln n)1/3(ln ln n)2/3).
http://mathworld.wolfram.com/NumberFieldSieve.html(...)
L'algorithme décrit par Bernstein est une optimisation (impressionante) du NFS comme il en est pratiquée depuis 10 ans. Pour mémoire RSA Security offre de $10000 à $200000 pour la factorisation de modulos RSA de 576 à 2048 bits.
En 1999, c'est déjà une variation du NFS qui avait permit de cracker RSA 155 (de 512 bits) en 97.5 années-cpu.
http://www.rsasecurity.com/rsalabs/challenges/factoring/(...)
Bref, belle découverte, mais pas de panique.
http://www.crypto-world.com/FactorPapers.html(...)
# RC5
Posté par Jean-Pierre Schwickerath (site web personnel) . Évalué à -2.
# NSA nous mène par le bout du nez
Posté par Rafael Pinilla . Évalué à 2.
http://linuxfr.org/comments/thread.php3?news_id=6060&com_id=817(...)
============== Début de citation
Je souhaite simplement rappeller que la NSA a été constituée à l'issue de la première guerre mondiale.
Depuis, son budget annuel est, disons, non diffusé, depuis toujours. La NSA recrute, depuis 1950,tout ce que les universités américaines forment de mathématiciens et d'informaticiens brillant.
Depuis les années 80, la NSA ne chiffre plus sa puissance de traitement informatique qu'en "hectares".
<p>
Je jette un voile pudique sur les clés NSA de windows9X.
<p>
La NSA a 50 ans d'avance sur la cryptographie théorique. On ne peut pas gauger exactement leur niveau de compétence, car il se situe à un niveau d'expertise tel que une "simple adaptation d'algorithme" de leur part peut cacher une faille mathématique que seule leur avance en mathématique fondamemtale permet d'exploiter.
<p>
Linux, OpenBSD, OpenSSH, c'est comme un tir qui leur sort par la culasse. Ils ont du mal à contrôler une mouvement si transparent (OpenSource), issu de la communauté.
Pire, les sociétés, les gouvernements, commencent à utiliser *vraiment* ce genre d'outils.
Participer aux discussions sur les fonctionnalités du noyal 2.5, c'est pour eux le meilleur moyen de placer des trous dans un mur qu'ils ne contrôlent pas. Je ne parle pas de backdoor TCP, non, trop simple, tout le monde pourrait auditer et rectifier. Sous le couvert de coller touts les patchs de sécu, il est plus simple de placer un équivalent de ssh à leur sauce. Je parle de trous théoriques dans l'inviolabilités des algorithmes.
<p>
Soyons sérieux un instant.
Je renvois chacun aux premiers chapitres de www.oreilly.com/catalog/pgp/
( Je renvois même au chapitre 3 (cryptographie d'avant PGP) et 5 (politique américaine et vie privée))
<p>
Pensez vous *vraiment* que la NSA va aider en quoi que ce soit à développer quoi que ce soit qui aille contre les interêts qui l'ont créé ?
===================== Fin de citation
La NSA a une sacrée longueur d'avance. Moi, je pense que j'en ai beaucoup de retard à ne pas m'y être mis il y a 5 ans (à PGP).
Je pense révoquer mes clés pour en augmenter la taille.
--
GNU rulez
[^] # Re: NSA nous mène par le bout du nez
Posté par Gaétan RYCKEBOER . Évalué à 1.
Donc, tous sont potentiellement des "espions".
C'est james bond, mais sans flingouze ni Demi moore.
Le problème étant de savoir faire la part des choses entre oui, on fait confiance, et non, on est complêtement parano.
Pour une utilisation qutidienne, j'en ai rien à taper que la NSA vienne coller son nez dans mes slips. Si elle veut sentir cu'il y a, libre à elle.
[Imagine la tête des keufs qui mettent la soeur de Daria sur écoute. Ils doivent pas rigoler tous les jours.]
Dans la mesure où tu ne manipule pas de données top secret défense, ben.. m'en fout. Ce que je ne veut pas, c'est que le type du coin de la rue viennet sniffer mes passwords, ou que le concurent du coin connaisse la politique de la boite. Le reste... je me sens pas trop anarchiste provocateur à la Polac.
[^] # Re: NSA nous mène par le bout du nez
Posté par vjm . Évalué à 5.
Certes la NSA est le premier employeur de mathématiciens au monde, certes son budget est plus important que je-ne-sais-plus-quel ministère. Mais par exemple dans le cas des patches SE Linux, les extensions concernent essentiellement les mises en place de politiques de sécurité dont le code est compréhensible. Le développement est assuré par la NSA mais aussi par MITRE Corp. et NAI Labs. La première a participé à la rédaction d'un draft sur le full disclosure pour l'ietf, tandis que la seconde a participé au developpement de LOMAC et maintenant de TrustedBSD (au travers du projet CBOSS soutenu par le darpa). Ces sociétés ne sont pas tenu je pense au secret defense.
Ensuite, si la NSA avait tant d'avance, je pense que d'en un pays empreint de l'éthique protestante, il aurait tôt fait d'en tirer parti économiquement. Je pense aussi que comme dans tout pays, les différentes bureaucraties s'affrontent en exploitant les petits écarts/secrets de l'autre. Je pense aussi que sur un nombre aussi important d'employés dont plusieurs génies, si qqch dérape ça finira par sortir.
Je ne pense pas que même la NSA ait des siècles d'avance sur le reste du monde. Je me souviens d'avoir lu l'histoire des chercheurs de GCHQ britannique qui avait découvert la cryptographie à clé publique : c'était seulement quelques années avant les publications de Diffie-Hellman-Merkle puis Rivest-Shamir-Adleman. Pour se donner une idée de l'avancement qu'on pu avoir (et doivent tjrs avoir) les agences de renseignement, le royaume uni libère chaque année des documents classés secret defense. Aux USA, il existe le Freedom of Information Act (FOIA) qui permet de consulter de nombreux documents passée une certaine période de temps.
Bref, même si certainement, comme c'est leur boulot, les agences de renseignement espionnent ; je pense qu'il y aura suffisamment de garde fous ou contre pouvoir (comme l'open source). En même temps, je peux être naïf :)
http://www.nsa.gov/selinux/contrib.html(...)
http://opensource.nailabs.com/initiatives/cboss/(...)
http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-dis(...)
http://www.aclu.org/library/foia.html(...)
http://www.ddj.com/documents/s=909/ddj9875b/9875b.htm(...)
# Clef inviolable...
Posté par babar33 . Évalué à -2.
XOR et utiliser une clef (prise au hasard) aussi longue que ce que l'on crypte !
(et surtout ne jamais utiliser 2 fois la meme clef)
et la, c'est foutou, c'est impossible à casser.
(on peut faire correspondre n'importe quoi)
[^] # Re: Clef inviolable...
Posté par Le Pnume . Évalué à 0.
t'envoie, un mail crypter avec gpg ? ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.