lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAHpNFcMxWJHfjAbAX+5uLsd7LaK1Kfo2DArFMOeSMt1pkeFh2w@mail.gmail.com> Date: Tue, 29 Mar 2022 03:16:55 +0100 From: Duke Abbaddon <duke.abbaddon@...il.com> To: torvalds@...ux-foundation.org Subject: Dev/Random : 4096-bit LFSR used for entropy collection : Submission 118 Dev/Random : 4096-bit LFSR used for entropy collection Basically the HASH is what makes a difference, In respect to BLAKE2 running out of entropy... An internal backup PKI AES/Blake2 Secondary HASH stored in Kernel... Bear in mind that the backup seed is worked from quality Random & is 99% unique : "We are The 99%" This keeps simple Pseudo numbers from being the bearer of predictable kernel Security behavior, Nothing wrong with keeping more! & we can for system device pools for example! For reference core HASH reserve storage can be per type: Main groups for Secondary hash main leaf HASH: /Dev /Memory /Storage /Keys /Con Rupert S *RAND OP Ubuntu : https://manpages.ubuntu.com/manpages/trusty/man1/pollinate.1.html https://pollinate.n-helix.com https://science.n-helix.com/2018/12/rng.html https://science.n-helix.com/2022/02/rdseed.html https://science.n-helix.com/2017/04/rng-and-random-web.html https://science.n-helix.com/2022/02/interrupt-entropy.html https://science.n-helix.com/2021/11/monticarlo-workload-selector.html https://science.n-helix.com/2022/03/security-aspect-leaf-hash-identifiers.html Audio, Visual & Bluetooth & Headset & mobile developments only go so far: https://science.n-helix.com/2022/02/visual-acuity-of-eye-replacements.html https://science.n-helix.com/2022/03/ice-ssrtp.html https://science.n-helix.com/2021/11/ihmtes.html https://science.n-helix.com/2021/10/eccd-vr-3datmos-enhanced-codec.html https://science.n-helix.com/2021/11/wave-focus-anc.html https://science.n-helix.com/2021/12/3d-audio-plugin.html https://aka.ms/win10rng "https://www.spinics.net/lists/stable/msg543787.html From: "Jason A. Donenfeld" <Jason@...xxxxxx> [ Upstream commit 6e8ec2552c7d13991148e551e3325a624d73fac6 ] The current 4096-bit LFSR used for entropy collection had a few desirable attributes for the context in which it was created. For example, the state was huge, which meant that /dev/random would be able to output quite a bit of accumulated entropy before blocking. It was also, in its time, quite fast at accumulating entropy byte-by-byte, which matters given the varying contexts in which mix_pool_bytes() is called. And its diffusion was relatively high, which meant that changes would ripple across several words of state rather quickly. However, it also suffers from a few security vulnerabilities. In particular, inputs learned by an attacker can be undone, but moreover, if the state of the pool leaks, its contents can be controlled and entirely zeroed out. I've demonstrated this attack with this SMT2 script, <https://xn--4db.cc/5o9xO8pb>, which Boolector/CaDiCal solves in a matter of seconds on a single core of my laptop, resulting in little proof of concept C demonstrators such as <https://xn--4db.cc/jCkvvIaH/c>. For basically all recent formal models of RNGs, these attacks represent a significant cryptographic flaw. But how does this manifest practically? If an attacker has access to the system to such a degree that he can learn the internal state of the RNG, arguably there are other lower hanging vulnerabilities -- side-channel, infoleak, or otherwise -- that might have higher priority. On the other hand, seed files are frequently used on systems that have a hard time generating much entropy on their own, and these seed files, being files, often leak or are duplicated and distributed accidentally, or are even seeded over the Internet intentionally, where their contents might be recorded or tampered with. Seen this way, an otherwise quasi-implausible vulnerability is a bit more practical than initially thought. Another aspect of the current mix_pool_bytes() function is that, while its performance was arguably competitive for the time in which it was created, it's no longer considered so. This patch improves performance significantly: on a high-end CPU, an i7-11850H, it improves performance of mix_pool_bytes() by 225%, and on a low-end CPU, a Cortex-A7, it improves performance by 103%. This commit replaces the LFSR of mix_pool_bytes() with a straight- forward cryptographic hash function, BLAKE2s, which is already in use for pool extraction. Universal hashing with a secret seed was considered too, something along the lines of <https://eprint.iacr.org/2013/338>, but the requirement for a secret seed makes for a chicken & egg problem. Instead we go with a formally proven scheme using a computational hash function, described in sections 5.1, 6.4, and B.1.8 of <https://eprint.iacr.org/2019/198>."
Powered by blists - more mailing lists