Ich glaube nicht, dass dies die Stärke Ihrer Verschlüsselung beeinflusst.
Ich habe den Quellcode überprüft und solange ich das, was ich richtig lese, interpretiere, müssen Sie sich darüber keine Sorgen machen.
Dieser Code gehört zum Modul 'stdrng'. Zumindest unter Fedora 23 ist dies in den Kernel integriert und wird nicht als Kernelmodul exportiert.
Wenn stdrng zum ersten Mal initialisiert wird, treten die folgenden Aufrufe auf.
In crypto / drbg.c beginnt hier die Initialisierung.
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);
Anschließend wird es an eine Hilfsfunktion übergeben, die die Initialisierung durchführt:
1989 return crypto_register_rngs(drbg_algs, (ARRAY_SIZE(drbg_cores) * 2));
In crypto/rng.cdiesem Fall wird einfach jedes Rng durchlaufen, um es 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 aus und ruft dann eine andere Funktion zur Zuordnung auf.
196 return crypto_register_alg(base);
Was nicht so offensichtlich ist, ist, was während der Registrierung passiert.
Ein anderes Modul, das tcryptebenfalls in den Kernel integriert ist, erhält Benachrichtigungen über das Einfügen neuer Algorithmen. Sobald ein neuer registrierter Algorithmus angezeigt wird, plant er einen Test. Dies erzeugt die Ausgabe, die Sie auf Ihrem Bildschirm sehen.
Wenn der Test beendet ist, geht der Algorithmus in einen TEST-Zustand über. Wenn der Test fehlschlägt, kann ich mir vorstellen (ich konnte das Bit, das dieses Verhalten erzeugt, nicht finden), dass es nicht für die Suche ausgewählt werden kann, wenn Sie die richtigen Flags übergeben.
Ob der Test erfolgreich ist oder nicht, wird definitiv intern gespeichert.
Darüber hinaus bewirkt das Aufrufen des Psudeo-Zufallszahlengenerators, dass eine Liste von Algorithmen von Prngs in der Reihenfolge der Stärke iteriert wird, wie in dieser Anmerkung in vorgegeben 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 *
Da der stärkste nicht ausfällt (hmac sha256), ist es unwahrscheinlich, dass Sie die ausgefallenen verwenden, selbst wenn sie ausgewählt werden könnten.
Zusammenfassen -
- Dies passiert, wenn das
stdrngModul für etwas benötigt wird.
- Es lädt alle bekannten Algorithmen.
- Alle geladenen Algorithmen werden getestet. Einige können scheitern (warum wird in dieser Antwort nicht berücksichtigt).
- Test fehlgeschlagene Algorithmen sollten später nicht zur Auswahl stehen.
- Die PRNGS sind nach Stärke geordnet und starke PRNGS, die bestehen, werden zuerst ausprobiert.
- Dinge, auf die man sich
stdrnghoffentlich stützt, sollten diese Algorithmen nicht als Grundlage für ihre PRNG-Quelle verwenden.
Mit dem folgenden Befehl können Sie sehen, welche Algen erfolgreich waren und die Tests bestanden haben:
grep -EC5 'selftest.*passed' /proc/crypto
Sie können die Auswahlpriorität auch im Feld "Priorität" anzeigen. Je höher der Wert, desto stärker ist der PRNG laut Modulautor.
Ich bin froh, dass ich mich hier irre, da ich mich nicht als Kernel-Programmierer betrachte, sondern abschließend -
Beim stdrngLaden werden anscheinend andere Algorithmen aus der Liste der akzeptablen Algen ausgewählt, die als stärker als die fehlgeschlagenen angesehen werden, und die fehlgeschlagenen werden wahrscheinlich sowieso nicht ausgewählt.
Daher glaube ich, dass dies kein zusätzliches Risiko für Sie ist, wenn Sie luks verwenden.
