Allocation-free operations?

[bal-e]

I noticed that Session::sign(), and the alternative sign_init()/sign_update()/sign_final() methods, always perform heap allocations (sign() and sign_final() both return Vec). At least for my use case, I already know which cryptographic algorithm is being used, so I know exactly how big the resulting signature should be. I'd like to have non-allocating methods, where I can pass in a buffer of a pre-determined size, just for efficiency.

This concern probably extends to all the other PKCS#11 operations. If this feels like a worthwhile change, I'm happy to put up PRs (at least for a few interesting operations). But I wanted to check in before getting started.

[hug-dev]

Hello!

Yes that would be a good optimization for some use case! Good to leave the option to the user at least. What could be the name suffix of this set of functions? no_alloc?

Would be perfect to do it in a way where the alloc variant calls the non_alloc one to maximize code re-use :)

[bal-e]

How about:

• sign_into() / sign_final_into(): write into &mut impl Buffer (something to cover variable-sized buffers, such as Vec<u8> and [u8] which naturally has a maximum capacity), return a usize of how many bytes were added

• sign_into_fixed() / sign_final_into_fixed(): write into &mut [u8], fail if the underlying function writes writes fewer bytes into the buffer

Buffer can just be fn alloc(&mut self, size: usize) -> Result<&mut [u8]>, which will provide space for exactly the caller-specified size (which is learnt as the existing code today), or fail if that many bytes could not be allocated.

Then sign() is a simple wrapper around sign_into() which passes in a fresh Vec<u8>. sign_into() determines the right output size, uses Buffer::alloc() to get that many bytes, and calls sign_into_fixed() to do the actual signature generation.

[hug-dev]

Thanks for the proposal.
Would the second variant (into_fixed) be enough for now to cover your use case? If so I'd say we can start with that to make it nice and simple for now and then add the other one if it appears to be needed!

A good thing for this is a potential optimization in the number of PKCS11 call needed as (correct me if I am wrong) the into_fixed variant will only require one call to C_Sign.

[bal-e]

Yeah, that's fair :)

Yes, into_fixed requires fewer PKCS#11 calls!

[bal-e]

Oh! I just realized that RSA signatures can be variable-sized (but an upper bound can be determined from the public key). I think I will implement the _into() variants, taking just &mut [u8] for now.