C_SeedRandom and C_GenerateRandom - minor issues

[johughes99]

Just doing some boundary tests for C_SeedRandom and C_GenerateRandom. I noticed that if you provide a zero length for the seed in C_SeedRandom or zero length for the RNG in C_GenerateRandom you get back CKR_OK. I was expecting CKR_ARGUMENTS_BAD.

Softhsm does correctly check for null pointers though.

[rijswijk]

Can you explain why you expected SoftHSM to return CKR_ARGUMENTS_BAD in case zero bytes are requested (or submitted in case of the seed)? As far as I'm aware, the PKCS #11 specification does not require this behaviour.

[johughes99]

The base PKCS#11 specification is actually silent on this subject. It mas my "interpretation" that it would silly to call these functions with zero lengths. Hence why I was checking for it. Just following the general principle of validating all input

[halderen]

IMO there is nothing really bad about having zero length seed and buffers. For seeding one could argu for a re-seed from hardware resource. Also there is a big argument for keeping it as is, is that current usages might break when changing this behavior. Either deliberate or not, they could e.g. check for availability of the functions. SoftHSM in these cases should be lenient rather than strict to be as useful as possibile.

[johughes99]

Totally understand the reasoning. Also when a token doesn't support seeding I guess it should report back either CKR_RANDOM_SEED_NOT_SUPPORTED or CKR_FUNCTION_NO_SUPPORTED