Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[wip] feat(kernel): use a sponge to generate nicer RNGs #334

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

hawkw
Copy link
Owner

@hawkw hawkw commented Oct 8, 2022

Per a suggestion from @hdevalence. This isn't done yet because...it turns out our current QEMU configuration doesn't expose RDRAND support to the guest, and I don't know if timestamp-based entropy added to the sponge at a fixed interval is a good idea...

image

Per a suggestion from @hdevalence. This isn't done yet because...it
turns out our current QEMU configuration doesn't expose RDRAND support
to the guest, and I don't know if timestamp-based entropy added to
the sponge at a fixed interval is a good idea...
@hawkw
Copy link
Owner Author

hawkw commented Oct 8, 2022

It would be nice to get this merged before implementing a /dev/random-like API for userspace, so that we can generate CSPRNGs nicely using the sponge...

@hawkw
Copy link
Owner Author

hawkw commented Oct 8, 2022

Suggestions from @hdevalence:

like there’s some kind of contortions to make like a fake RNG in order to use the merlin api or whatever
instead of doing that, you could just vendor the strobe implementation from the merlin crate
the code isn’t going to change
and then you can use the strobe state directly, and you can absorb the entropy in a way that provides forward secrecy
basically, when you’re ingesting new entropy, you want to be in K mode
so it overwrites rather than xoring

@hawkw
Copy link
Owner Author

hawkw commented Oct 8, 2022

from henry:

OK so here’s what i’d do
make a

struct MyceliumRng {
    inner: Strobe128
}

then have

MyceliumRng::new(seed: &[u8])
MyceliumRng::reseed(&mut self, data: &[u8])
MyceliumRng::fork(&mut self) -> MyceliumRng

impl RngCore for MyceliumRng
  • new should initialize the struct and then immediately reseed it with the data
  • reseed should do a strobe KEY operation with the provided data
  • the RngCore impl should use the PRF operation to fill bytes

the fork operation is a little tricky. you want to make sure that the two forks have different transcripts
because it has to be different regardless of the state of the world
i think you want to do something like, clone the existing state, then reseed both the existing and the cloned state with different data
eg [0] and [1]
this way, if i do .fork() a bunch of times, i can never accidentally get the same outputs, because the state is bound to a transcript of that instances path through the fork tree
remember it doesn’t need extra entropy, it just has to have different transcript data

the idea is that fork is like Clone but safe
ideally it would actually Be the Clone impl
but that’s not possible because you need to mutate both instances
and the reason you need to do that is so if you fork twice you don’t get two copies of “forked from X”

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant