| View previous topic :: View next topic |
| Author |
Message |
jessetaylor84
n00b
Joined: 21 Sep 2014
Posts: 4
Location: Cascadia, USA
|
 Posted: Sun Sep 21, 2014 7:09 am Post subject: Will enabling PAX_LATENT_ENTROPY result in weak crypto? |
 |
|
Looking at the Gentoo Wiki article "PaX Quickstart", in the section on kernel configuration, I noticed that it says to set PAX_LATENT_ENTROPY=y
That is, in menuconfig:
| Code: | PaX --->
Miscellaneous hardening features --->
[...]
[*] Generate some entropy during boot |
The help description for this kernel configuration option reads as follows:
| Quote: | | By saying Y here the kernel will instrument some kernel code to extract some entropy from both original and artificially created program state. This will help especially embedded systems where there is little 'natural' source of entropy normally. The cost is some slowdown of the boot process and fork and irq processing. When pax_extra_latent_entropy is passed on the kernel command line, entropy will be extracted from up to the first 4GB of RAM while the runtime memory allocator is being initialized. This costs even more slowdown of the boot process. Note that the implementation requires a gcc with plugin support, i.e., gcc 4.5 or newer. You may need to install the supporting headers explicitly in addition to the normal gcc package. Note that entropy extracted this way is not cryptographically secure! |
... but then there is this, from the grsecurity website:
| Quote: | | Providing enough randomness, especially at early boot, has been a constant struggle for Linux. While on the Intel platform, Ivy Bridge and newer processor models that support RDRAND generally eliminate the problem of entropy starvation at early boot and runtime, older processors and those of other architectures continue to be plagued by this problem. The demonstrable effects of this include weak private keys on embedded systems, weak randomness on VM guests, predictable stack canaries, and more. PaX's latent entropy plugin included in grsecurity addresses the lack of randomness by modifying the instruction streams of functions called only during boot as well as some specific functions at runtime that perform some unpredictable computations from the perspective of an attacker. These functions are modified to produce a nondeterministic value based on the flow of execution. At several points in the boot process and at runtime, this pseudorandom value is mixed in to the entropy pool. Further, a kernel compiled with this plugin will have the various random pools in the kernel initialized at compile-time to random contents. |
... So the configuration help says that it's not cryptographically secure, but then their website documentation says that it's being mixed into the entropy pool ... Is this going to somehow weaken security for cryptographic applications that require random data from the entropy pool? |
|
| Back to top |
|
 |
N8Fear
Tux's lil' helper
Joined: 15 Apr 2013
Posts: 140
Location: Berlin (Germany)
|
| Posted: Sun Sep 21, 2014 12:10 pm Post subject: |
|
|
It actually strengthen the entropy ("randomness") at early boot. Later it is mostly newly "collected" entropy. What makes you think that it could be less secure?
Disclaimer: In theory anything can negatively impact entropy. It's all about trust anyways... |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 14379
|
| Posted: Sun Sep 21, 2014 3:09 pm Post subject: |
|
|
Based on the descriptions, the entropy provided by this plugin is not at a level where you should rely on it for long lived secret numbers if you have an alternative. On the other hand, by not using this option, you get an entropy pool that is even less random and even less suitable for long lived cryptography. You might think of it as the difference among using a glass door, a wooden door, or a heavy steel door. Obviously the steel door provides the best security, but in early boot, your choices are a glass door or a wooden door. The glass door can be beaten by anyone willing to break the glass with a heavy object. The wooden door requires an axe or a lockpick.
Disclaimer: my knowledge of this particular feature comes entirely from the posts in this thread. |
|
| Back to top |
|
|
jessetaylor84
n00b
Joined: 21 Sep 2014
Posts: 4
Location: Cascadia, USA
|
| Posted: Sun Sep 21, 2014 3:57 pm Post subject: |
|
|
| N8Fear wrote: | | What makes you think that it could be less secure? |
It was the the part in the documentation that said "Note that entropy extracted this way is not cryptographically secure!" ...
Last edited by jessetaylor84 on Sun Sep 21, 2014 4:03 pm; edited 1 time in total |
|
| Back to top |
|
|
jessetaylor84
n00b
Joined: 21 Sep 2014
Posts: 4
Location: Cascadia, USA
|
| Posted: Sun Sep 21, 2014 4:02 pm Post subject: |
|
|
| Hu wrote: | | Based on the descriptions, the entropy provided by this plugin is not at a level where you should rely on it for long lived secret numbers if you have an alternative. On the other hand, by not using this option, you get an entropy pool that is even less random and even less suitable for long lived cryptography. You might think of it as the difference among using a glass door, a wooden door, or a heavy steel door. Obviously the steel door provides the best security, but in early boot, your choices are a glass door or a wooden door. The glass door can be beaten by anyone willing to break the glass with a heavy object. The wooden door requires an axe or a lockpick. |
That makes sense, I suppose -- i.e. that it could be saying that ideally (if you had a high quality HW random # generator), you wouldn't want to use this plugin, but if you have no other alternative that this plugin is better than nothing.
Anyways, I'd be interested in hearing from someone who knows for sure that this is correct. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
