New AVX/AVX2 Crypto Code For The Linux Kernel
Phoronix: New AVX/AVX2 Crypto Code For The Linux Kernel
A set of Intel developers have worked out a new set of AVX and AVX2 routines for the Linux kernel to enhance additional crypto functionality for better performance...
I just noticed that in my kernel, I have the "Cryptographic API" (in menuconfig) disabled.
What is this actually used for?
It lets userspace use the kernel implementations.
What EXACTLY is the current role of HW random number generators in this?
I've seen changes over time in attitudes concerning the hardware generation of random numbers that is part of AES-NI, and am not the only one with concerns. I know that at one point the Linux kernel used this as one input to seed entropy for /dev/random and presumable /dev/urandom was well and did not sumply map /dev/random to it. This is crucial because it would be something the NSA could agree with Intel to limit the randomness of, which would lead to keys the NSA can brute-force if used by itself. If it is used only as one of many entropy sources, by comparison, even an NSA-engineered limitation to the randomness of the hw randome number generator would probably leave /dev/random stronger than before and certainly leave /dev/urandom stronger than without it. Truecrypt does not use any of the key generation parts of AES-NI, only the round processing parts for this reason.
Originally Posted by phoronix
There was a previous dispute where a Linux kernel developer left over the use of the hardware random number generator, what exactly is the current status of it's use? Is it still used as an entropy source, or is it now mapped directly to /dev/random or /dev/urandom?
now it's used only as an additional source
Originally Posted by Luke
Thanks, I just did some more digging too
Good to know the source of LUKS keys in Cryptsetup works in such a way that any NSA backdoor in AES-NI random number generation (the usual NSA target) would fail.
Originally Posted by tomato
I did some more digging, looks like the HW random number generator is Xor'd with the "traditional" random number stream, then hashed. Knowing one input but not the other to Xor does not give knowledge of the output. As a result, this improves the security of /dev/random and /dev/urandom against any adversary other than the NSA, if not backdoored makes them more secure against the NSA as well, if backdoored security against the NSA would be the same as with an older proc not supporting AES-NI. This means any backdoor fails, getting control over only one of two inputs into Xor, even if they can reverse the hash. Intel tried to get Linus Torvalds to just map /dev/random to the HW random number generator but he refused-and is apparently damned glad he did after the Snowden revelations.
That in turn means blacklisting AES-NI when encrypting a new volume should have no security benefits against the NSA and be a security disadvantage against all opponents other than the NSA and possibly when up against the NSA as well. When opening a previously made volume, any changes in generation of keys would have no effect, as you are using that volume's existing key. Good to know, I was wondering if I should remake all my encrypted volumes over this-and then have to copy 2.5TB of files over again.
Don't forget, to my knowledge there has not been a single criminal prosecution anywhere sucessfully supported by information decrypted by a backdoor in unmodified hardware. In-line keyloggers seem to be the favored attack on disk encryption, probably due to reliablity. You might want to epoxy down laptop keyboards, keep a close eye on your desktop's wiring, and never use wireless keyboards. An encrypted wireless keyboard would be commercial closed-source encryption and is presumed compromised.