Is wasi-crypto deterministic?

[sunfishcode]

Since wasi-crypto stores things like private keys outside of the normal program state, is the entropy used for things like private keys fully encapsulated? And if so, does this mean that the wasi-crypto API is deterministic, aside from the set of supported algorithms in an implementation?

This would be an interesting property for users wanting fully deterministic execution.

To be sure, WASI will likely still want to have raw entropy-source APIs, but it would help users that want deterministic execution if they could disable it while letting users do crypto through wasi-crypto.

[jedisct1]

Hi Dan,

The wasi-crypto API doesn't allow applications to use a specific random number source.

Creating a key requires an algorithm identifier and optional parameters, but these intentionally don't include a seed or some RNG handle, for a couple reasons.

• To prevent misuse, such as badly seeded or non-cryptographically secure RNGs,
• To make it easier to implement on top of existing libraries that don't necessarily give control over entropy sources, or that generally don't guarantee determinism,
• To support keys generated by HSMs.

RNGs used for e.g. Monte Carlo simulation need different properties than RNGs needed for cryptography.

PCG, Xoroshiro, etc. are perfect algorithms for running simulations. But they should probably be part of an API that is distinct from wasi-crypto.

[jedisct1]

So, the wasi-crypto APIs cannot be deterministic, if only because key management can be delegated to HSMs.

But the random module can still provide an RNG, accessible via new functions, that the application can optionally seed in so that it is deterministic. It won't affect key creation via the crypto APIs, though.

[indolering]

PCG, Xoroshiro, etc. are perfect algorithms for running simulations. But they should probably be part of an API that is distinct from wasi-crypto.
...
But the random module can still provide an RNG, accessible via new functions, that the application can optionally seed in so that it is deterministic.

I did a review of random APIs a few years ago, but sadly never got around to writing something up. A few notes:

• Make sure that the random API is non-blocking, as there might not be enough entropy on first boot.
• Provide unrandom for instances when performance is a concern.
  • Because the output of non-CSRNG APIs are regularly misused (nonces, hash tables), chose a PRNG whose output is non-trivial to predict.
  • Because PRNG's with similar seeds will produce correlated outputs (see .NET Random), salt and hash user provided seeds using a secure hash function (SHA3(Math.tau ++ seed)).

IMHO, I don't believe Xoroshiro provides the best set of trade-offs. Probably some vectorized version of PCG.