fix(rust-client): replace `RandomCoin` with `ChaCha20Rng` by ricomateo · Pull Request #2414 · 0xMiden/rust-sdk

ricomateo · 2026-08-18T17:19:59Z

Replaces the usage of RandomCoin with ChaCha20Rng.
ClientBuilder::rng now requires the RNG to implement CryptoRng (i.e. RandomCoin is no longer accepted, since it is not a CryptoRng).
Added Client::secure_rng, a second RNG intended to be used to generate randomness for secret values.
Added a trybuild test asserting that ClientBuilder::rng rejects a FeltRng which is not a CryptoRng.

…aCha20Rng

…OS-seeded RNG

…ects a non-CryptoRng

…ures

juan518munoz

Looks good overall. What I still don't understand is why we are keeping rng and secure_rng separately, for what I see we could just get away with the new secure implementation in all places.

If I'm not mistaken, keeping a single rng would also make the trybuild test redundant.

juan518munoz · 2026-08-19T19:06:08Z

+    /// the field modulus, which keeps the result uniform over the field. The rejection
+    /// probability is about 2^-32.
+    pub fn draw_felt(rng: &mut impl rand::Rng) -> crate::Felt {
+        use rand::RngExt;


we should move the import outside this function

juan518munoz · 2026-08-19T19:12:41Z

+    /// Uses rejection sampling: [`Felt::new`](crate::Felt::new) rejects any `u64` at or beyond
+    /// the field modulus, which keeps the result uniform over the field. The rejection
+    /// probability is about 2^-32.
+    pub fn draw_felt(rng: &mut impl rand::Rng) -> crate::Felt {


Maybe this functions are better suited in a separate file, similar to how we do with utils.rs, we could add an rng.rs file.

juan518munoz · 2026-08-19T19:12:57Z

+    ///
+    /// Use this for note serial numbers when building notes from a plain [`rand`] generator, which
+    /// does not implement [`FeltRng`].
+    pub fn draw_word(rng: &mut impl rand::Rng) -> crate::Word {


Same as other comment

ricomateo · 2026-08-20T19:04:30Z

@juan518munoz thanks! all comments were addressed in this commit e3b4748.

What I still don't understand is why we are keeping rng and secure_rng separately, for what I see we could just get away with the new secure implementation in all places.

We keep both secure_rng and rng because rng may be a predictable RNG (since the caller can override it with ClientBuilder::rng, passing an RNG initialized with a small seed), which makes it unsafe, so a separate RNG (secure_rng) is used for account keys and transaction input encryption, as pointed out in this comment.

SantiagoPittella · 2026-08-21T15:20:13Z

+
+#[cfg(test)]
+mod tests {
+    /// Checks that [`ClientBuilder::rng`] rejects a generator that is not a `CryptoRng`.


this is already enforced by the compiler in the type system, we can remove this test IMO

SantiagoPittella · 2026-08-21T15:23:19Z

If we remove the test, then we should remove this file

juan518munoz

LGTM. Before merging this, it may be a good idea to create a branch on web-sdk that points to this branch, so we can assure there won't be any setbacks.

ricomateo · 2026-08-24T15:48:45Z

@juan518munoz I created a draft PR in the web-sdk pinning the rust-sdk dependency to this branch, to check this PR doesn't break the web client. It required some changes but the CI succeeds.

huitseeker

Thanks for taking this on. Replacing RandomCoin with a standard CryptoRng is the right direction.

I checked the web SDK compatibility PR to understand why the client accepts a seed. Account recovery already has a separate path: newWallet(initSeed) derives the account key and initialization seed, while importPublicAccountFromSeed repeats that derivation. This path does not need ClientBuilder::rng.

The seed passed to createClient has a wider effect. It controls the client's operational RNG and also derives the web keystore's signing RNG. That behavior is useful for repeatable tests, but it should not be available to a client that may submit live transactions.

I suggest keeping one Client::rng for every client operation and seeding it from the operating system in normal builds. Whole-client deterministic seeding can move to the testing feature or the mock client. Account recovery can keep its explicit account seed.

With that setup, I think this PR can remove the second RNG field and the public secure_rng() accessor. ClientRng::inner_mut() should also be limited to testing if production code has no need to replace the generator after construction.

That smaller implementation would keep the CryptoRng requirement and the ChaCha20Rng default. It would route the current secure_rng call sites through the one client RNG. The web SDK can then stop passing createClient(seed) into the production client builder while leaving newWallet(initSeed) unchanged.

Does this match the intended role of the client seed? If another production caller needs to inject its own CryptoRng, I may of course have missed something!

huitseeker · 2026-09-04T20:46:30Z

    }

-    /// Optionally provide a custom RNG.
+    /// Optionally provide a custom RNG for note serial numbers, script arguments and account


Requiring CryptoRng is a good step. Web account recovery already uses newWallet(initSeed), so could we keep recovery there and make this whole-client override test-only, unless there's another production use?

huitseeker · 2026-09-04T20:46:36Z

+    /// Returns a reference to the client's secure random number generator. This can be used to
+    /// generate randomness for secret values such as account keys, and the nonces that seal
+    /// transaction inputs.
+    pub fn secure_rng(&mut self) -> &mut ClientRng {


If whole-client overrides are limited to tests, every production operation can use the same OS-seeded RNG (and we would not need to return a mutable variant of it in those production paths.

nit: the name implies security, but that's contextual. Could we remove secure_rng() and keep a single Client::rng() instead?

huitseeker · 2026-09-04T20:46:42Z


 ### Breaking Changes

+* [BREAKING][removal][rust] Removed the `miden_client::crypto::RandomCoin` re-export. Use a `rand` CSPRNG such as `ChaCha20Rng`, plus the new `miden_client::crypto::draw_felt` / `draw_word` helpers where a `Felt` or `Word` is needed from a generator that does not implement `FeltRng` ([#2414](https://github.com/0xMiden/rust-sdk/pull/2414)).


The migration path here does not compile because both helpers live under miden_client::rng. Please change this to miden_client::rng::{draw_felt, draw_word} if the helpers remain public.

ricomateo added 12 commits August 18, 2026 14:19

fix(rust-client): require a CryptoRng in the client and default to Ch…

fb3cc74

…aCha20Rng

fix(rust-client): draw secret keys and input sealing from a separate …

e2f2ad1

…OS-seeded RNG

refactor(rust-client): remove RandomCoin in favor of ChaCha20Rng

42aea8b

refactor(rust-client): use explicit branching for the default RNG

98e77fd

docs(rust-client): correct which RNG covers account seeds

a69138b

docs(rust-client): fix broken intra-doc link in draw_felt

f2c72b7

chore: improve docs

4efc3f3

chore: improve changelog

2e5ebc7

chore: shorten doc comment

9e408fe

test(rust-client): add trybuild test asserting ClientBuilder::rng rej…

a440cdb

…ects a non-CryptoRng

chore: remove doc test

18cf8d9

chore(rust-client): silence the cargo-shear warning for trybuild fixt…

47b7d75

…ures

ricomateo marked this pull request as ready for review August 19, 2026 15:51

ricomateo requested review from SantiagoPittella, TomasArrachea, igamigo and juan518munoz August 19, 2026 15:51

ricomateo changed the title ~~fix(rust-client): replace RandomCoin~~ fix(rust-client): replace RandomCoin with ChaCha20Rng Aug 19, 2026

juan518munoz reviewed Aug 19, 2026

View reviewed changes

ricomateo added 2 commits August 20, 2026 15:41

Merge branch 'next' into replace-random-coin

35e647e

chore: move draw_felt and draw_word functions to rng.rs

e3b4748

chore: fix intra-doc link

b36b001

SantiagoPittella approved these changes Aug 21, 2026

View reviewed changes

juan518munoz approved these changes Aug 21, 2026

View reviewed changes

Merge branch 'next' into replace-random-coin

cd55c64

ricomateo mentioned this pull request Aug 24, 2026

chore: check the rust-sdk replace-random-coin does not break the web client 0xMiden/web-sdk#317

Closed

huitseeker reviewed Sep 5, 2026

View reviewed changes

chore: remove Client::secure_rng

8c636ca

Navigation Menu

Uh oh!

fix(rust-client): replace `RandomCoin` with `ChaCha20Rng` - #2414

fix(rust-client): replace `RandomCoin` with `ChaCha20Rng`#2414
ricomateo wants to merge 17 commits into
nextfrom
replace-random-coin

ricomateo commented Aug 18, 2026 •

edited

Loading

Uh oh!

juan518munoz left a comment

Uh oh!

juan518munoz Aug 19, 2026

Uh oh!

juan518munoz Aug 19, 2026

Uh oh!

juan518munoz Aug 19, 2026

Uh oh!

ricomateo commented Aug 20, 2026

Uh oh!

SantiagoPittella Aug 21, 2026

Uh oh!

SantiagoPittella Aug 21, 2026

Uh oh!

juan518munoz left a comment

Uh oh!

ricomateo commented Aug 24, 2026

Uh oh!

huitseeker left a comment

Uh oh!

huitseeker Sep 4, 2026

Uh oh!

huitseeker Sep 4, 2026

Uh oh!

huitseeker Sep 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants


		### Breaking Changes

		* [BREAKING][removal][rust] Removed the `miden_client::crypto::RandomCoin` re-export. Use a `rand` CSPRNG such as `ChaCha20Rng`, plus the new `miden_client::crypto::draw_felt` / `draw_word` helpers where a `Felt` or `Word` is needed from a generator that does not implement `FeltRng` ([#2414](https://github.com/0xMiden/rust-sdk/pull/2414)).

Uh oh!

Conversation

ricomateo commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

juan518munoz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ricomateo commented Aug 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

juan518munoz left a comment

Choose a reason for hiding this comment

Uh oh!

ricomateo commented Aug 24, 2026

Uh oh!

huitseeker left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ricomateo commented Aug 18, 2026 •

edited

Loading