extended api for allow use fixed seed for generate key pair and generate public key from private key in Signature schemes

[mraksoll4]

extended api for allow use fixed seed for generate key pair and generate public key from private key in Signature schemes

in this case we pass the seed as a parame.

OQS_SIG_keypair_from_fseed(const OQS_SIG *sig, uint8_t *public_key, uint8_t *secret_key, const uint8_t *seed);

in this case we pass the private key as a param.

OQS_SIG_pubkey_from_privkey(const OQS_SIG *sig, uint8_t *public_key, const uint8_t *secret_key);

falcon and dilithium at this moment - all versions. But can be done for other algos to.

"issue #2030"

old pull request #2027 , recreated for with correct style.

• Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)? (If so, a version bump will be required from x.y.z to x.(y+1).0.)
• Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in fully supported downstream projects dependent on these, i.e., oqs-provider will also need to be ready for review and merge by the time this is merged.)

it's extended api , but not affect native support old functions.

[SWilson4]

I know this is a useful feature for a number of applications, but I am hesitant to add support for it to the liboqs API. Unlike the keygen, sign, and verify functions, the derivation functions don't have an interfact mandated by NIST, and this will mean lots of manual patching work on our part. I don't expect that this will be a significant issue for standardized / standards-track algorithms, but I can see it slowing down additions of new schemes (e.g., from the NIST signature on-ramp).

[baentsch]

I know this is a useful feature for a number of applications

What apps are we talking about here, @SWilson4 @mraksoll4 ? fwiw, oqsprovider just removed Dilithium, so it's a "don't care" there by now.

this will mean lots of manual patching work on our part

A very true concern, and already visible in this PR, consisting of a gazillion patches that I am not not exactly eager to review and definitely unwilling to maintain, let alone replicate across all algorithms.

I can see it slowing down additions of new schemes (e.g., from the NIST signature on-ramp).

Completely agree on this too: Algorithm-specific patching should only be a method of "last resort", say if there's a security issue that an upstream cannot or does not fix in a timely manner. Using it to alter the externally visible behaviour of many, let alone all, algorithm(s) with many separate, bespoke patches --even if doing basically the same thing-- does not seem like a long-term viable way forward: Such changes should come from the upstream and be driven by a standards body (such as NIST).

[SWilson4]

I know this is a useful feature for a number of applications

What apps are we talking about here, @SWilson4 @mraksoll4 ? fwiw, oqsprovider just removed Dilithium, so it's a "don't care" there by now.

I meant "application" in the sense of an application of cryptography, as opposed to an app. I was thinking mostly of "fancy crypto" (e.g., BIP32).

[mraksoll4]

In fact, we can make a stub for the API so that it works only in supported algorithms and does not litter others, I'm a little confused there. As for patches, the function is built on the basis of the basic key pair generator, we just accept the Seed parameter from the outside, just like in the case of opening a public key from a private one we use part if it for recontrctrun pubkey - for falcon example from f and g.

It seems that I succeeded in this, but the problem is with Falcon and other algorithms where there is no meta data from the supported functionality, although you can go the other way and use a template through checking the algorithm "name"

[mraksoll4]

I know this is a useful feature for a number of applications

What apps are we talking about here, @SWilson4 @mraksoll4 ? fwiw, oqsprovider just removed Dilithium, so it's a "don't care" there by now.

I meant "application" in the sense of an application of cryptography, as opposed to an app. I was thinking mostly of "fancy crypto" (e.g., BIP32).

For this to work, we also need to figure out how to securely "derive" public keys from public keys. In addition to the private key tree, there is often also a public key tree, which allows us to create a new public key and associate it with a private key without revealing the private key.