Sunday, February 6, 2022

RDSEED, Random & Entropy Security & Information protection : Kernel & Processor Development

RDSEED, Random & Entropy Security & Information protection : Kernel & Processor Development


Kernel Dev : To be fair flawing AES Filtered Seeds with Doping would be an answer for people that feel distrust for (As far as i am concerned "A Perfect Security HASH" RS)"random: use computational hash for entropy extraction"

To be fair flawing AES Filtered Seeds with Doping would be an answer for people that feel distrust for (As far as i am concerned "A Perfect Security HASH" RS)"random: use computational hash for entropy extraction"

But bear in mind that Rupert's Cross mixing does take at least 3 CPU Cycles if you do not use:

MMX/AVX 16Bit multiple line Byte Swapping.

And let's go deeper and Hash again ? 8 Cycles!

Performance is key, SiMD Crucial, Dopping? A Thought (Does this scare you? Yes)

Perfect operations is IO DeKeyed low priority CPU Process (GPU RAND's Exist read my post)

Rupert S https://science.n-helix.com

Sources :

https://science.n-helix.com/2022/02/interrupt-entropy.html 

https://science.n-helix.com/2018/12/rng.html

https://science.n-helix.com/2017/04/rng-and-random-web.html

https://science.n-helix.com/2021/11/monticarlo-workload-selector.html

https://science.n-helix.com/2020/06/cryptoseed.html

https://science.n-helix.com/2019/05/zombie-load.html

https://science.n-helix.com/2018/01/microprocessor-bug-meltdown.html

random: use computational hash for entropy extraction

*

On 2/5/22, Dominik Brodowski wrote:

> Why are we only using RDRAND here, and not RDSEED?

Simply because that's what was already used here; I didn't revisit the

old decision. It seems like any changes there should be made in a

separate patch with its own justification. If you think there's a good

rationale, feel free to send that.


Part of why these changes are so gradual is because much of random.c

isn't my code originally. Were it mine, I'd presumably know all my

various rationales and be able to rapidly think within them and

re-evaluate. But because that's not the case, I find that I'm spending

a lot of time trying to reconstruct the original rationales of its

authors. IOW, rather than saying, "I don't get this, must be bad," I'm

trying to do a little bit of archaeology to at least make sure I know

what I'm disagreeing with, if I even disagree at all. That's time

consuming in part, but also is part of doing things evolutionarily.


With regards to RDRAND vs RDSEED, just off the top of my head -- I'm

writing this email on my phone -- I think extract_entropy/extract_buf

used to be used as part of /dev/random's blocking stream, which

ostensibly could mean more frequent calls, once every 10 bytes IIRC.

Nowadays it's only called once every 5 minutes (per numa node), so

maybe RDSEED could make sense? Or maybe there are other reasons to

unearth, or none at all. We'll have to look and see.

Jason

*

*




Each Zip presents 8 x 1MB present 2048 x 4096KB HASH Object or if you probably like 8100+ Multi sorted HASH RAND Objects : 8 Way sorted & hashed : RS 2022-02-02

2 cypher Seed key random : Random Initiator : Linus' 50ee7529ec45 : RS


(Especially MIPS) getting that Router /dev/random 2 cypher Seed key random : Random Initiator : Linus' 50ee7529ec45

yes MIPS are used in routers & some phones!

the proposal is to utilize & day to 8 day pre seeding & Haveged cored monte-carlo workload selector & therefore provide for Mitigation on many fronts while improving performance

*RAND OP Ubuntu : https://manpages.ubuntu.com/manpages/trusty/man1/pollinate.1.html

https://pollinate.n-helix.com

https://science.n-helix.com/2021/11/monticarlo-workload-selector.html

https://science.n-helix.com/2021/11/parallel-execution.html

https://science.n-helix.com/2019/06/kernel.html

https://science.n-helix.com/2022/02/rdseed.html

https://is.gd/FastCRNG

"Alternative mitigation involves moving process-related information in the kernel into a process-local part of the kernel address space. A user-space attacker that can infer the content of its associated kernel page table can thus only read information about its own process. Switching between these kernel address spaces is done as part of the normal address space switch when a thread in a different process is scheduled and thus comes with no additional cost."

https://www.phoronix.com/scan.php?page=news_item&px=Specmelt-No-Cost-Research

"You're proposing a middle way here, which would be to
just call try_to_generate_entropy() (the "Linus Jitter Dance" code) if
!crng_ready() in /dev/urandom and getrandom(GRND_INSECURE)"

"The justification for always waiting for randomness and never
returning insecure randomness to userspace isn't so much about
simplifying the code -- this patch isn't very large anyway -- but
rather for simplifying userspace crypto footguns. After several
decades of endless user confusion, we'd finally be able to say, "use
any single one of our random interfaces and you'll be fine. They're
all the same. It doesn't matter.""

https://www.spinics.net/lists/linux-crypto/msg61415.html

No comments: