[Android Software/Hacking General [Developers Only]] mw86:
This article was linked on last page. It makes a good read but doesn't beyond a doubt prove that there is no benefit to keeping entropy pool full.

https://lwn.net/Articles/525459/

However simple a statement this was posted there as a comment.

Posted Dec 3, 2012 17:23 UTC (Mon) by Kaejox (guest, #85586) [Link]

Some programs seem to drain entropy fast. Also starting a new process needs random numbers from kernel pool. Your can watch how much is available at /proc/sys/kernel/random/entropy_avail

I find this true. Using this app here

https://play.google.com/store/apps/details?id=com.promethylhosting.checkrandentropyavail

I see just that. I started it as soon as home screen starts and even with nonseeder and read_wakeup_threshold and randomize_va_space randomize_va_space adjusted entropy is draining often under many types of scenario it shouldn't. Its been stated wifo security should be only use of entropy. Its not just monitor and seem. At boot no wifi on i see numerous drops and raises on entropy. Scrolling tasks and launching new processes drain entropy. Thats why those of us trying tonsee the improvement are. Its not measurable so sorry allnof you asking for a bench as it will never be shown in a bench. So people see apps launch faster with it or the read_wakeup_threshold etc because processes get launched there is room for improvement with entropy not draining.

Another user put it well here.

"What it ultimately comes down to is the following: "if I can't have what I really want [unlimited entropy, instantly] what do I want to happen instead?" You have a few different options: potentially poor entropy, denial of service, etc., and you have to balance between them. The answer will frequently vary even between different usages in the same application.

However, the dearth of entropy on startup is a real problem unless you have a working HWRNG and applications really should take that into consideration."

Anyway taking this right from the main article id say there is a noted issue and we likely see more issues if apps are witten like the following says to not write apps.

"Guidelines for application writers

If you are writing applications that need to use a lot of randomness, you really want to use a cryptographic library such as OpenSSL, Peter said. Every cryptographic library has a component for dealing with random numbers. If you need just a little bit of randomness, then just use /dev/random or /dev/urandom. The difference between the two is how they behave when entropy is in short supply. Reads from /dev/random will block until further entropy is available. By contrast, reads from /dev/urandom will always immediately return data, but that data will degrade to a CSPRNG when entropy is exhausted. So, if you prefer that your application would fail rather than getting randomness that is not of the highest qualify, then use /dev/random. On the other hand, if you want to always be able to get a non-blocking stream of (possibly pseudo-) random data, then use /dev/urandom.

"Please conserve randomness!", Peter said. If you are running recent hardware that has a HWRNG, then there is a virtually unlimited supply of randomness. But, the majority of existing hardware does not have the benefit of a HWRNG. Don't use buffered I/O on /dev/random or /dev/urandom. The effect of performing a buffered read on one of these devices is to consume a large amount of the possibly limited entropy. For example, the C library stdio functions operate in buffered mode by default, and an initial read will consume 8192 bytes as the library fills its input buffer. A well written application should use non-buffered I/O and read only as much randomness as it needs.

Where possible, defer the extraction of randomness as late as possible in an application. For example, in a network server that needs randomness, it is preferable to defer extraction of that randomness until (say) the first client connect, rather extracting the randomness when the server starts. The problem is that most servers start early in the boot process, and at that point, there may be little entropy available, and many applications may be fighting to obtain some randomness. If the randomness is being extracted from /dev/urandom, then the effect will be that the randomness may degrade for a CSPRNG stream. If the randomness is being extracted from /dev/random, then reads will block until the system has generated enough entropy."

Enough with prove it or disprove it posts.

It all needs research.

A users post recent in thread makes the most sence. Those seeing benefit have lag issues from i/o, gpu/ui and processes starting all draining entropy too fast.

GS3 L710 4.2.1 AOSP Kt747 2.1Ghz ROW/Ktoonservative *Tapatalk

---------- Post added at 05:35 PM ---------- Previous post was at 05:24 PM ----------

This is who i meant. This explanation makes the most sense. How does it not make sense? This above is the going theory. I see this happening on my setup.

GS3 L710 4.2.1 AOSP Kt747 2.1Ghz ROW/Ktoonservative *Tapatalk