Wallet seed generation uses `Hc128Rng::from_entropy` instead of OsRng

[ckeshava]

Description

Seed generation for wallet keys uses rand_hc::Hc128Rng::from_entropy(). Although HC-128 is a recognized stream cipher seeded once from the OS, the idiomatic secure choice for wallet seeds is OsRng / ThreadRng, which reseed continuously. A one-time seed-expand design means that any compromise of the initial entropy snapshot exposes every subsequently generated wallet, and the code departs from what xrpl-py / xrpl.js use.

Location

• src/core/keypairs/mod.rs#L108-L109

Impact / Severity

Critical — Cryptographic-RNG selection. Compromise of the single initial entropy seed exposes every wallet generated during the process lifetime. Switch to OsRng (or a vetted reseeding CSPRNG) for all secret-material generation.

Adversarial Agent Notes

Verdict: ACCEPT. HC-128 is eSTREAM-portfolio and not broken, so the practical risk is moderate, but the choice is inconsistent with every other XRPL SDK. No demo test — RNG quality isn't testable in a unit test.

[satyakwok]

Fix submitted in #300.

The PR replaces rand_hc::Hc128Rng::from_entropy() with rand::rngs::OsRng, drops the rand_hc = "0.3.1" dependency from Cargo.toml (no other call sites), and removes the now-unused use rand::SeedableRng;. OsRng reads from the OS entropy pool on every call, so a one-time entropy-snapshot compromise no longer carries over to subsequent wallets.

The existing rand = "0.8.5" already has the getrandom feature enabled, so the new code works in both std and no_std modes without further dep changes.

Adds generate_seed_without_entropy_produces_distinct_outputs to pin the "two consecutive generate_seed(None, None) calls return different seeds" property — trivially true with OsRng but worth locking so a future RNG swap can't silently regress it.