Supported algorithms

[ueno]

It would be useful if there is a function that retrieves "meta" information of supported algorithms, or at minimum, a function that checks whether a given algorithm is supported.

[jedisct1]

Do we want algorithms to be specified as strings, or using constants?

Do we want to also be able to know what parameters are supported for a given algorithm?

Implementations of some algorithms intentionally restrict, or do not let applications choose key sizes, nonce sizes and other parameters in order to avoid unsafe choices.

[ueno]

Do we want algorithms to be specified as strings, or using constants?

I would say it doesn't make significant difference: both can be open-ended (with the int enum type in witx for constants), and we nevertheless would need to maintain the list of defined algorithms.

Do we want to also be able to know what parameters are supported for a given algorithm? Implementations of some algorithms intentionally restrict, or do not let applications choose key sizes, nonce sizes and other parameters in order to avoid unsafe choices.

In that case wouldn't it sufficient to use a different algorithm identifier?

[jedisct1]

I would say it doesn't make significant difference: both can be open-ended

Right. Identifiers would be marginally faster and more developer-friendly.

But strings have the major advantage of avoiding the IANA syndrom (e.g. /etc/services or /etc/protocols that every system copies around, but most entries are now completely useless).

[jedisct1]

In that case wouldn't it sufficient to use a different algorithm identifier?

Probably. Argon2ID-128 could be Argon2ID with the salt constrained to 128 bit.

[tniessen]

I think an important factor is: How do we manage the list of supported algorithms? Whether it's a list of strings or integers, we will need exact specifications for each algorithm.

[jedisct1]

Having an exhaustive list of algorithms and parameters is an impossible task.

However, what we can do is list a minimal set of algorithms+parameters that MUST be present in a wasi-crypto implementation, as well as what implementations MAY provide.

The MAY set is important in order to at least have a set of identifiers for common algorithms.

But the API shouldn't prevent custom identifiers, even though we need some convention in order to avoid collisions.

[tniessen]

I think we should go beyond just specifying the names. Often, there are multiple variants to perform the same algorithm, and standards such as WebCrypto have shown us some very "interesting" variants such as non-standard algorithm options, and unconventional signature / output encodings.

[jedisct1]

Good point.

Given an algorithm, we should be able to retrieve a set of key/value pairs describing what options, features and parameters supported.

What could the interface look like?

Maybe a sysctl-like interface, so that all this information can be accessed using a single function?

Can you possibly sketch something and see how some common and less common algorithms would fit into it?

[ueno]

I guess we will eventually have to maintain a document covering all the defined algorithms and their parameters as in PKCS#11 mechanisms specification. I'm not sure if it makes sense to provide such information from the API (or if it can be future proof).

[jedisct1]

One example I had in mind is the maximum degree of parallelism for a function such as k12, blake3 or argon2. This is runtime-dependent. But also not algorithm dependent, so that information can be provided by a more general API, that doesn't even have to be part of wasi-crypto.

You're right, maintaining a document covering all the defined algorithms and acceptable parameters is likely to be sufficient.