RDSEED, Random & Entropy Security & Information protection : Kernel & Processor Development
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
*
(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
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
> 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
*
*
*RAND OP Ubuntu : https://manpages.ubuntu.com/manpages/trusty/man1/pollinate.1.html
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:
Post a Comment