random – aperçu d’interfaces pour obtenir un
caractère aléatoire
Le générateur de nombres aléatoires du noyau repose sur
l’entropie recueillie à partir de pilotes de
périphérique et d’autres sources de bruit environnemental
pour ensemencer un générateur de nombres
pseudo-aléatoires (CSPRNG) sûr du point de vue cryptographie. Il
est conçu pour la sécurité plutôt que pour la
rapidité.
Les interfaces suivantes fournissent un accès pour obtenir un
résultat d’un générateur de nombres
pseudo-aléatoires du noyau :
- •
- Les périphériques /dev/urandom et
/dev/random, tous deux décrits dans random(4). Ces
périphériques sont présents dans Linux depuis les
premiers temps et sont aussi disponibles dans beaucoup d’autres
systèmes.
- •
- L’appel système getrandom(2)
spécifique à Linux, disponible depuis Linux 3.17. Cet
appel système fournit un accès soit à la même
source que /dev/urandom (appelée la source urandom
dans cette page) ou à la même source que /dev/random
(appelée la source random dans cette page). Celle par
défaut est la source urandom. La source random est
sélectionnée avec l’indicateur GRND_RANDOM
dans l’appel système. La fonction getentropy(3) avec
getrandom(2) fournit une interface légèrement plus
portable.
Le noyau collecte les bits d’entropie à partir de
l’environnement. Lorsque un nombre suffisant de bits a
été collecté, la réserve d’entropie est
considérée comme initialisée.
À moins de vouloir générer une clef pérenne (et
très vraisemblablement même pas dans ce cas), la lecture ne sera
probablement pas faite à partir du périphérique
/dev/random ou en employant
getrandom(2) avec
l’indicateur
GRND_RANDOM. À la place, la lecture sera
faite soit à partir du périphérique
/dev/urandom
ou en utilisant
getrandom(2) sans l’indicateur
GRND_RANDOM. Les cryptosystèmes pour la source
urandom
sont plutôt conservatifs et par conséquent devraient être
suffisants pour toutes les utilisations.
L’inconvénient de
GRND_RANDOM et des lectures à
partir de
/dev/random est que l’opération peut bloquer
pendant une période indéfinie. De plus, gérer des
requêtes partiellement remplies pouvant se produire lors de
l’utilisation de
GRND_RANDOM ou de la lecture à partir de
/dev/random augmente la complexité du code.
L’utilisation de ces interfaces pour fournir de grandes quantités
de données pour les simulations de Monte-Carlo et d’autres
programmes ou algorithmes réalisant un échantillonnage
probabiliste, sera peu rapide. De plus, c’est inutile parce que de
telles applications n’ont pas besoin de nombres aléatoires
sûrs du point de vue chiffrement. À la place, les interfaces
décrites dans cette page sont à utiliser pour obtenir une petite
quantité de données pour ensemencer un générateur
de nombres pseudo-aléatoires pour ce type d’applications.
Le tableau suivant résume le comportement des diverses interfaces qui
peuvent être utilisées pour obtenir un caractère
aléatoire.
GRND_NONBLOCK est un indicateur qui peut être
utilisé pour contrôler le comportement bloquant de
getrandom(2). La dernière colonne du tableau tient compte du cas
pouvant se produire au tout début du démarrage quand la
réserve d’entropie n’est pas encore initialisée.
| Interface |
Réserve |
Comportement de blocage |
Comportement si réserve pas encore prête |
| /dev/random |
Réserve bloquante |
Si entropie trop faible, blocage jusqu’à assez
d’entropie |
Blocage jusqu’à suffisamment d’entropie
accumulée |
| /dev/urandom |
Sortie CSPRNG |
Aucun blocage |
CSPRNG non initialisé (entropie faible et inadaptée au
chiffrement ?) |
|
getrandom() |
Identique à /dev/urandom
|
Aucun blocage si réserve prête |
Blocage jusqu’à réserve prête |
|
getrandom() GRND_RANDOM
|
Identique à /dev/random
|
Si entropie trop faible, blocage jusqu’à assez
d’entropie |
Blocage jusqu’à réserve prête |
|
getrandom() GRND_NONBLOCK
|
Identique à /dev/urandom
|
Aucun blocage si réserve prête |
EAGAIN |
|
getrandom() GRND_RANDOM + GRND_NONBLOCK
|
Identique à /dev/random
|
EAGAIN si manque d’entropie disponible |
EAGAIN |
The amount of seed material required to generate a cryptographic key equals the
effective key size of the key. For example, a 3072-bit RSA or Diffie-Hellman
private key has an effective key size of 128 bits (it requires about 2^128
operations to break) so a key generator needs only 128 bits (16 bytes) of seed
material from
/dev/random.
Bien qu’une marge de sécurité au-dessus de ce minimum soit
raisonnable comme protection contre des défauts d’algorithme de
CSPRNG, aucune primitive cryptographique disponible actuellement ne peut
espérer promettre plus de 256 bits de sécurité,
aussi, si un programme lit plus de 256 bits (32 octets) de la
réserve de caractère aléatoire du noyau par invocation,
ou par intervalle raisonnable de réensemencement (pas moins
d’une minute), cela doit être pris comme un signe que son
chiffrement n’a
pas été implémenté
savamment.
getrandom(2),
getauxval(3),
getentropy(3),
random(4),
urandom(4),
signal(7)
La traduction française de cette page de manuel a été
créée par Christophe Blaess
<
https://www.blaess.fr/christophe/>, Stéphan Rafin
<
[email protected]>, Thierry Vignaud
<
[email protected]>, François Micaux, Alain Portal
<
[email protected]>, Jean-Philippe Guérard
<
[email protected]>, Jean-Luc Coulon (f5ibh)
<
[email protected]>, Julien Cristau
<
[email protected]>, Thomas Huriaux <
[email protected]>,
Nicolas François <
[email protected]>, Florentin
Duneau <
[email protected]>, Simon Paillard
<
[email protected]>, Denis Barbier
<
[email protected]>, David Prévot <
[email protected]> et
Jean-Paul Guillonneau <
[email protected]>
Cette traduction est une documentation libre ; veuillez vous reporter
à la
GNU
General Public License version 3 concernant les conditions de copie
et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message à
[email protected]