Concisement, je ne crois pas que cela affecte la force de votre cryptage.
J'ai vérifié le code source et tant que j'interprète correctement ce que j'ai lu, vous n'avez pas nécessairement à vous en soucier.
Ce code appartient au module 'stdrng'. Au moins sur Fedora 23, cela est intégré au noyau plutôt qu'exporté en tant que module du noyau.
Lorsque stdrng est initialisé pour la première fois, les appels suivants se produisent.
Dans crypto/drbg.c, l'initialisation commence ici.
1997 module_init(drbg_init);
Ceci enregistre tous les drbgs connus du système.
1985 for (j = 0; ARRAY_SIZE(drbg_cores) > j; j++, i++)
1986 drbg_fill_array(&drbg_algs[i], &drbg_cores[j], 1);
1987 for (j = 0; ARRAY_SIZE(drbg_cores) > j; j++, i++)
1988 drbg_fill_array(&drbg_algs[i], &drbg_cores[j], 0);
Il le transmet ensuite à une fonction d'assistance qui effectue l'initialisation :
1989 return crypto_register_rngs(drbg_algs, (ARRAY_SIZE(drbg_cores) * 2));
Dans crypto/rng.c cela parcourt simplement chaque rng pour l'enregistrer..
210 for (i = 0; i < count; i++) {
211 ret = crypto_register_rng(algs + i);
212 if (ret)
213 goto err;
214 }
Cette fonction effectue un ensemble d'étapes d'initialisation puis appelle une autre fonction pour l'allocation.
196 return crypto_register_alg(base);
Ce qui n'est pas si évident, c'est ce qui se passe lors de l'inscription.
Un autre module appelé tcrypt également intégré au noyau reçoit des notifications de nouveaux algorithmes insérés. Une fois qu'il voit un nouvel algorithme enregistré, il programme un test de celui-ci. C'est ce qui produit la sortie que vous voyez sur votre écran.
Lorsque le test est terminé, l'algorithme passe dans un état TESTED. Si le test échoue, j'imagine (Je n'ai pas trouvé le bit qui produit ce comportement) il n'est pas sélectionnable pour la recherche si vous passez les bons drapeaux.
La réussite ou l'échec du test est définitivement stockée en interne.
En plus de cela, l'appel du générateur de nombres aléatoires psudeo provoque l'itération d'une liste d'algorithmes de prngs par ordre de force comme dicté par cette note dans crypto/drbg.c
107 /*
108 * The order of the DRBG definitions here matter: every DRBG is registered
109 * as stdrng. Each DRBG receives an increasing cra_priority values the later
110 * they are defined in this array (see drbg_fill_array).
111 *
Étant donné que le plus fort n'échoue pas (hmac sha256), il est peu probable que vous utilisiez ceux qui ont échoué même s'ils pouvaient être sélectionnés.
Pour résumer -
- Cela se produit lorsque le
stdrngmodule est requis pour quelque chose. - Il charge tous ses algorithmes connus.
- Tous les algorithmes chargés sont testés. Certains peuvent échouer (pourquoi n'est pas pris en compte dans cette réponse).
- Tester les algorithmes ayant échoué ne devrait pas être disponible pour sélection ultérieurement.
- Les PRNGS sont classés par force et les PRNGS forts qui réussissent sont essayés en premier.
- Choses qui reposent sur
stdrngespérons qu'ils ne devraient pas utiliser ces algorithmes comme base pour leur source PRNG.
Vous pouvez voir quels algos ont réussi et réussi les tests en utilisant la commande suivante :
grep -EC5 'selftest.*passed' /proc/crypto
Vous pouvez également voir la priorité de sélection avec le champ 'priorité'. Plus la valeur est élevée, plus le PRNG est fort selon l'auteur du module.
Donc, heureux de me tromper ici car je ne me considère pas comme un programmeur du noyau mais, en conclusion -
Quand stdrng charge, il semble sélectionner d'autres algorithmes dans la liste des algos acceptables qui sont considérés comme plus forts que ceux qui ont échoué, et ceux qui ont échoué ne sont probablement pas sélectionnés de toute façon.
En tant que tel, je pense qu'il n'y a aucun risque supplémentaire pour vous lorsque vous utilisez luks.