Results 1 to 6 of 6

Thread: New AVX/AVX2 Crypto Code For The Linux Kernel

  1. #1
    Join Date
    Jan 2007
    Posts
    13,474

    Default 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...

    http://www.phoronix.com/vr.php?view=MTU0MTY

  2. #2
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,766

    Default

    I just noticed that in my kernel, I have the "Cryptographic API" (in menuconfig) disabled.

    What is this actually used for?

  3. #3
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,754

    Default

    It lets userspace use the kernel implementations.

  4. #4
    Join Date
    May 2013
    Posts
    347

    Default What EXACTLY is the current role of HW random number generators in this?

    Quote Originally Posted by phoronix View Post
    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...

    http://www.phoronix.com/vr.php?view=MTU0MTY
    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.

    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?

  5. #5
    Join Date
    Oct 2012
    Posts
    148

    Default

    Quote Originally Posted by Luke View Post
    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.

    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

  6. #6
    Join Date
    May 2013
    Posts
    347

    Default Thanks, I just did some more digging too

    Quote Originally Posted by tomato View Post
    now it's used only as an additional source
    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.

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •