Sufficient entropy during initialization. I added one more test in 3.3.1 which demonstrates the providing of * To clarify the question whether sufficient entropy is present during boot * Addition of a SystemTap script to test add_input_randomness
#Logicworks 5.6 update
* Update documentation and testing in to cover the updates * Addition of processing of add_input_randomness as suggested by Ted * Removal of the Jitter RNG fast noise source as requested by Ted * add per NUMA node secondary DRBGs as suggested by Andi Kleen - theĮxplanation of how the logic works is given in section 2.1.1 of myĭocumentation, especially how the initial seeding is performed. Machek - it uses ideas from the add_interrupt_randomness of the legacy * Add handling logic for systems without high-res timer as suggested by Pavel * Do not mix in struck IRQ measurements as requested by Pavel Machek * Add missing \n as suggested by Joe Perches * Convert debug printk to pr_debug as suggested by Joe Perches This boundary covers all currently existing cipher implementations. * Align all buffers that are processed by the kernel crypto API to an 8 byteīoundary. * Add boot time entropy tests discussed in section 3.4.3. * Use kmalloc_node for the per-NUMA node secondary DRBGs. The interrupt estimates can be changed arbitrarily at compile time. Not have a high-resolution timer, apply 1/10th bit of entropy per interrupt. * Entropy estimate: one bit of entropy per interrupt. * Addition of the example defines for a CTR DRBG with AES128 which can be a SHA256 Hash DRBG implies the use of SHA-256, an AES256 The pre-defined hashes are the same as used for * The reading of the entropy pool is performed with a hash. Primitive polynomials for other entropy pool sizes are offered in the code. Whose taps are not too close to the location the current byte is mixed in. The LFSR is based on a primitive and irreducible polynomial * Use classical twisted LFSR approach to collect entropic data as requested by Of the LRNG.The ChaCha20 RNG is described in. * add ChaCha20 DRNG: in case the kernel crypto API is not compiled, the ChaCha20ĭRNG with the SHA-1 C implementations are used to drive the cryptographic part * add security strength to /proc/sys/kernel/random/lrng_type * use DRBG security strengths as defined in SP800-57 section 5.6.1 When using aįake NUMA system with 4 nodes on 4 CPUs, I still get up to 430 MB/s read speed * use CTR DRBG with AES256 as default due to its superior speed - on X86_64Įxecuting within a KVM I get read speeds of up to 850 MB/s now.
* fix treating LRNG_POOL_SIZE_BITS as entropy value in lrng_get_pool * inject current time into primary DRBG at the time of seeding from noise Runs low because of /dev/urandom reseeds, the entropy provider is woken up) Will benefit from the wake up as well (i.e. * move wakeup call of entropy-providers to a code location where /dev/urandom * simplify the interrupt to entropy amount conversion code
#Logicworks 5.6 64 bits
* set read wakeup threshold to 64 bits to comply with legacy /dev/random * prevent fast noise sources from dominating slow noise sources * use of min3 in lrng_get_pool to beautify code * add missing memzero_explicit to ChaCha20 DRNG Furthermore, includes aĬomparison with RNG design suggestions such as SP800-90B, SP800-90C, and The design and implementation is driven by a set of goals described in Finally massive performance improvements are visible at /dev/urandom Also, all steps of the entropic data processing are
A secondary design goal is to limit the impact of the entropyĬollection on massive parallel systems and also allow the use acceleratedĬryptographic primitives. Sufficient entropy during boot time as well as in virtual environments and when The main improvements compared to the legacy /dev/random is to provide
#Logicworks 5.6 generator
I call Linux Random Number Generator (LRNG) to collect entropy within the Linux
#Logicworks 5.6 Patch
The following patch set provides a different approach to /dev/random which Peter Anvin", Joe Perches, Pavel Machek, George Spelvin, ,
0 kommentar(er)
