rand

fr::crypto::rand(3SSL)               OpenSSL              fr::crypto::rand(3SSL)



NOM
       rand - Générateur de nombres pseudoaléatoires

SYNOPSIS
        #include <openssl/rand.h>

        int  RAND_set_rand_engine(ENGINE *engine);

        int  RAND_bytes(unsigned char *buf, int num);
        int  RAND_pseudo_bytes(unsigned char *buf, int num);

        void RAND_seed(const void *buf, int num);
        void RAND_add(const void *buf, int num, int entropy);
        int  RAND_status(void);

        int  RAND_load_file(const char *file, long max_bytes);
        int  RAND_write_file(const char *file);
        const char *RAND_file_name(char *file, size_t num);

        int  RAND_egd(const char *path);

        void RAND_set_rand_method(const RAND_METHOD *meth);
        const RAND_METHOD *RAND_get_rand_method(void);
        RAND_METHOD *RAND_SSLeay(void);

        void RAND_cleanup(void);

        /* Seulement pour Win32 */
        void RAND_screen(void);
        int RAND_event(UINT, WPARAM, LPARAM);

DESCRIPTION
       Depuis l’introduction de l’interface de programmation d'ENGINE, la
       manière recommandée de contrôler les implémentations par défaut est
       d’utiliser les fonctions d’interface de programmation d'ENGINE. La
       RAND_METHOD par défaut, telle que définie par RAND_set_rand_method() et
       renvoyée par RAND_get_rand_method(), n’est utilisée que si ENGINE a été
       défini comme implémentation « rand » par défaut. Par conséquent, ces deux
       fonctions ne sont plus recommandées pour contrôler les valeurs par
       défaut.

       Si une implémentation RAND_METHOD alternative est en cours d’utilisation
       (soit définie directement, soit fournie par un module d’ENGINE), alors
       elle est entièrement responsable de la génération et de la gestion d’un
       flux de génération de nombres pseudoaléatoires cryptographiquement sûr.
       Les mécanismes décrits ci-dessous ne reposent que sur l’implémentation de
       génération de nombres pseudoaléatoires intégrée à OpenSSL et utilisée par
       défaut.

       Ces fonctions implémentent un générateur de nombres pseudoaléatoires
       cryptographiquement sûr. Il est utilisé par d’autres fonctions de
       bibliothèques, par exemple pour générer des clefs aléatoires, et les
       applications peuvent l’utiliser quand elles ont besoin de hasard.

       Un générateur de nombres pseudoaléatoires cryptographique doit être
       initialisé avec des données non prévisibles comme des mouvements de
       souris ou des frappes aléatoires de touches par l’utilisateur. C’est
       décrit dans RAND_add(3). Son état peut être enregistré dans un fichier
       d’initialisation (consultez RAND_load_file(3)) pour éviter de recommencer
       le processus d’initialisation à chaque fois que l’application est
       démarrée.

       RAND_bytes(3) décrit comment obtenir des données aléatoires du générateur
       de nombres pseudoaléatoires.

