security/keys: rewrite all of big_key crypto
Subsystems (3)
PATCH v4 1/1 security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with get_random_bytes_wait, so that we wouldn't use bad randomness at boot time. But, upon looking further, it appears that there were even deeper underlying cryptographic problems, and that this seems to have been committed with very little crypto review. So, I rewrote the whole thing, trying to keep to the conventions introduced by the previous author, to fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep using it like this, when in fact there's already get_random_bytes_wait, which can ensure there's enough entropy and be a much more standard way of generating keys. Since this sensitive material is being stored untrusted, using ECB and no authentication is simply not okay at all. I find it surprising and a bit horrifying that this code even made it past basic crypto review, which perhaps points to some larger issues. This patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely generated each time, we can set the nonce to zero. There was also a race condition in which the same key would be reused at the same time in different threads. A mutex fixes this issue now. And, some error paths forgot to zero out sensitive material, so this patch changes a kfree into a kzfree.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the cipher text in particular ways in order to manipulate the plaintext, which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
--- security/keys/Kconfig | 4 +- security/keys/big_key.c | 139 ++++++++++++++++++++++-------------------------- 2 files changed, 65 insertions(+), 78 deletions(-)
Changes v3->v4:
- Patchset resurrected from the dead. Just like the original use of ECB, which this patch fixes, crypto-related things are sometimes neglected, unfortunately.
- Rebased on top of 4.13+ changes.
- Now that get_random_bytes_wait has been merged, we can actually use it, just like in v1 of this patch.
security/keys/Kconfig +1 -3
@@ -45,10 +45,8 @@ config BIG_KEYS bool "Large payload keys" depends on KEYS depends on TMPFS - depends on (CRYPTO_ANSI_CPRNG = y || CRYPTO_DRBG = y) select CRYPTO_AES - select CRYPTO_ECB - select CRYPTO_RNG + select CRYPTO_GCM help This option provides support for holding large keys within the kernel (for example Kerberos ticket caches). The data may be stored out to
security/keys/big_key.c +64 -75
263 lines not on this page · raw message
Signature · 1 line
2.14.1
PATCH v5 1/1 security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with get_random_bytes_wait, so that we wouldn't use bad randomness at boot time. But, upon looking further, it appears that there were even deeper underlying cryptographic problems, and that this seems to have been committed with very little crypto review. So, I rewrote the whole thing, trying to keep to the conventions introduced by the previous author, to fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep using it like this, when in fact there's already get_random_bytes_wait, which can ensure there's enough entropy and be a much more standard way of generating keys. Since this sensitive material is being stored untrusted, using ECB and no authentication is simply not okay at all. I find it surprising and a bit horrifying that this code even made it past basic crypto review, which perhaps points to some larger issues. This patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely generated each time, we can set the nonce to zero. There was also a race condition in which the same key would be reused at the same time in different threads. A mutex fixes this issue now. And, some error paths forgot to zero out sensitive material, so this patch changes a kfree into a kzfree.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the cipher text in particular ways in order to manipulate the plaintext, which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
--- security/keys/Kconfig | 4 +- security/keys/big_key.c | 141 +++++++++++++++++++++++------------------------- 2 files changed, 67 insertions(+), 78 deletions(-)
Changes v4->v5:
- Fix get_random_bytes_wait ret value derp.
security/keys/Kconfig +1 -3
@@ -45,10 +45,8 @@ config BIG_KEYS bool "Large payload keys" depends on KEYS depends on TMPFS - depends on (CRYPTO_ANSI_CPRNG = y || CRYPTO_DRBG = y) select CRYPTO_AES - select CRYPTO_ECB - select CRYPTO_RNG + select CRYPTO_GCM help This option provides support for holding large keys within the kernel (for example Kerberos ticket caches). The data may be stored out to
security/keys/big_key.c +66 -75
265 lines not on this page · raw message
Signature · 1 line
2.14.1
Hi Jason,
security/keys/big_key.c int big_key_preparse(struct key_preparsed_payload *prep) · line 176
Quoted 7 lines · Jason A. Donenfeld
security/keys/big_key.c +3
-4- - ret =big_key_gen_enckey (enckey); -if (ret) - goto err_enckey; + ret =get_random_bytes_wait (enckey,ENC_KEY_SIZE ); +if (unlikely (ret)) + goto error;
This should jump to 'err_enckey', otherwise it will leak 'enckey'.
Otherwise the changes all look good; after fixing the above, feel free to add my Reviewed-by. Yes, AES-GCM is the right choice here. It is, however, almost certainly the case that if someone can modify your swap partition, they can already own your system in many other ways, so the "authenticated" portion of "authenticated encryption" may not actually buy much in this situation :-)
The patch is a little long and perhaps should be split into several patches, each of which fixes one bug; but see what David thinks.
I should also note, that while there definitely were some inadmissible bugs here, the support for encrypting big_key's was only added recently, in the v4.7 kernel. And obviously not encrypting at all is at least as much as a "vulnerability" as using weak encryption. I'm also a little skeptical that people actually care enough about big_key's for it to be worthwhile to mark a rewrite like this for stable, though I suppose it wouldn't be *too* hard to at least cherry-pick this to 4.9 if you wanted. (There is a small conflict so you'd have to send the backport yourself after this goes into mainline.)
Eric
Quoted 1 line · Eric Biggers
This should jump to '
err_enckey', otherwise it will leak 'enckey'.
Yikes, good catch, thanks!
Quoted 3 lines
Otherwise the changes all look good; after fixing the above, feel free to add my Reviewed-by.
Ack.
Quoted 4 lines
Yes, AES-GCM is the right choice here. It is, however, almost certainly the case that if someone can modify your swap partition, they can already own your system in many other ways, so the "authenticated" portion of "authenticated encryption" may not actually buy much in this situation :-)
True, though this is slightly different from people putting their big_keys on NFS, I guess (but who would do such a thing anyway?).
Quoted 2 lines
The patch is a little long and perhaps should be split into several patches, each of which fixes one bug; but see what David thinks.
Meh, it's a rewrite, so sure, it's long. I saw a bunch of bugs and rewrote the whole thing rather than going one-by-one with the bugs, which would have produced a series. Personally I'd prefer to keep it like this than spending the time needling away with git and extra commit messages and struggling to make them each build separately. Seems like very very little gain for the time required to do that right. *shrug* Will wait to hear from David.
Quoted 4 lines
I should also note, that while there definitely were some inadmissible bugs here, the support for encrypting big_key's was only added recently, in the v4.7 kernel. And obviously not encrypting at all is at least as much as a "vulnerability" as using weak encryption.
Yea that's fair. I'm mostly just running around like a headless chicken after seeing ECB and wondering how this got committed in the first place, but nobody really takes chickens seriously. But yes, I suppose one way of considering this is just to say, "big_keys did not use encryption before 4.14, even though the code was really complicated."
Quoted 5 lines
I'm also a little skeptical that
people actually care enough about big_key's for it to be worthwhile to mark a rewrite like this for stable, though I suppose it wouldn't be *too* hard to at least cherry-pick this to 4.9 if you wanted. (There is a small conflict so you'd have to send the backport yourself after this goes into mainline.)
I imagine the conflicts will be moving back from get_random_bytes_wait to get_random_bytes and maybe the loff_t/kernel_{read,write} thing. Is this what you had in mind too? I should be able to handle those fairly easily and send it to Greg manually after this lands.
Thanks again for the review, very appreciated.
Regards,
Jason
PATCH v6 1/1 security/keys: rewrite all of big_key crypto
This started out as just replacing the use of crypto/rng with get_random_bytes_wait, so that we wouldn't use bad randomness at boot time. But, upon looking further, it appears that there were even deeper underlying cryptographic problems, and that this seems to have been committed with very little crypto review. So, I rewrote the whole thing, trying to keep to the conventions introduced by the previous author, to fix these cryptographic flaws.
It makes no sense to seed crypto/rng at boot time and then keep using it like this, when in fact there's already get_random_bytes_wait, which can ensure there's enough entropy and be a much more standard way of generating keys. Since this sensitive material is being stored untrusted, using ECB and no authentication is simply not okay at all. I find it surprising and a bit horrifying that this code even made it past basic crypto review, which perhaps points to some larger issues. This patch moves from using AES-ECB to using AES-GCM. Since keys are uniquely generated each time, we can set the nonce to zero. There was also a race condition in which the same key would be reused at the same time in different threads. A mutex fixes this issue now. And, some error paths forgot to zero out sensitive material, so this patch changes a kfree into a kzfree.
So, to summarize, this commit fixes the following vulnerabilities:
* Low entropy key generation, allowing an attacker to potentially guess or predict keys.
* Unauthenticated encryption, allowing an attacker to modify the cipher text in particular ways in order to manipulate the plaintext, which is is even more frightening considering the next point.
* Use of ECB mode, allowing an attacker to trivially swap blocks or compare identical plaintext blocks.
* Key re-use.
* Faulty memory zeroing.
--- security/keys/Kconfig | 4 +- security/keys/big_key.c | 139 ++++++++++++++++++++++-------------------------- 2 files changed, 66 insertions(+), 77 deletions(-)
Changes v5->v6:
- Fix memory leak.
- CC->Reviewed-by for Eric.
security/keys/Kconfig +1 -3
@@ -45,10 +45,8 @@ config BIG_KEYS bool "Large payload keys" depends on KEYS depends on TMPFS - depends on (CRYPTO_ANSI_CPRNG = y || CRYPTO_DRBG = y) select CRYPTO_AES - select CRYPTO_ECB - select CRYPTO_RNG + select CRYPTO_GCM help This option provides support for holding large keys within the kernel (for example Kerberos ticket caches). The data may be stored out to
security/keys/big_key.c +65 -74
264 lines not on this page · raw message
Signature · 1 line
2.14.1
David Howells
maintainerQuoted 2 lines · Jason A. Donenfeld
And, some error paths forgot to zero out sensitive material, so this patch changes a kfree into a kzfree.
Can you split that out into a separate preparatory patch?
Also, I recommend limiting the lines in your patch description to 75 chars lest you get people who run checkpatch on everything pestering you ;-)
David
Quoted 9 lines · David Howells
Quoted 2 lines · Jason A. Donenfeld
And, some error paths forgot to zero out sensitive material, so this patch changes a kfree into a kzfree.
Can you split that out into a separate preparatory patch?
Also, I recommend limiting the lines in your patch description to 75 chars lest you get people who run checkpatch on everything pestering you ;-)
No problem. Will split that out, then fix the description, and resubmit as v7. Coming your way shortly.
Am Sonntag, 17. September 2017, 13:52:17 CEST schrieb Jason A. Donenfeld:
Hi Jason,
Quoted 2 lines
* Use of ECB mode, allowing an attacker to trivially swap blocks or compare identical plaintext blocks.
The use of GCM with the implementtion here is just as challenging. The implementation uses a NULL IV. GCM is a very brittle cipher where the construction of the IV is of special importance. SP800-38D section 8.2.1 and 8.2.2 outlines the generation methods of the IV. A collision of keys/IVs is fatal. I understand that keys are generated anew each time which makes that issue less critical here. However, as user space may see the ciphertext, GCM should simply not be used.
A fix could be as easy as to use CCM or one of the authenc() ciphers. Yet, for both I am not sure how a zero IV affects the cipher.
The cipher where you do not need to handle the IV at all would be the RFC3394/ SP800-38F keywrapping cipher which is meant for the encryption of key material which includes authentication as well. It is available as an skcipher under the name of kw(aes). If you want to use it, please be careful that you obtain the generated IV to be stored with the plaintext as documented in the comments in crypto/keywrap.c
Ciao
Stephan
Quoted 7 lines · Stephan Mueller
The use of GCM with the implementtion here is just as challenging. The implementation uses a NULL IV. GCM is a very brittle cipher where the construction of the IV is of special importance. SP800-38D section 8.2.1 and 8.2.2 outlines the generation methods of the IV. A collision of keys/IVs is fatal. I understand that keys are generated anew each time which makes that issue less critical here. However, as user space may see the ciphertext, GCM should simply not be used.
This sounds incorrect to me. Choosing a fresh, random, one-time-use 256-bit key and rolling with a zero nonce is a totally legitimate way of using GCM. There's no possible reuse of the key stream this way. However, on the off chance that you know what you're talking about, could you outline the cryptographic attack you have in mind, or if that's too difficult, simply link to the relevant paper on eprint?
Am Mittwoch, 20. September 2017, 12:52:21 CEST schrieb Jason A. Donenfeld:
Hi Jason,
Quoted 7 lines
This sounds incorrect to me. Choosing a fresh, random, one-time-use 256-bit key and rolling with a zero nonce is a totally legitimate way of using GCM. There's no possible reuse of the key stream this way. However, on the off chance that you know what you're talking about, could you outline the cryptographic attack you have in mind, or if that's too difficult, simply link to the relevant paper on eprint?
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/Joux_comments.pdf
Ciao
Stephan
Quoted 1 line · Stephan Mueller
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/Joux_comments.pdf
Section 3 shows an attack with repeated nonces, which we don't do here.
Section 4 shows an attack using a non-96-bit nonce, which we also don't do here.
Am Mittwoch, 20. September 2017, 16:01:21 CEST schrieb Jason A. Donenfeld:
Hi Jason,
Quoted 2 lines
Section 3 shows an attack with repeated nonces, which we don't do here.
Maybe I miss a point here, but zero IVs is no repetition of nonces?
Ciao
Stephan
Quoted 3 lines · Stephan Mueller
Quoted 1 line
Section 3 shows an attack with repeated nonces, which we don't do here.
Maybe I miss a point here, but zero IVs is no repetition of nonces?
If there's a fresh key each time, then no, it's not a repetition.
This patch uses a fresh random key for every encryption.
Am Samstag, 16. September 2017, 15:00:34 CEST schrieb Jason A. Donenfeld:
Hi Jason,
Quoted 2 lines
This started out as just replacing the use of
crypto/rngwithget_random_bytes_wait,
This change is a challenge. The use of the kernel crypto API's DRNG has been made to allow FIPS 140-2 compliance. Otherwise, the entire key generation logic will not be using the right(TM) DRNG. Thus, I would not suggest to replace that for a stable tree.
Note, I am currently working on a pluggable DRNG apporach for /dev/random and /dev/urandom to be able to get rid of the use of the kernel crypto API's DRNG API. It is ready and I will air that solution shortly. Yet, it needs work to be integrated upstream (and approval from Ted Tso).
Ciao
Stephan
Greg KH
maintainerQuoted 11 lines · Stephan Mueller
Am Samstag, 16. September 2017, 15:00:34 CEST schrieb Jason A. Donenfeld:
Hi Jason,
Quoted 2 lines
This started out as just replacing the use of
crypto/rngwithget_random_bytes_wait,This change is a challenge. The use of the kernel crypto API's DRNG has been made to allow FIPS 140-2 compliance. Otherwise, the entire key generation logic will not be using the right(TM) DRNG. Thus, I would not suggest to replace that for a stable tree.
Why not? What is the issue here, there is only one "DRNG" in the kernel now (and probably for a long time...)
Quoted 4 lines
Note, I am currently working on a pluggable DRNG apporach for
/dev/randomand/dev/urandomto be able to get rid of the use of the kernel crypto API's DRNG API. It is ready and I will air that solution shortly. Yet, it needs work to be integrated upstream (and approval from Ted Tso).
We don't postpone work for potential future patches that might or might not ever happen or get merged. That's how NetBSD died...
thanks,
greg k-h
Am Montag, 18. September 2017, 11:04:55 CEST schrieb Greg KH:
Hi Greg,
Quoted 8 lines · Stephan Mueller
Quoted 7 lines
Am Samstag, 16. September 2017, 15:00:34 CEST schrieb Jason A. Donenfeld:
Hi Jason,
Quoted 2 lines
This started out as just replacing the use of
crypto/rngwithget_random_bytes_wait,
Quoted 6 lines
Quoted 4 lines
This change is a challenge. The use of the kernel crypto API's DRNG has been made to allow FIPS 140-2 compliance. Otherwise, the entire key generation logic will not be using the right(TM) DRNG. Thus, I would not suggest to replace that for a stable tree.
Why not?
An SP800-90A-compliant DRNG must be used in those circumstances.
Quoted 2 lines
What is the issue here, there is only one "DRNG" in the kernel now (and probably for a long time...)
There are more DRNGs implemented in the kernel crypto API (see crypto/drbg.c or crypto/ansi-cprng.c).
Quoted 8 lines
Quoted 5 lines
Note, I am currently working on a pluggable DRNG apporach for
/dev/randomand/dev/urandomto be able to get rid of the use of the kernel crypto API's DRNG API. It is ready and I will air that solution shortly. Yet, it needs work to be integrated upstream (and approval from Ted Tso).We don't postpone work for potential future patches that might or might not ever happen or get merged. That's how NetBSD died...
Then I would recommend to leave it as is or hear complaints from other users.
Ciao
Stephan
Hello Stephan,
I realize you have your Linux RNG project, which is a very worthwhile goal that I support you in. I hope you're eventually successful, and I apologize for not being more available in the last 2.5 months to chime in on that patchset thread you posted.
However, your message to this thread here is a completely inappropriate and nonsensical hijacking, which makes me entirely question your overall judgement.
(David -- please don't let such hijacking derail or delay these critical vulnerability fixes from landing.)
Quoted 4 lines
This change is a challenge. The use of the kernel crypto API's DRNG has been made to allow FIPS 140-2 compliance. Otherwise, the entire key generation logic will not be using the right(TM) DRNG. Thus, I would not suggest to replace that for a stable tree.
Complete and utter nonsense. This patch has a history (this is already v6), and it's pretty obvious from prior discussion and conclusion that the only reason "crypto/rng" was used for this is because the original author just had no idea what he was doing (thus leading to using ECB as well). Besides, from what RNG do you think the seed for that was generated?
Quoted 3 lines
Note, I am currently working on a pluggable DRNG apporach for
/dev/randomand/dev/urandomto be able to get rid of the use of the kernel crypto API's DRNG API. It is ready and I will air that solution shortly.
Good to hear you're still working on that project.
Quoted 2 lines
Yet, it needs work to
be integrated upstream (and approval from Ted Tso).
Good luck with getting approval... While Ted and I have our differences like any two kernel developers, I really tend agree with him in his attitude about this FIPS silliness. It's unlikely you're going to be able to shovel this stuff into random.c, and I think doing so will undermine your entire LRNG effort.
Quoted 1 line
An SP800-90A-compliant DRNG must be used in those circumstances.
Again, complete and utter unsubstantiated nonsense.
Quoted 1 line
Then I would recommend to leave it as is or hear complaints from other users.
What a poor lack of judgement.
I get it -- this FIPS compliance backwardness is something you're keen about. But don't start hijacking every thread that involves randomness with a demand to replace calls to get_random_bytes with wrappers in outdated, flawed, government compliance crypto API key expanders. From a cryptographic point of view it's a ridiculous demand. And from an engineering point of view, it's a ridiculous demand too, for if get_random_bytes already returned FIPS-compliant randomness, you wouldn't be writing this email here.
Instead, if you want your FIPS garbage in the Linux RNG, take your battle for that over to random.c. I'll oppose you to the end on it, but at the very least it will the the appropriate venue for that discussion. In the meantime, stop hijacking this thread.
Thanks,
Jason
PS: apologies for what's probably perceived as an unfriendly and overly hostile tone of this email. It's not my intention to alienate you, but I do feel necessary in these circumstances to write as directly as possible.
Quoted 5 lines · Jason A. Donenfeld
Good luck with getting approval... While Ted and I have our differences like any two kernel developers, I really tend agree with him in his attitude about this FIPS silliness. It's unlikely you're going to be able to shovel this stuff into
random.c, and I think doing so will undermine your entire LRNG effort.
Let me add one more reason why FIPS compliance for the kernel is just ***stupid***. The way FIPS compliance works, you have to pay hundreds of thousands of dollars to a FIPS certification lab to certify a specific binary, complete with the exact build environment (compiler, binutils, etc.) used to build that kernel binary.
The moment you need to make a change --- say, to fix a critical zero-day security bug --- this breaks the FIPS certification, and you then have to go back to the FIPS certification lab, and pay another hundreds of thousands of dollars for another certification. This will take weeks/months, and while you are waiting for the results to come back from the FIPS certification lab, the hackers will be busy extracting another 143 million credit histories, or another 4.1 million SF-86 Security Clearance Forms from the systems involved. :-)
You might say that FIPS certification != FIPS compliance. Sure, but the only silly people who care about FIPS compliance also need FIPS certification, for the US Goverment signoff.
Realistically, people who need FIPS certification will need to use FIPS certified crypto in hardware. In which case the FIPS certified RNG, as well as the FIPS certified crypto, will all be in a single certified lump of hardware, which doesn't have to change when we need to fix various kernel bugs.
Cheers,
- Ted
Quoted 11 lines · Theodore Ts'o
Quoted 3 lines · Jason A. Donenfeld
Good luck with getting approval... While Ted and I have our differences like any two kernel developers, I really tend agree with him in his attitude about this FIPS silliness. ...
Let me add one more reason why FIPS compliance for the kernel is just ***stupid***. The way FIPS compliance works, you have to pay hundreds of thousands of dollars to a FIPS certification lab to certify a specific binary, complete with the exact build environment (compiler, binutils, etc.) used to build that kernel binary.
Quoted 6 lines
The moment you need to make a change --- say, to fix a critical zero-day security bug --- this breaks the FIPS certification, ...
You might say that FIPS certification != FIPS compliance. Sure, but the only silly people who care about FIPS compliance also need FIPS certification, for the US Goverment signoff.
I do not think it is just the US that matters here. If I understand Stefan correctly, one of his concerns is German (or EU?) gov't standards that are somehow related. I'm very hazy on details.
I emphatically agree with Ted on some points here. Making FIPS certification a goal for kernel development would be really dumb. Having multiple RNGs available & compile-time options to select among them also looks silly to me; we just need one good one.
On the other hand, I do not see why the driver should not use a FIPS-compliant PRNG where it can. This would make things easier for anyone who does seek certification. One of the big distro vendors? A gov't department or contractor that wants to use Linux? A corporation's sys admin or security reviewer? Stefan?
I cannot see much downside to this. Is the current PRNG more efficient? More easily maintained? Is it still the case that random(4) must use only hashes, not ciphers, to avoid restrictions under export laws?
Quoted 3 lines · Sandy Harris
On the other hand, I do not see why the driver should not
From my perspective, this discussion is over. I'll be carrying out
David's requested patchset changes and submitting it. If you'd like different cryptography, you'll have to find somebody else to do that work for you.
Quoted 6 lines · Sandy Harris
On the other hand, I do not see why the driver should not use a FIPS-compliant PRNG where it can. This would make things easier for anyone who does seek certification. One of the big distro vendors? A gov't department or contractor that wants to use Linux? A corporation's sys admin or security reviewer? Stefan?
First, making it easier for a sysadmin to seek certification is creating an attractive nuisance. That means that after said company sinks $100,000+ into getting a certification, they will be hesitant to take the kernel update to fix that zero-day bug, less it causes them to lose that certification.
Secondly, I've worked with a defense contractor wanting to use (and did use) Linux. Specifically, on the Zumwalt class destroyer, DD-21, although back when I worked on it was the DD(X) program. I can assure you the fact that /dev/random wasn't FIPS certified wasn't a problem with either Raytheon or the US Navy. Really. If you're really serious about crypto, and you do government work, it will be type 1 ciphers implemented in hardware, courtesy of the NSA.
So really. You can use Linux without getting FIPS certification. Lots of copies of Linux are used in the government already, without FIPS certification.
Quoted 4 lines
I cannot see much downside to this. Is the current PRNG more efficient? More easily maintained? Is it still the case that random(4) must use only hashes, not ciphers, to avoid restrictions under export laws?
Linux is now using a Chacha20 based random number generator, much like OpenBSD. It's stream cipher-based CSPRNG, which is much more efficient than a block cipher or HMAC based DRBG. Unfortunately, it's also not one of the types defined in NIST 800-90A rev 1.
- Ted