Getting More Entropy in Java on Linux

Mar 21, 2014

Setting entropy pool for Java server on linux is fair simple. Just add a system property to specify a device to read from.

Blocking, but more Secure

This is secure but may block your application until enough entropy is available.

When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

Non-Blocking But Less Secure

A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current non-classified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.

If solution not working then take a look at workaround:

How to get more entropy

  1. Involve an audio entropy daemon like AED to gather noise from your datacenter with an open microphone, maybe combine it with a webcam noise collector like VED. Other sources are talking about “Cryptographic Randomness from Air Turbulence in Disk devices“.
  2. Use the Entropy Gathering Daemon to collect weaker entropy from randomness of userspace programs.
  3. Have a look at haveged (collecting good entropy on basis of CPU clock flutter)
  4. Consider installing a couple of parrots or canary next to your server.


See Also

Video: Scalable Memory Allocation using jemalloc Tech Talk (1/11/2011)

Video: Scalable Memory Allocation using jemalloc - Tech Talk (1/11/2011) jemalloc project:


Chronicle by Peter Lawrey: This library is an ultra low latency, high throughput, persisted, messaging and event driven in memory database. The typical latency is as low as 80 nano-seconds and supports throughput of 5-20 million messages/record updates per second. This library also supports distributed, durable, observable collections (Map, List, Set) The performance depends on the data structures used, but simple data structures can achieve throughput of 5 million elements or key/value pairs in batches (eg addAll or putAll) and 500K elements or key/values per second when added/updated/removed individually.

JVM Profiling Mode

There is no sense to run profiler in instrumentation mode on a high load. Instead of using instrumentation you should use sampling mode. This article describes the difference between instrumentation and sampling modes. JVisualVM is a good free tool for this task.

logo   Never miss a story, subscribe to our newsletter