-
Notifications
You must be signed in to change notification settings - Fork 484
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exendend api and modification for allow generate keypair from fixed seed for some sig algos. #2027
Exendend api and modification for allow generate keypair from fixed seed for some sig algos. #2027
Conversation
Thanks for sharing your activities, @mraksoll4 -- please do check our contribution guidance, particularly heeding guidance on upstream code as you are modifying here, though. Finally, please mark this PR Ready for Review only when indeed everything is ready for review (incl. patches and tests). If you'd like to discuss the approach taken, it may be better to open an issue or discussion item to discuss the problem before doing a PR. On the topic, please be sure to also take a look at pre-existing issues like #1206... |
well, it's still far from a full-fledged solution (although these functions work as expected and are mostly built from existing ones), later I'll fix everything in the right style, although the commits are not signed at need style so what i need do ? recrate PR at rigt style or i can some how modify this exist PR, I was created an issue alrady , but it was closed because the necessary functionality did not exist so i created it. The most difficult thing is still planned - implementing something similar to the logic of hmac, I don't know yet if it is possible at all, we have no problems with private keys, it is quite easy to organize a key tree from them, but the ability to get a new public key from the master public key with no decrease seccurity is questionable |
…seed for some sig algos. Exendend api and modifications for allow generate keypair from fixed seed for some sig algos. Supported algos all variants of Dilithium all variants of Falcon Todo add testvectors. ( tested over python calls by hands for now.) Todo in process generarion from exported privat key public key and sign with it. OQS_SIG_keypair_from_fseed(const OQS_SIG *sig, uint8_t *public_key, uint8_t *secret_key, const uint8_t *seed); expect seed at args. ( 48 bit string for Falcon and 32 bit string for Dilithium) Signed-off-by: mraksoll4 <[email protected]>
add support pubkey generation from privkey falcon Signed-off-by: mraksoll4 <[email protected]>
correcting comments Signed-off-by: mraksoll4 <[email protected]>
add suport public key generation from private key dilithium2 - 5 Signed-off-by: mraksoll4 <[email protected]>
c26528a
to
e72bd9e
Compare
@ryjones could help with that.
Can you please point to that? Maybe re-open or rather, create a new one with a design proposal so you can get feedback on that before doing a PR? |
yes i think i simple create new PR for do it more clear + make separate patches for every algo, how i understand patches need do only for algo changes, and every variant of algo as exanple falcon512 and falcon1024 need separate pacth. |
PR is recreated with patches etc.. |
Exendend api and modification for allow generate keypair from fixed seed for some sig algos.
suporeted now .
all variants of Dilithium
all variants of Falcon
Todo add testvectors. ( tested over python calls by hands for now.)
Todo add dirrect generation public key from private key. (done)
OQS_SIG_keypair_from_fseed(const OQS_SIG *sig, uint8_t *public_key, uint8_t *secret_key, const uint8_t *seed);
expect seed at args. ( 48 byte string for Falcon and 32 byte string for Dilithium)
need deep review . But seems it works as expected.