Error de LUKS durante el arranque

Consicely, no creo que afecte la fuerza de su encriptación.

Revisé el código fuente y siempre que interprete bien lo que leí, no tienes que preocuparte necesariamente por esto.

Este código pertenece al módulo 'stdrng'. Al menos en Fedora 23, esto está integrado en el kernel en lugar de exportarse como un módulo del kernel.

Cuando stdrng se inicializa por primera vez, se producen las siguientes llamadas.

En crypto/drbg.c, la inicialización comienza aquí.

1997 module_init(drbg_init);

Esto registra todos los drbgs conocidos por el 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);

Luego lo pasa a una función auxiliar que realiza la inicialización:

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

En crypto/rng.c esto solo itera a través de cada rng para registrarlo.

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

Esta función realiza una serie de pasos de inicialización y luego llama a otra función para la asignación.

196         return crypto_register_alg(base);

Lo que no es tan obvio es lo que sucede durante el registro.

Otro módulo llamado tcrypt también integrado en el kernel recibe notificaciones de la inserción de nuevos algoritmos. Una vez que ve un nuevo algoritmo registrado, programa una prueba del mismo. Esto es lo que produce el resultado que ve en su pantalla.

Cuando finaliza la prueba, el algoritmo pasa al estado PROBADO. Si la prueba falla, me imagino (No pude encontrar el bit que produce este comportamiento) no se puede seleccionar para buscar si pasa las banderas correctas.

Si la prueba pasa o no definitivamente se almacena internamente.

Además de esto, llamar al generador de números aleatorios psudeo hace que se itere una lista de algoritmos de prngs en orden de fuerza según lo dictado por esta nota en 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  *

Dado que el más fuerte no falla (hmac sha256), es poco probable que esté utilizando los fallidos, incluso si se pudieran seleccionar.

Para resumir -

• Esto sucede cuando el stdrng se requiere módulo para algo.
• Carga todos sus algoritmos conocidos.
• Todos los algoritmos cargados se prueban. Algunos pueden fallar (por qué no se considera en esta respuesta).
• Probar algoritmos fallidos no debería estará disponible para su selección más adelante.
• Los PRNGS se ordenan por fuerza y ​​los PRNGS fuertes que pasan se prueban primero.
• Cosas que dependen de stdrng con suerte, no deberían usar estos algoritmos como base para su fuente PRNG.

Puede ver qué algos han tenido éxito y han pasado las pruebas usando el siguiente comando:

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

También puede ver la prioridad de selección con el campo 'prioridad'. Cuanto mayor sea el valor, más fuerte será el PRNG según el autor del módulo.

Entonces, feliz de estar equivocado aquí ya que no me considero un programador del kernel pero, en conclusión -

Cuando stdrng carga parece seleccionar otros algoritmos de la lista de algoritmos aceptables que se consideran más fuertes que los fallidos, además de que es probable que los fallidos no se seleccionen de todos modos.

Como tal, creo que esto no supone un riesgo adicional para ti cuando usas luks.