Other updates on the CL signature scheme #14
Conversation
- Created another type to match 128 bits of security.(CL03_CL3072_SHA256) - Replaced Mersenne Twister in Keys since it's not cryptographically secure (now we use ChaCha20 PRNG with a random seed from thread_rng, both cryptographically secure). - Created new tests specific for CL key generation. - Added a parameter to CLCiphersuite, QSEC, to be able to match needed security according to NIST FIPS 186-4 (DSA & RSA KeyGen). Now, iterations are dynamic depending on the security parameter. Fixed code to match the "deps - 24" iterations specification in Integer.is_probably_secure. - Changed the order of some instructions to have better readability on the code. - (Change not pushed, but in my version the tests fail on keypair_shake256 and keypair_sha256. Filenames are to be fixed)
AleCla97
left a comment
AleCla97
left a comment
There was a problem hiding this comment.
Thank you very much @alebldn for your contribution, it is always appreciated!!
I tested it and it passes all the tests too, the key test was fixed in a later version than yours. The PNRG change was also done in a later version but if you consider it insufficient I can merge yours. The rest all perfect, I will release this pull request in a new minor release 0.5
…Table C1). - Made CommitmentPublicKey implement traits that are common to other keys and necessary for serde handling.
|
Thanks @AleCla97 for your positive feedback! I've given a look at your code at 79c5f24 and I must admit it's pretty close to what I had been doing initially. Unfortunately, my code failed to compile since ThreadRng is not thread safe (as it does not implement the Send + Sync traits), so I decided to shift towards a fully thread safe RNG, being ChaCha20PRNG in crate rand_chacha. If your code does work, I'm fine either way. Thanks for asking anyway! In any case, I figured there were a few more changes I would've liked to introduce, namely the introduction of the final ciphersuite CL2048, and the possibility to serialize/deserialize CommitmentPublicKey. This last change was basically an adaptation of the CommitmentPublicKey to CLSecretKey and CLPublicKey which both implement Serialize and Deserialize trait. Once again, I've tested everything multiple times before committing and pushing but I still invite you to do the same. Unfortunately, I didn't really achieve more efficiency in generating CL Keypairs but I think overall this pull request might be an improvement. Let me know if I can help in any way, and thanks for your kindness!
|
|
@alebldn thank you again for your contribution!! |
2 participants
Hi again! I changed a few things in the CL side of the library:
Before committing and pushing, I ran all the tests, both in BBS+ and CL and they all passed.
The only exception is that in my version of the code (which is relatively old), two of the tests in keys.rs have mismatched filename. I edited this change locally and did not push it since I did not want to touch the BBS+ side of the library.
I invite you to test the changes yourself!
Thanks for your library, have a good one.