générateur de nombre aléatoire

Published: 31-01-2016

Updated: 22-05-2016

By: Maxime de Roucy

tags: haveged random rngd

Sources :

Quelques notes sur /dev/random et /dev/urandom.

Ces deux pseudo-fichier sont des sources binaire aléatoire. Il sont alimenté par le noyau qui utilise les intéruptions matérielle (IRQ) comme source.

/dev/random est bloquant, c’est à dire que si le noyau ne dispose pas d’assez d’IRQ il bloque flux binaire de /dev/random. Le programme qui cherche à utiliser ce flux doit donc attendre que d’autres IRQ permette au noyau d’alimenter le pseudo-fichier.

/dev/urandom n’est pas bloquant, c’est à dire que s’il n’y a pas assez d’IRQ le noyau se débrouille avec ce qu’il a pour alimenter quand même le fichier. Aucun programme n’est bloqué en attente du flux. Mais la qualité du flux binaire aléatoire est grandement diminué… c’est plus vraiment aléatoire.

Pour les service relatif à la sécurité (e.g. génération de clé secrète) il est important d’utiliser une source vraiment aléatoire. /dev/random est donc utilisé.

Je dispose d’un serveur sans carte graphique, sans carte son, dont les seuls cables branché sont l’alimentation et un RJ45. De plus il y n’a pas beaucoup d’activité au niveau du disque dure… Autant dire qu’il n’y a pas beaucoup d’IRQ et que les programme peuvent resté bloqué très longtemps en attente de /dev/random.

J’ai notamment eu le cas de kadmind qui mettait une dizaine de minutes à démarrer. Sans erreur dans les logs, j’ai du sortir strace pour m’apercevoir qu’il n’était pas planté mais qu’il attenté /dev/random.

Il est possible d’ajouté des sources d’entropy (d’aléatoire) à /dev/random.

Certain ordinateur possède des sources d’entropy matériel. Ça peut être du matériel dédié ou intégré dans le CPU.

Pour savoir si on dispose d’une tel source :

root@server # rngd -v
Unable to open file: /dev/tpm0
Available entropy sources:
        DRNG

Malheureusement pour moi, je n’en ai pas :

root@server # rngd -v
Unable to open file: /dev/tpm0
can't open any entropy source
Maybe RNG device modules are not loaded

Sur le net on trouve des tuto conseillant d’utilisé /dev/urandom comme source d’entropie pour /dev/random… Si vous avez lue ce qu’il y a au dessus vous comprendrez que ça fonctionne mais ce n’est pas une bonne solution.

Heureusement il existe haveged qui ne necessite pas de matériel spécifique. Il se base sur le fait que sur un ordinateur, un même programe lancé deux fois ne prendra jamais exactement le même temps.

root@server # emerge -av haveged
…
root@server # systemctl start haveged
root@server # systemctl enable haveged

Certain pense que la qualité de cette source n’est pas très bonne. rngtest permet de tester la qualité d’un flux binaire aléatoire :

root@server # cat /dev/random| rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 1000
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=398.743; avg=4596.865; max=54253.472)Kibits/s
rngtest: FIPS tests speed: (min=2.225; avg=31.872; max=40.410)Mibits/s
rngtest: Program run time: 4850071 microseconds

Avoir quelques « failures » est acceptable… là j’en ai aucune.

rngtest: FIPS 140-2 successes: 1000
rngtest: FIPS 140-2 failures: 0

J’ai fait le test plusieurs fois, le moin bon score était 3 « failures » et je ne l’ai vu qu’une fois. Bref, je considère que haveged est une bonne source d’entropie.

Maintenant, kadmind ne met plus que quelques secondes à démarrer.