Utilisation de RNDADDENTROPY pour ajouter de l'entropie à /dev/random

Question

J'ai un périphérique qui génère du bruit que je veux ajouter au pool d'entropie pour le périphérique /dev/random dans un système Linux embarqué.

Je suis en train de lire le page de manuel sur /dev/random et je ne comprends pas vraiment la structure que vous passez dans l'appel ioctl RNDADDENTROPY.

   RNDADDENTROPY
          Add some additional entropy to the input pool, incrementing
          the entropy count.  This differs from writing to /dev/random
          or /dev/urandom, which only adds some data but does not
          increment the entropy count.  The following structure is used:

              struct rand_pool_info {
                  int    entropy_count;
                  int    buf_size;
                  __u32  buf[0];
              };

          Here entropy_count is the value added to (or subtracted from)
          the entropy count, and buf is the buffer of size buf_size
          which gets added to the entropy pool.

Est entropy_count dans cette structure le nombre de bits que j'ajoute ? Pourquoi cela ne serait-il pas toujours buf_size * 8 (en supposant que buf_size est en termes d'octets) ?

De plus, pourquoi buf un tableau de taille nulle ? Comment suis-je censé lui attribuer une valeur ?

Merci pour toute aide !

Answer 1

J'utilise un RNG matériel pour stocker mon pool d'entropie. Ma structure a une taille statique et ressemble à ceci (mon noyau a un random.h légèrement différent ; copiez simplement ce que vous copiez ce que vous trouvez dans le vôtre et augmentez la taille du tableau à votre guise) :

#define BUFSIZE 256
/* WARNING - this struct must match random.h's struct rand_pool_info */
typedef struct {
    int bit_count;               /* number of bits of entropy in data */
    int byte_count;              /* number of bytes of data in array */
    unsigned char buf[BUFSIZ];
} entropy_t;

Tout ce que vous passez dans buf sera haché et remuera le bassin d'entropie. Si vous utilisez /dev/urandom, peu importe ce que vous passez pour bit_count car /dev/urandom ignore le fait qu'il soit égal à zéro et continue.

Ce que fait le bit_count c'est de pousser le point auquel /dev/random va bloquer et attendre que quelque chose vienne ajouter de l'entropie à partir d'une source RNG physique. Ainsi, il est correct d'estimer le nombre de bits. Si vous estimez qu'il est faible, le pire pire qui puisse arriver est que /dev/random se bloque plus tôt qu'il ne le ferait qu'il ne l'aurait fait. Si vous devinez haut, /dev/random fonctionnera comme /dev/urandom pendant un peu plus longtemps qu'il ne l'aurait fait avant de se bloquer.

Vous pouvez faire une estimation en vous basant sur la "qualité" de votre source d'entropie. Si elle est faible, comme des caractères tapés par des humains, vous pouvez la fixer à 1 ou 2 par octet. Si elle est élevée, comme des valeurs lues à partir d'un RNG matériel dédié, vous pouvez le définir à 8 bits par octet.

Answer 2

Si vos données sont parfaitement aléatoires, alors je pense qu'il serait approprié de entropy_count pour être le nombre de bits dans le tampon que vous fournissez. Cependant, la plupart des sources d'aléatoire ne sont pas parfaites, et il est donc logique que la taille du tampon et la quantité d'entropie soient des paramètres séparés.

buf qui est déclaré de taille zéro est un idiome standard du C. Le problème est que lorsque vous allouez réellement un fichier rand_pool_info vous le faites malloc(sizeof(rand_pool_info) + size_of_desired_buf) puis vous faites référence à la mémoire tampon en utilisant la balise buf membre. Note : Avec un peu de Dans les compilateurs C, vous pouvez déclarer buf[*] au lieu de buf[0] pour être explicite sur le fait qu'en réalité buf est "extensible".

Answer 3

Le nombre d'octets que vous avez dans le tampon est en corrélation avec l'entropie des données, mais l'entropie ne peut pas être calculée uniquement à partir de ces données ou de leur longueur.

Bien sûr, si les données proviennent d'un bon générateur de bruit aléatoire matériel, imprévisible et distribué de manière égale, l'entropie (en bits) est de 8*taille du tampon (en octets).

Mais si les bits ne sont pas répartis de manière égale ou s'ils sont prévisibles d'une manière ou d'une autre, l'entropie diminue.

Voir https://en.wikipedia.org/wiki/Entropy_(théorie de l'information)

J'espère que cela vous aidera.