Les générateurs de nombres pseudo-aléatoires

[Yarflam]

Bonjour à tous !
J'ai une question qui me tourmente l'esprit quand je lis un article de cryptographie.
Du genre :
" Nous avons au final assez peu de paramètres pour une génération aléatoire sérieuse des clés privées RSA, on en déduit que la séquence de prédiction de génération de ces clés est cassable "

En quoi une liste pseudo-aléatoire peut-elle affecter la sécurité d'un chiffrement ?
Je ne comprends pas. Si j'utilise la fonction random() de l'ordinateur et que je chiffre un message en RSA serriez-vous capable de deviner la clef privé ?
Si oui, j'aimerai bien apprendre

Merci d'avance.

[SAKAROV]

Oui, fallait quote tout le paragraphe

"Le fichier javascript décrivant le mécanisme cryptographique est d’ailleurs assez effrayant. Nous avons au final assez peu de paramètres pour une génération aléatoire sérieuse des clés privées RSA, on en déduit que la séquence de prédiction de génération de ces clés est cassable"

En fait, mega utilise un code JS qui suit les mouvements de la souris pour générer des clés privées RSA. En gros, ce que mentionne l'auteur c'est que c'est juste un "gadget" (il a pas tort) non seulement inutile mais surtout dangereux (peu secure), car le caractère aléatoire de la génération n'est plus aussi aléatoire qu'à l'accoutumée. En effet, puisque ça prend des mouvements de souris, la probabilité pour que deux utilisateurs génèrent la même clé est beaucoup plus élevée que la génération strictement aléatoire.

Note : je n'ai pas regardé le .js (servant à capter les mouvements du curseur pour générer les clés privées) et ce que je dis est une explication "à la hâte" de ce que dis l'auteur. Ne prend pas ce que je dis pour argent comptant. Mais je pense que je ne me trompe pas, cela dit.

PS: pour juger de la véracité des propos de l'auteur : analyse le JS. Ils le fournissent.

[yacx21]

Bonjour à tous.
Je déterre un peu le poste mais je passais dans le coin et je me suis dit pourquoi pas.

Concernant génération de nombre aléatoires, c'est par définition impossible et c'est pour cela qu'on parle de nombres pseudo-aléatoire.
Les mouvements de la souris ce n'est pas si débile tout dépend de comment cela influe sur la gestion de ce nombre pseudo-aléatoire.

