Conscientemente, não acredito que isso afete a força da sua criptografia.
Eu verifiquei o código-fonte e, desde que eu esteja interpretando o que eu li corretamente, você não precisa necessariamente se preocupar com isso.
Este código pertence ao módulo 'stdrng'. Pelo menos no Fedora 23, isso é embutido no kernel ao invés de ser exportado como um módulo do kernel.
Quando o stdrng é inicializado pela primeira vez, ocorrem as seguintes chamadas.
Em crypto / drbg.c, a inicialização começa aqui.
1997 module_init(drbg_init);
Isso registra todos os drbgs conhecidos no 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);
Em seguida, passa para uma função auxiliar que realiza a inicialização:
1989 return crypto_register_rngs(drbg_algs, (ARRAY_SIZE(drbg_cores) * 2));
Em crypto/rng.c , isso apenas itera em cada rng para registrá-lo.
210 for (i = 0; i < count; i++) {
211 ret = crypto_register_rng(algs + i);
212 if (ret)
213 goto err;
214 }
Esta função faz um monte de etapas de inicialização e chama outra função para alocação.
196 return crypto_register_alg(base);
O que não é tão óbvio é o que acontece durante o registro.
Outro módulo chamado tcrypt também embutido no kernel recebe notificações de novos algoritmos sendo inseridos. Depois de ver um novo algoritmo registrado, ele programa um teste. É isso que produz a saída que você vê na tela.
Quando o teste termina, o algoritmo entra em um estado TESTED. Se o teste falhar, eu imagino (eu não encontrei o bit que produz este comportamento) ele não é selecionável para procurar se você passar os flags certos.
Se o teste é ou não definitivamente armazenado internamente.
Além disso, chamar o gerador de números aleatórios psudeo faz com que uma lista de algoritmos seja iterada de prngs em ordem de intensidade, conforme ditado por esta nota em 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 *
Como o mais strong não falha (hmac sha256) é improvável que você esteja usando os que falharam, mesmo que pudessem ser selecionados.
Para resumir -
- Isso acontece quando o módulo
stdrng é necessário para algo.
- Carrega todos os seus algoritmos conhecidos.
- Todos os algoritmos carregados são testados. Alguns podem falhar (por que não é considerado nesta resposta).
- Algoritmos de teste com falha não devem estar disponíveis para seleção posterior.
- O PRNGS é ordenado por força e os PRNGS strongs que passam são julgados primeiro.
- As coisas que dependem de
stdrng não devem usar esses algoritmos como base para sua fonte de PRNG.
Você pode ver quais algos foram bem-sucedidos e passou nos testes usando o seguinte comando:
grep -EC5 'selftest.*passed' /proc/crypto
Você também pode ver a prioridade da seleção com o campo "prioridade". Quanto maior o valor, mais strong o PRNG, de acordo com o autor do módulo.
Então, feliz por estar errado aqui, pois eu não me considero um programador do kernel, mas, em conclusão -
Quando stdrng é carregado, parece que selecionou outros algoritmos da lista de algos aceitáveis que são considerados mais strongs do que os fracassados, mais os que falharam não são provavelmente selecionados de qualquer maneira.
Como tal, acredito que isso não representa um risco adicional para você ao usar o luks.
