Support for multi-part operations

[jacobprudhomme]

Hello Cryptoki team!

Is there any plan to add bindings for the multi-part operations (C_{Digest,Encrypt,Decrypt,Sign,Verify}{Init,Update,Final}) to the library?

If so, I already have some code written for the digest operations that I can contribute immediately. I would be happy to take on adding support for the others too.

Getting ahead of myself here, but in writing this, would it be preferred to keep the implementation as bare as possible to conform to the spec (i.e. letting the device return CKR_OPERATION_NOT_INITIALIZED if a user tries to call an update function without having first called an init one, essentially leaving it up to human error)? Or is there some benefit in having some form of internal state machine to a Session so that we don't allow users to call an update or final function if the corresponding init function has not been called, disallowing these kinds of errors at compile-time instead of runtime?

I'm not sure where to stand on this, as it makes for better developer experience, but also strays from the exact expected behaviour of these functions as defined in the spec, and obviates the need for certain errors.

[hug-dev]

Hello! Thanks for your issue!

No plan to add them and all contributions are welcome ⭐

I have a question first, what would be the advantage of doing a multiple-part operation as opposed to running a single-part with all the data? What would be the use-case for example?

Detecting sequence errors at compile time could be done if the Update function could only be callable on a specific type, returned by the Init I guess? I am thinking, even if there is a state machine in the Session, the state would have to be checked at run time right?

I think personally it's fine for a first implementation to let the user mess up and we can improve later on 😄

[jacobprudhomme]

In our specific case, our goal is to have different swappable crypto backends for a library we're writing, and so really it's just a matter of being able to provide all of the same functionality with the PKCS#11 backend as with the other ones, which includes multi-part hashing. Admittedly, I'm not sure what the original goal was with providing that API in the library, though. That was a decision made before my time.

Re: the implementation: Yeah, not sure how I would do that without adding a generic type parameter to Session itself, which seems like far too breaking a refactor. I'll leave the fancy stuff for another time 😄

[wiktor-k]

Or is there some benefit in having some form of internal state machine to a Session so that we don't allow users to call an update or final function if the corresponding init function has not been called, disallowing these kinds of errors at compile-time instead of runtime?

An alternative is to have the init_encrypt function return a struct (say EncryptOp) and would take a &mut self of Session. The EncryptOp would have an update function (with &self so it can be called multiple times) and a final function that'd consume the struct (self). This way it would be impossible to execute functions in wrong order or interleaved.

Note that I haven't verified that in code 😅 but if there are problems I'm happy to dig in and create a PoC.

[jacobprudhomme]

Smart idea! Like a builder-style pattern?

I just opened a PR for the basic implementation (#252) now which is already quite large (though it's mainly just repetitive simple changes). So maybe it's best to wait for that one to be merged in first, instead of adding these changes on top