Wasm, Contexts, and Entropy

[JeremyRubin]

does signing context generate entropy on creation? testing now but this may be a big issue for using verification from a WASM module with no entropy because the get random number methods may panic.

For manually generated contexts, this happens only if you randomize them explicitly, see

rust-secp256k1/src/lib.rs

Lines 354 to 380 in 48683d8

	/// (Re)randomizes the Secp256k1 context for cheap sidechannel resistance;
	/// see comment in libsecp256k1 commit d2275795f by Gregory Maxwell. Requires
	/// compilation with "rand" feature.
	#[cfg(any(test, feature = "rand"))]
	pub fn randomize<R: Rng + ?Sized>(&mut self, rng: &mut R) {
	let mut seed = [0u8; 32];
	rng.fill_bytes(&mut seed);
	self.seeded_randomize(&seed);
	}
	/// (Re)randomizes the Secp256k1 context for cheap sidechannel resistance given 32 bytes of
	/// cryptographically-secure random data;
	/// see comment in libsecp256k1 commit d2275795f by Gregory Maxwell.
	pub fn seeded_randomize(&mut self, seed: &[u8; 32]) {
	unsafe {
	let err = ffi::secp256k1_context_randomize(self.ctx, seed.as_c_ptr());
	// This function cannot fail; it has an error return for future-proofing.
	// We do not expose this error since it is impossible to hit, and we have
	// precedent for not exposing impossible errors (for example in
	// `PublicKey::from_secret_key` where it is impossible to create an invalid
	// secret key through the API.)
	// However, if this DOES fail, the result is potentially weaker side-channel
	// resistance, which is deadly and undetectable, so we take out the entire
	// thread to be on the safe side.
	assert_eq!(err, 1);
	}
	}

.

For the global context, it depends on the enabled feature: The global-context feature randomizes the context automatically and depends on rand, and the global-context-less-secure feature gives you a context that is not randomized (and can't be randomized).

Originally posted by @real-or-random in #342 (comment)

We should probably think through what it means to use any of these contexts in a WASM context! Especially in wasm32-unknown-unknown you have no syscalls or way of getting entropy, so this could be problematic.

Fully isolated WASM is really great to provide first-class support for for a myriad of reasons, but we'd need to think through carefully exactly what we do. Maybe we can detect if we're in wasm and disable some targets if we don't have symbols for getting entropy linked? Not sure :)

[real-or-random]

Hm, I don't think we should disable anything. This all depends on the threat model of the application and it's hard for a library to know this. (It's already hard for an application to make a guess about the threat model of the user...)

So randomization is defense in depth against timing attacks and it may provide some resistance against other side-channel attacks (electromagnetic -- but that's anyway hard). How much do you care about this in WASM? We can't tell as a library. Anyway, can WASM code even be made resistant against timing leaks? Apparently yes. So okay, without entropy, we lose defense in depth but there's no reason to believe that we lose security.

Especially in wasm32-unknown-unknown you have no syscalls or way of getting entropy, so this could be problematic.

You could try to hash your secrets at least. How do you get your secrets into WASM? (I mean you can't generate them in WASM without external entropy?)

edit: Please tell me if I seem to assume anything which is wrong. To be honest, I really have no idea how WASM works.

[elichai]

If you know your default implementation of getrandom either sucks or panics, then you should make your own global context (or use a local one) and randomize it using whatever randomness you do have (and you have to have some kind of randomness as you have a private key).

I'd rather we won't change anything in the context until bitcoin-core/secp256k1#988 is done and then we can rehaul our API

[apoelstra]

It is really unfortunate that rand methods would panic. This seems like an abuse of panic and I don't see any reasonable way we can detect it and recover.

Are there replacements for rand out there which are widely supported?

[TheBlueMatt]

This is the exact reason for global-context-less-secure - supporting environments where you can't get global randomness, especially WASM. In these environments there's probably nothing we can do better around global context, we have to hope people use their own local contexts and randomize them manually, if they want. A "better rand" here would still be one that just doesn't get any randomness.

[apoelstra]

Gotcha. So, in light of #388 (not sure if you've been following this) where we are moving toward removing global-context-less-secure and just using rand whenever it was available, I guess we can't do that, because rand sometimes unpreventably terminates the program from inside library functions.

So I guess we should keep global-context-less-secure, indicate in the docs that this is needed if you expect rand to misbehave, and we should gate the global context randomization on #[cfg(all(feature = "rand", not(feature = "global-context-less-secure"))].

[TheBlueMatt]

where we are moving toward removing global-context-less-secure and just using rand whenever it was available, I guess we can't do that, because rand sometimes unpreventably terminates the program from inside library functions.

I don't see why this is a problem? We just need to make sure we do not enable the rand feature/dependency unless the user does.

[JeremyRubin]

you can also test rand via https://doc.rust-lang.org/std/panic/fn.catch_unwind.html at runtime btw.

[TheBlueMatt]

That is std-only, sadly (not to mention very poor practice, IMO)

[apoelstra]

@TheBlueMatt we can't prevent parallel dependencies from enabling the rand feature ... I don't think we can reasonably say "this may break unless feature X is off"

[tcharding]

I don't think we need #385. Since we feature gate on "rand-std", and not on "rand", we do fully control the feature gating. If we were to use "rand" we would be at the mercy of other dependencies enabling "rand" as you say @apoelstra.

no-std users will not be enabling "rand-std" so they will not get the global context randomization and will not hit the rand panic issue, right?

[apoelstra]

Yeah, I think you're right. Ok.

[Kixunil]

Skipping over the details, would it be reasonable to provide a method for consumers to dynamically set a global randomization Fn? People could set it when initializing and not lose any security.