vendredi 15 janvier 2010

moar gmail security


Voilà une excellente nouvelle, gmail qui utilise du https par défaut pour l'ensemble de la session (et pas seulement pour l'authentification). Pour rappel, c'était en phase de test ces quelques derniers mois (afin d'évaluer la charge que cela pourrait engendrer).

vendredi 8 janvier 2010

Factorisation d'une clé RSA de 768 bits

Voilà ça a été fait, même si ça leur a pris pas mal de temps (en travail préparatoire, lire l'article pour des détails plus précis, je serais capable d'en altérer le sens)

The following effort was involved. We spent half a year on 80 processors on polynomial selection. This was about 3% of the main task, the sieving, which was done on many hundreds of machines and took almost two years.
Quand ils parlent de "many hundreds of machines", c'est un immense cluster réparti sur plusieurs pays. Mais là encore, la lecture du pdf est probablement plus intéressante. A noter également cette petite info:

On a single core 2.2 GHz AMD Opteron processor with 2 GB RAM per core, sieving would have taken about fifteen hundred years.
Ainsi que:

Preparing the sieving data for the matrix step took a couple of weeks on a fewprocessors, the final step after the matrix step took less than half a day of computing, but took about four days of intensive labor because a few bugs had to be fixed.
Je ne vais pas parler des détails mathématiques concernant cette belle performance, je ne suis pas très orienté maths :) Par contre, on peut toujours s'intéresser à l'impact que cela peut avoir sur la sécurité-informatique-de-l'internet-mondial (ah non, c'est vrai que l'idée de nationaliser "l'Internet" a été émise [1]).

Premier exemple qui me vient à l'esprit, le fait que nos cartes bancaires utilisent une taille de clé RSA de 768 bits (elles étaient à 320 bits avant l'affaire Humpich). Même si factoriser un nombre de cette taille a pris un peu de temps avec quelques milliers de machines, on pourrait se demander si ça ne sera pas faisable avec un botnet un de ces jours, par des gens pas spécialement bien intentionnés (bon en meme temps, y'a d'autres moyens d'abuser des cartes bancaires, comme les cloneurs de cartes qu'on trouve parfois sur des ATM).

Ensuite, bien sûr, l'utilisation de RSA en cryptographie dans la vie de presque-tous-les-jours (comme PGP [hein ? vous ne chiffrez pas vos mails ?!]). Un document trouvé sur le site de l'ANSSI nous conseille ces tailles de clé:

RègleFact-1. La taille minimale du module est de 1536 bits, pour une utilisation
ne devant pas dépasser l’année 2010.
RègleFact-2. La taille minimale du module est de 2048 bits, pour une utilisation
ne devant pas dépasser l’année 2020.
RègleFact-3. Pour une utilisation au-delà de 2020, la taille minimale du module
est de 4096 bits.
RègleFact-4. Les exposants secrets doivent être de même taille que le module.
RègleFact-5. Pour les applications de chiffrement, les exposants publics doivent
être strictement supérieurs à 216=65536.
RecomFact-1. Il est recommandé d’employer des modules d’au moins 2048 bits,
même pour une utilisation ne devant pas dépasser 2010.
RecomFact-2. Il est recommandé, pour toute application, d’employer des exposants publics strictement supérieurs à 216=65536.
RecomFact-3. Il est recommandé que les deux nombres premiers p et q constitutifs du module soient de même taille et générés aléatoirement.
En gros, 1536 bits est le minimum à utiliser actuellement, mais 2048 bits sont recommandés. Ensuite, l'utilisation de la crypto ne doit pas être vue comme un moyen ultime d'empêcher quelqu'un de consulter des documents qu'il ne devrait pas consulter de manière perpétuelle, mais plutôt de le ralentir dans cette démarche. Tout dépend donc de la période pendant laquelle on souhaite rendre le document inaccessible.

On note au dessous une explication quant à la raison du non-choix d'une taille de clé RSA de 1024 bits, qui, bien que non encore factorisé, reste sujet à controverse et est donc un mauvais choix si l'on souhaite maintenir un niveau de sécurité conséquent. D'ailleurs, il va être temps que je passe ma clé PGP perso à une taille de clé supérieure, au détriment des performances de mon téléphone (openpgp sur mon téléphone prend de longues secondes pour déchiffrer un mail chiffré avec une clé de 1024 bits: j'imagine à peine le résultat avec 2048. Le pire restant 4096, car là, l'OS du téléphone tue le thread de déchiffrement)

Une alternative intéressante: les courbes elliptiques, qui demandent une taille de clé moindre, pour une sécurité équivalente.

Il ne me reste plus qu'à vous souhaiter, en retard, une bonne année.

[1] Idée évoquée par un député Français, pour faire comme en Chine afin de se protéger d'une hypothétique menace étrangère qui n'existe probablement pas. Quand on commence à prendre en exemple la Chine, je pense que là y'a du danger et personne ne peut nous sauver)