Par exemple si le paramètre entrant en compte est la position moyenne du curseur c'est clairement débile. Mais si il s'agit d'une position précise sur l'écran a un instant précis (imaginons 10 secondes avant que l'utilisateur ne valide sa clé par exemple), alors les possibilités sont bien plus élevées.
Ensuite il faut aussi réussir a déterminer l'ensemble de lois définissant la génération de la clef une fois la "position" de la souris déterminée.

Toujours est-il que le sujet de la génération de nombre aléatoire est très relayé (que ce soit en informatique, en mathématiques ou dans les disciplines comme les stats maths).
Je me rappelle que des mecs avaient créés un algo en se basant sur les "bruits du silence", oui oui c'est possible.

Le défaut majeur du système c'est que ca ne repose QUE sur un paramètre.

Pour en revenir à ta question le fait que le chiffrement repose sur la génération d'un nombre aléatoire n'est pas le problème (car c'est impossible de faire sans, à moins de faire du purement déterministe mais là ca repose sur des modèles maths bien trop poussés, pour moi en tout cas), il n'y a juste pas assez de paramètres qui entrent en jeu?

Sinon la fonction random de ton ordi sans un soft potable oui elle sera très très très très facile à trouver, il faudra faire quelques tentatives mais le système de calcul utilisé est plus que basique.
SI tu utilises de bon algorythme de génération de nombres pseudo aléatoires là ce sera beaucoup plus compliqué (avec quelques recherches tu dois pouvoir trouver des détails sur lesquels sont ou ne sont pas fiables).

Bonne soirée à tous

[TorTukiTu]

Ensuite il faut aussi réussir a déterminer l'ensemble de lois définissant la génération de la clef une fois la "position" de la souris déterminée.

C'est d'ailleurs comme ca que fonctionne /dev/random sur les distributions GNU/Linux.

Il existe une fonctionnalité du noyau qui consiste en la collecte du bruit sur les différents périphériques matériel. Ca va de la souris aux paquets recus par la carte réseau. L'ensemble forme ce que l'on appelle l'entropie du système.

Par exemple, petit cat /proc/sys/kernel/random/entropy_avail vous affichera la taille du pool entropique du noyau.

Pour ce qui est de la fonction random ATTENTION:
L'implémentation de base de random sur tous les GNU/Linux (glibc) ne conviens pas à toutes les applications. Le générateur a une période très faible. ie. Il redonne rapidement les mêmes suites de nombres.

(On mesure la qualité d'un générateur de nombres peuso aléatoires entre autre à sa période. Plus elle est grande, plus le générateur est bon. Un générateur de nombres réellement aléatoires n'ayant pas de période.)

Si vous l'utilisez dans des simulations ou dans de la crypto, vous allez voir apparaître des artefacts qui sont dus à la faible périodicité du générateur, et donc induire des vulnérabilités dans le cas de la crypto.

Donc, pour ta question,

Si j'utilise la fonction random() de l'ordinateur et que je chiffre un message en RSA serriez-vous capable de deviner la clef privé ?

Si j'obtiens suffisament de données pseudo-aléatoires depuis random(), étant donné que c'est toujours la même suite de nombres qui finira par être générée par période, alors oui.

Si vous voulez des générateurs corrects, allez voir du côté de la GSL (Gnu Scientific Library).

Le chiffrement est un domaine très particulier. On n'implémente pas comme ca des algorithmes de chiffrement. Il y a une très grande quantité de choses à savoir pour éviter un maximum de biais possibles.

Conclusion: Toujours utiliser des implémentations connues comme robustes et ne jamais réecrire soi même son implémentation.

Tortue 974.

[Yarflam]

Merci à tout les deux.

Conclusion: Toujours utiliser des implémentations connues comme robustes et ne jamais réecrire soi même son implémentation.

Là dessus, je ne suis pas d'accord avec toi.
Les dernières déclarations de Snowden sur l'implantation d'une backdoor par la NSA dans le système de chiffrement Dual_EC_DRGB démontre un point crucial de la technologie : celle ne jamais faire confiance à un algorithme si on en connait pas ses rouages. Et c'est d'ailleurs très curieux de ta part d'exprimer cette avis alors que tu ne supportes par le Javascript - un langage hautement utilisé et de plus en plus d'actualité avec le HTML 5, le Jquery et le Processing - bref l'avenir du web et tu as peur de l'utiliser.

A ça je rajoute qu'un algorithme propriétaire requière une autorisation de la part du fabriquant ou du programmeur. Et toute modification ou dérivation du produit est exclu par la licence ou le brevet. Si on souhaite développer une copie de ce système on doit demander l'autorisation et payer. Sans compter qu'on est en plus dépendant du propriétaire.

Pour le reste je suis d'accord avec vous. Et je garde en mémoire des petits détails intéressent pour mes prochains développement en sécurité.

[TorTukiTu]

Oula, attention, je n'ai jamais parlé de propriétaire.

Le fermé est bien entendu à fuir comme de la peste, et ce dans tous les cas.

Ne pas réaliser une implémentation de veux pas dire ne rien piger à l'algo. Idéalement, c'est à l'utilisateur final de vérifier d'une facon satellitaire si l'implémentation est correcte.
Le chiffrement, c'est vraiment un métier à part entière. Si un néophyte essaye de se faire un implémentation maîson, il va se gauffrer avec une probabilité de 100%.

Donc, oui, je persiste et je signe. Faites confiance aux gens des grands projets de crypto libre plutot que de tout recommencer from scratch.
La probabilité d'utiliser des implémentations vulnérable est bien plus faible en utlisant des implémentations reconnues que des implémentations maîson.

Tortue 974.