LUKS Error During Boot
Consicely, I do not believe it affects the strength of your encryption.
I've checked the source code and as long as I'm interpreting what I read right, you dont necessarily have to worry about this.
This code belongs to the module 'stdrng'. At least on Fedora 23 this is built into the kernel rather than exported as a kernel module.
When stdrng is initialized for the first time the following calls occur.
In crypto/drbg.c initialization starts here.
1997 module_init(drbg_init);
This registers all the drbgs known to the system..
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);
It then passes it to a helper function that performs the initialization:
1989 return crypto_register_rngs(drbg_algs, (ARRAY_SIZE(drbg_cores) * 2));
In crypto/rng.c this just iterates through each rng to register it..
210 for (i = 0; i < count; i++) {
211 ret = crypto_register_rng(algs + i);
212 if (ret)
213 goto err;
214 }
This function does a bunch of initialization steps then calls another function for allocation.
196 return crypto_register_alg(base);
Whats not so obvious is what happens during register.
Another module called tcrypt also built into the kernel receives notifications of new algorithms being inserted. Once it sees a new registered algorithm it schedules a test of it. This is what produces the output you see on your screen.
When the test is finished, the algorithm goes into a TESTED state. If the test fails, I imagine (I couldnt find the bit that produces this behaviour) it isn't selectable for searching if you pass the right flags.
Whether or not the test passes is definitely internally stored.
In addition to this, calling the psudeo random number generator causes a list of algorithms to be iterated of prngs in order of strength as dictated by this note 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 *
Since the strongest one does not fail (hmac sha256) its unlikely you are using the failed ones even if they could be selected.
To summarize -
- This happens when the
stdrngmodule is required for something. - It loads all its known algorithms.
- All algorithms loaded get tested. Some can fail (why is not considered in this answer).
- Test failed algorithms shouldnt be available for selection later.
- The PRNGS are ordered by strength and strong PRNGS that do pass are tried first.
- Things that rely on
stdrnghopefully should not use these algorithms as the basis for their PRNG source.
You can see which algos have succeeded and passed the tests using the following command:
grep -EC5 'selftest.*passed' /proc/crypto
You can also see the selection priority with the 'priority' field. The higher the value the stronger the PRNG according to the module author.
So, happy to be wrong here as I dont consider myself a kernel programmer but, in conclusion -
When stdrng loads it appears to select other algorithms from the list of acceptable algos which are considered stronger than the failed ones, plus the failed ones aren't likely selected anyway.
As such, I believe that this no additional risk to you when using luks.
How can I fix it?
Per Red Hat Knowledge Base, you must add 'ctr' Kernel module to your initrd. Their instructions also say to include 'ecb' though it seems the issue is with the 'ctr' module not being loaded.
dracut -f -v --add-drivers "ctr ecb"
Subscribers can see the full information. I am not sure if I am permitted to republish the rest here so I have paraphrased the full solution.
https://access.redhat.com/solutions/2249181
Edit 9/29/2016:
You can also add these drivers to /etc/dracut.conf so that they are added to the new initramfs on Kernel upgrades. Otherwise, your symptoms mysteriously reappear many months later. ;)
add_drivers+="ctr ecb"