Batch operations to enable use of multi-buffer libraries on the host?

[stevedoyle]

The current wasi-crypto API definition allows operations to be performed one at a time. There are also "multi-buffer" techniques (e.g. Intel Multi-buffer Cryptography Functions) that leverage SIMD instructions to provide a performance benefit by operating on multiple requests in parallel.

What is the best way to enable these multi-buffer techniques for use with wasi-crypto?

One idea is to add some "batch" API functions to wasi-crypto to supply multiple operations to the host via a single host call. For example: signature_state_sign_many(). This seems to fit reasonably well at the lower level wasi-crypto interface but may break some of the higher level API abstractions. For example, adding a batch signing API to a keypair doesn't really add as much value as being able to perform a batch of signatures using different keypairs.

An alternative idea could be to push the batching down into the host and have an async API at the wasi-crypto level. But this likely requires promises / futures which don't appear to be supported for WASI at the moment.

Thoughts?

[jedisct1]

Hi Steve,

That's a very good point. Not just for asymmetric operations, btw. Batch operations are also useful for hashes and ciphers (most notably Keccak-based constructions).

Introducing new functions seems like the easiest to implement. Even with Promises, that would require different versions of the functions, as WASI's async model is unfortunately not colorblind.

Maybe a good starting point would be to sketch what all these functions would look like, to see how many we actually need, what they might break, and what could be nasty to implement.

I'm wondering if batch functions couldn't be in their own namespace/module (batch_signature_state_sign()), so that it would be an optional extension to the base API.

[stevedoyle]

I agree, the scope should include symmetric crypto also.

Making them an optional extension via their own namespace/module and new functions is a good idea.

I can sketch a version of what these would look like and post for feedback.

[stevedoyle]

An initial filter of the existing functions that could benefit from a batch variant:

• signature_state_sign
• signature_verification_state_verify
• symmetric_state_squeeze
• symmetric_state_squeeze_tag
• symmetric_state_encrypt
• symmetric_state_encrypt_detached
• symmetric_state_decrypt
• symmetric_state_decrypt_detached

This is based on the following proposed criteria:

• Able to leverage existing multi-buffer operations / libraries.
• Operations that take a long time to process and items in the batch could be processed in parallel by the runtime.
• "Data path" operations rather than setup/tear down operations. Rationale: They are more critical from a performance perspective.

Feedback?

[jedisct1]

Hi Steve,

That looks really good!

We need to clarify what happens/what errors get returned when batches are inconsistent, for example when algorithms don't match.

Waiting a bit for possible feedback from others, but LGTM.

[stevedoyle]

Updated PR#88 with error handling details and added batch api details for symmetric_state_squeeze operations.