The "(maximum) length" words in OQS_SIG and OQS_KEM are misleading

[wangweij]

All fields for the lengths of secret keys, public keys, signatures, ciphertexts, and shared secrets in the OQS_SIG and OQS_KEM structs claim they are "The (maximum) length". However, except for the signature length, all of them should be the exact lengths. In fact, only the OQS_SIG_sign function has an out parameter to retrieve the length of the signature.

[cothan]

Hi @wangweij , I'm not sure that I understand your point.

The maximum length actually returns the length, designed for current and the future scheme that are variable in length, if it's variable in length, return the maximum length, otherwise return the exact length.

[wangweij]

Even if a key has a variable length, I don't know how to obtain it. The OQS_KEM_keypair(const OQS_KEM *kem, uint8_t *public_key, uint8_t *secret_key) function only accepts pre-allocating memory of public_key but does not provide any information on the actual length. Thus, although the key's length might vary in theory, this variability isn't practical within the program's context and users must always utilize the entire allocated array.

A variable length only makes sense if the function had been designed as

OQS_STATUS OQS_KEM_keypair(const OQS_KEM *kem, uint8_t *public_key, size_t *public_key_len, uint8_t *secret_key, size_t *secret_key_len);

[SWilson4]

None of the schemes in liboqs have variable-length keys, in theory or practice. As you note, variable-length keys wouldn't fit with the APIs. You can safely use those as exact lengths.

Even for signature schemes, the only ones with variable-length signatures are Falcon-{512,1024}.

[wangweij]

@SWilson4, thanks for the confirmation. Then, shall we remove the words from the header files?

[SWilson4]

@SWilson4, thanks for the confirmation. Then, shall we remove the words from the header files?

That seems reasonable to me. Please feel free to create a PR and tag me as a reviewer.