Ehrlich gesagt glaube ich nicht, dass dies die Stärke Ihrer Verschlüsselung beeinflusst.
Ich habe den Quellcode überprüft und solange ich das, was ich gelesen habe, richtig interpretiere, müssen Sie sich darüber nicht unbedingt Sorgen machen.
Dieser Code gehört zum Modul 'stdrng'. Zumindest bei Fedora 23 ist dies in den Kernel eingebaut, anstatt als Kernelmodul exportiert zu werden.
Wenn stdrng zum ersten Mal initialisiert wird, erfolgen die folgenden Aufrufe.
In crypto/drbg.c beginnt die Initialisierung hier.
1997 module_init(drbg_init);
Dies registriert alle dem System bekannten drbgs..
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);
Es übergibt es dann an eine Hilfsfunktion, die die Initialisierung durchführt:
1989 return crypto_register_rngs(drbg_algs, (ARRAY_SIZE(drbg_cores) * 2));
In crypto/rng.c
dies iteriert einfach durch jeden rng, um ihn zu registrieren..
210 for (i = 0; i < count; i++) {
211 ret = crypto_register_rng(algs + i);
212 if (ret)
213 goto err;
214 }
Diese Funktion führt eine Reihe von Initialisierungsschritten durch und ruft dann eine andere Funktion zur Zuweisung auf.
196 return crypto_register_alg(base);
Was nicht so offensichtlich ist, ist, was während der Registrierung passiert.
Ein weiteres Modul namens tcrypt
Der ebenfalls in den Kernel integrierte Algorithmus erhält Benachrichtigungen über neu eingefügte Algorithmen. Sobald es einen neuen registrierten Algorithmus sieht, plant es einen Test davon. Dies erzeugt die Ausgabe, die Sie auf Ihrem Bildschirm sehen.
Wenn der Test beendet ist, geht der Algorithmus in einen TESTED-Zustand. Wenn der Test fehlschlägt, stelle ich mir vor (Ich konnte das Bit, das dieses Verhalten erzeugt, nicht finden) Es ist nicht für die Suche auswählbar, wenn Sie die richtigen Flags übergeben.
Ob die Testdurchläufe definitiv intern gespeichert werden oder nicht.
Darüber hinaus bewirkt der Aufruf des Psudeo-Zufallszahlengenerators, dass eine Liste von Algorithmen von Prngs in der Reihenfolge ihrer Stärke iteriert wird, wie in dieser Anmerkung in crypto/drbg.c
vorgeschrieben
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 *
Da der stärkste nicht fehlschlägt (hmac sha256), ist es unwahrscheinlich, dass Sie die fehlgeschlagenen verwenden, selbst wenn sie ausgewählt werden könnten.
Zusammenfassend -
- Dies geschieht, wenn
stdrng
Modul wird für etwas benötigt. - Es lädt alle seine bekannten Algorithmen.
- Alle geladenen Algorithmen werden getestet. Einige können fehlschlagen (warum wird in dieser Antwort nicht berücksichtigt).
- Testen Sie fehlgeschlagene Algorithmen sollten nicht später zur Auswahl stehen.
- Die PRNGS werden nach Stärke geordnet und starke PRNGS, die bestehen, werden zuerst versucht.
- Dinge, die auf
stdrng
angewiesen sind sollten diese Algorithmen hoffentlich nicht als Grundlage für ihre PRNG-Quelle verwenden.
Mit dem folgenden Befehl können Sie sehen, welche Algorithmen erfolgreich waren und die Tests bestanden haben:
grep -EC5 'selftest.*passed' /proc/crypto
Sie können die Auswahlpriorität auch mit dem Feld „Priorität“ sehen. Je höher der Wert, desto stärker der PRNG laut Modulautor.
Ich bin froh, hier falsch zu liegen, da ich mich nicht als Kernel-Programmierer betrachte, aber abschließend -
Wenn stdrng
lädt, scheint es, andere Algorithmen aus der Liste der akzeptablen Algorithmen auszuwählen, die als stärker angesehen werden als die fehlgeschlagenen, und die fehlgeschlagenen werden wahrscheinlich sowieso nicht ausgewählt.
Daher glaube ich, dass dies kein zusätzliches Risiko für Sie darstellt, wenn Sie Luks verwenden.