Closed jedisct1 closed 1 year ago
maybe there should be a separate group of functions for when the random data will be immediately sent to a key construction function (or similar) to avoid the need for the WASM application to remember to securely zero the random data after key construction?
Applications should probably not be allowed to create keys out of secret data they generated themselves.
For each type of key, the API can provide a generate()
function that returns a key handle.
And as proposed in the security design document, secret data related to these keys should be wiped when not in use any more.
But internally, the generate()
function still needs to access a random number generator.
Considering the random_get()
guarantees of the core WASI module, the crypto submodule should just reuse that.
How to access it from the submodule is an internal implementation detail.
But should applications be able to define their own RNG?
The only justification I can think of for allowing it is for having deterministic tests.
But if a deterministic RNG is needed, that can be an option for all functions generating random numbers, which would be less dangerous that a global setting.
The WASI crypto module requires the ability to generate random numbers.
In order to do so, WASI already provides
random_get()
, defined as a function that returnshigh-quality random data
, which can be read as suitable for generating secret keys (maybe something that should be explicitly stated).Note that there are plans for that function to be in its own module: https://github.com/WebAssembly/WASI/blob/master/phases/ephemeral/witx/wasi_ephemeral_random.witx
Shall the crypto module simply use that function?
Or can you see any reason why it should use something different, or provide more options?