Errore LUKS durante l'avvio

Di conseguenza, non credo che ciò influisca sulla forza della tua crittografia.

Ho controllato il codice sorgente e fintanto che interpreto correttamente ciò che ho letto, non devi necessariamente preoccuparti di questo.

Questo codice appartiene al modulo 'stdrng'. Almeno su Fedora 23 questo è integrato nel kernel piuttosto che esportato come modulo del kernel.

Quando stdrng viene inizializzato per la prima volta, si verificano le seguenti chiamate.

In crypto/drbg.c l'inizializzazione inizia qui.

1997 module_init(drbg_init);

Questo registra tutti i drbgs noti al sistema..

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);

Quindi lo passa a una funzione di supporto che esegue l'inizializzazione:

1989         return crypto_register_rngs(drbg_algs, (ARRAY_SIZE(drbg_cores) * 2));

In crypto/rng.c questo scorre semplicemente ogni rng per registrarlo..

210         for (i = 0; i < count; i++) {
211                 ret = crypto_register_rng(algs + i);
212                 if (ret)
213                         goto err;
214         }

Questa funzione esegue una serie di passaggi di inizializzazione, quindi chiama un'altra funzione per l'allocazione.

196         return crypto_register_alg(base);

Ciò che non è così ovvio è ciò che accade durante la registrazione.

Un altro modulo chiamato tcrypt anch'esso integrato nel kernel riceve le notifiche dei nuovi algoritmi che vengono inseriti. Una volta che vede un nuovo algoritmo registrato ne pianifica un test. Questo è ciò che produce l'output che vedi sullo schermo.

Al termine del test, l'algoritmo entra in uno stato TESTED. Se il test fallisce, immagino (non sono riuscito a trovare il bit che produce questo comportamento) non è selezionabile per la ricerca se passi i flag giusti.

L'esito positivo o negativo del test è sicuramente memorizzato internamente.

In aggiunta a questo, la chiamata allo psudeo generatore di numeri casuali provoca l'iterazione di un elenco di algoritmi di prng in ordine di forza come dettato da questa nota in 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  *

Dal momento che il più forte non fallisce (hmac sha256) è improbabile che tu stia usando quelli falliti anche se potrebbero essere selezionati.

Per riassumere -

• Questo accade quando stdrng module è richiesto per qualcosa.
• Carica tutti i suoi algoritmi conosciuti.
• Tutti gli algoritmi caricati vengono testati. Alcuni possono fallire (perché non è considerato in questa risposta).
• Algoritmi falliti di test non dovrebbero essere disponibile per la selezione in seguito.
• I PRNGS sono ordinati per forza e i PRNGS forti che passano vengono provati per primi.
• Cose che si basano su stdrng si spera che non dovrebbero utilizzare questi algoritmi come base per la loro fonte PRNG.

Puoi vedere quali algoritmi hanno avuto successo e superato i test utilizzando il seguente comando:

 grep -EC5 'selftest.*passed' /proc/crypto

Puoi anche vedere la priorità di selezione con il campo 'priorità'. Più alto è il valore, più forte è il PRNG secondo l'autore del modulo.

Quindi, felice di sbagliarmi qui perché non mi considero un programmatore del kernel ma, in conclusione -

Quando stdrng carica sembra selezionare altri algoritmi dall'elenco di algoritmi accettabili che sono considerati più forti di quelli falliti, inoltre quelli falliti non sono probabilmente selezionati comunque.

In quanto tale, credo che questo non comporta alcun rischio aggiuntivo per te quando utilizzi luks.