Use secure memory not for verification operation

[falko-strenzke]

For signature schemes we should find a way to restrict the usage of secure (non-swapable) memory to the key generation and the private (signing) operation. For this purpose, we might hand to each function that needs to allocate memory a pointer to an allocation function. I think this would be the best solution. The reason is that we assume that a hash is signed (and not the message directly, in which case it would have to be treated as a secret).

ML-KEM should use secure memory also in the encapsulation operation, as the message is a secret.

@TJ-91

[TJ-91]

I agree - it should be easy to implement. For Dilithium, this only affects one function _gcry_dilithium_polyvec_create and it's only called directly from the main keygen/sign/verify procedures and passing a bool is sufficient for handling that single case.

Currently, many buffers are also allocated on the stack. Is there a reason to make the allocation dynamic? Or asked differently, what could we define as a criteria whether to dynamically or statically allocate?
If we do more dynamic allocation, a more generic approach with the pointer to an allocation function might be worthwhile to consider

[falko-strenzke]

Currently, many buffers are also allocated on the stack. Is there a reason to make the allocation dynamic? Or asked differently, what could we define as a criteria whether to dynamically or statically allocate?

The difference is that stack allocations will never be secure allocations – except is the whole stack was locked, which will consume unnecessarily much locked memory. In any case libgcrypt does not support this, and it would be complicated to implement also.

[falko-strenzke]

If we do more dynamic allocation, a more generic approach with the pointer to an allocation function might be worthwhile to consider

If we make generic with a pointer to an allocation function, we would also have to provide a deallocation function. Providing only a flag indicating either "secure" or "non-secure" allocations, then in both cases xfree() can be used for deallocation. After considering again, I think the function pointer is indeed the better solution, and as long as only the appropriate allocation functions are used xfree() can remain hard-coded.

[TJ-91]

Why did you change "public operations" to "signing operation"? Shouldn't it have been correct before?

I think that the function pointer for the allocation function sounds reasonable. It can even be set in the context struct that we already pass around (in the high level sign/verify/keygen operation), however, then the naming "param" is a bit misleading and it should then be called gcry_<algorithm>_ctx_t or something.

Perhaps we should pass a struct around that is built like this:

typdef struct {
  gcry_<algorithm>_param_t param;
  void (*alloc_func)(size_t);
} gcry_<algorithm>_ctx_t;

[falko-strenzke]

Why did you change "public operations" to "signing operation"? Shouldn't it have been correct before?

Because for KEM there is a secret involved in the encryption operation: the secret key.

I think that the function pointer for the allocation function sounds reasonable. It can even be set in the context struct that we already pass around (in the high level sign/verify/keygen operation), however, then the naming "param" is a bit misleading and it should then be called gcry_<algorithm>_ctx_t or something.

Perhaps we should pass a struct around that is built like this:

typdef struct {
  gcry_<algorithm>_param_t param;
  void (*alloc_func)(size_t);
} gcry_<algorithm>_ctx_t;

Looks reasonable to me.

[TJ-91]

Because for KEM there is a secret involved in the encryption operation: the secret key.

Ah, I see. So we can only use non-secure memory in the ML/SLH-DSA verification call and for ML-KEM not at all.