fix(keypairs): use OsRng directly for seed entropy (#286)#300
Open
satyakwok wants to merge 1 commit into
Open
Conversation
`generate_seed` was seeding an `Hc128Rng` stream cipher from the OS once per call, then filling the seed buffer from that cipher's keystream. HC-128 is a recognised eSTREAM-portfolio cipher, but the choice means a single compromise of the initial entropy snapshot inside the process exposes every wallet generated during the process lifetime — and it departs from what xrpl-py and xrpl.js use for secret-material generation. Replace `rand_hc::Hc128Rng::from_entropy()` with `rand::rngs::OsRng`, which reads from the OS entropy pool on each call. Drop the `rand_hc = "0.3.1"` dependency from `Cargo.toml` (it had no other call sites) and remove the now-unused `use rand::SeedableRng;`. Adds `generate_seed_without_entropy_produces_distinct_outputs` — pins the property that two consecutive `generate_seed(None, None)` calls return different seeds. Trivially true with `OsRng` but worth locking so any future RNG swap is forced to preserve it. The existing `generate_seed(Some(TEST_BYTES), ...)` deterministic-path tests are unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #286.
Summary
generate_seedwas seeding anHc128Rngstream cipher from the OS once per call, then filling the seed buffer from that cipher's keystream:HC-128 is a recognised eSTREAM-portfolio cipher, but the choice means a single compromise of the initial entropy snapshot inside the process can expose every wallet generated during that process lifetime — and it departs from what xrpl-py and xrpl.js use.
This PR replaces the call with
rand::rngs::OsRng, which reads from the OS entropy pool on every call:Also:
rand_hc = "0.3.1"dependency fromCargo.toml— no other call sites.use rand::SeedableRng;.rand = "0.8.5"already has thegetrandomfeature enabled, soOsRngworks in bothstdandno_stdmodes.Tests
Adds
generate_seed_without_entropy_produces_distinct_outputs— pins the property that two consecutivegenerate_seed(None, None)calls return different seeds. Trivially true withOsRngbut worth locking so any future RNG swap is forced to preserve it.The existing deterministic-path tests (
generate_seed(Some(TEST_BYTES), ...)) are unchanged and still pass.Smoke gate
cargo build✓cargo build --no-default-features --features embassy-rt,core,utils,wallet,models,helpers,websocket,json-rpc✓ (no_std mode)cargo test --lib -- --skip asynch::— 587 passed, 0 failedasynch::*tests that hit live XRPL testnet endpoints are skipped here; they're network-flaky and unrelated to this change.