FONCTIONNEMENT INTERNE
       La méthode RAND_SSLeay() implémente un générateur de nombres
       pseudoaléatoires basé sur une fonction de hachage cryptographique.

       La description suivante de sa conception est basée sur la documentation
       de SSLeay :

       Pour commencer, une déclaration des choses considérées nécessaires pour
       un bon générateur de nombres aléatoires.

       1.  Un bon algorithme de hachage pour mélanger les choses et convertir
           l’« état » du générateur en nombres aléatoires.

       2.  Une source de départ d’« état » de hasard.

       3.  L’état devrait être très grand. Si le générateur de nombres
           aléatoires est utilisé pour générer une clef RSA de 4096 bits, (au
           moins) deux chaînes aléatoires de 2048 bits sont nécessaires. Si
           l’état du générateur de nombres aléatoires n’a que 128 bits, l’espace
           de recherche est évidemment limité à 128 bits et non 2048. Ce dernier
           point est probablement exagéré, mais cela indique vraiment que garder
           beaucoup d’état du générateur de nombres aléatoires ne serait pas une
           mauvaise idée. Ce devrait être plus facile de casser un algorithme de
           chiffrement que de deviner les données d’initialisation du générateur
           de nombres aléatoires.

       4.  Toutes les données d’initialisation du générateur de nombres
           aléatoires devraient influencer tous les nombres aléatoires suivants
           générés. Cela implique que toutes les données aléatoires
           d’initialisation auront une influence sur tous les nombres aléatoires
           suivants générés.

       5.  Lors de l’utilisation des données pour initialiser l’état du
           générateur de nombres aléatoires, les données utilisées ne devraient
           pas pouvoir être extraites de l’état du générateur de nombres
           aléatoires. Ce devrait être impossible car une éventuelle source de
           données semi-aléatoires « secrètes » pourrait être une clef privée ou
           un mot de passe. Ces données ne doivent être dévoilées ni par un des
           nombres aléatoires suivants, ni par un déversement de la mémoire
           laissé par un plantage de programme.

       6.  À partir du même « état » initial, deux systèmes devraient dévier
           dans leur état du générateur de nombres aléatoires (et donc dans les
           nombres aléatoires générés) si possible.

       7.  À partir d’un flux de sortie de nombres aléatoires, il devrait être
           impossible de déterminer l’état du générateur de nombres aléatoires
           ou le nombre aléatoire suivant.

       L’algorithme est défini comme suit.

       Un état global constitué d’un tampon de 1023 octets (l’« état »), une
       valeur de hachage fonctionnelle (« md ») et un compteur (« compte »).

       À chaque fois que des données d’initialisation sont ajoutées, elles sont
       insérées dans l’« état » comme suit.

       L’entrée est découpée en morceaux de 20 octets (ou moins pour le dernier
       bloc). Chacun de ces blocs est passé dans la fonction de hachage comme
       suit : les données passées dans la fonction de hachage deviennent la
       « md » actuelle, le même nombre d’octets de l’« état » (la position est
       déterminée en bouclage incrémenté d’indice) en tant que « bloc » actuel,
       le nouveau « bloc » de données de clefs et « compte » (qui est augmenté
       après chaque utilisation). Ce résultat est gardé dans « md » et aussi
       ajouté à l’« état » à l’aide d’un XOR à l’endroit qui a été utilisé en
       entrée dans la fonction de hachage. Ce système devrait répondre aux
       points 1 (fonction de hachage, SHA-1 pour le moment), 3 (l’« état »), 4
       (par l’intermédiaire du « md ») et 5 (en utilisant une fonction de
       hachage et XOR).

       Lorsque des octets sont extraits du générateur de nombres aléatoires, le
       processus suivant est utilisé. Pour chaque groupe de 10 octets (ou
       moins), voici ce qui est fait.

       Entrer dans la fonction de hachage la « md » locale (qui est initialisée
       à partir de la « md » globale avant que des octets ne soient générés),
       les octets qui sont à écraser par les octets aléatoires et les octets de
       l’« état » (bouclage incrémenté d’indice). À partir de cette sortie
       hachée (qui est gardée dans « md »), les 10 premiers octets (au maximum)
       sont renvoyés à l’appelant et les 10 derniers octets sont ajoutés à
       l’« état » à l’aide d’un XOR.

       Enfin, après avoir fini « num » octets aléatoires de l’appelant,
       « compte » (qui est augmenté) et les « md » locale et globale sont
       introduits dans la fonction de hachage, et les résultats sont gardés dans
       la « md » globale.

       Ce qui précède devrait répondre aux points 1 (utilisation de SHA-1), 6
       (en hachant dans l’« état » les « anciennes » données de l’appelant qui
       vont être écrasées) et 7 (en n’utilisant pas les 10 octets donnés à
       l’appelant pour mettre à jour l’« état », mais ils sont utilisés pour
       mettre à jour « md »).

       Ainsi, de tous les points soulevés, seul 2 n’est pas traité (mais
       consultez RAND_add(3)).

VOIR AUSSI
       BN_rand(3), RAND_add(3), RAND_load_file(3), RAND_egd(3), RAND_bytes(3),
       RAND_set_rand_method(3), RAND_cleanup(3)

TRADUCTION
       La traduction de cette page de manuel est maintenue par les membres de la
       liste <debian-l10n-french AT lists DOT debian DOT org>.  Veuillez
       signaler toute erreur de traduction par un rapport de bogue sur le paquet
       manpages-fr-extra.



1.0.2a 1.0.2c                      2015-12-31             fr::crypto::rand(3SSL)