DRBG: delay initialization of DRBG method until instantiation#11111
DRBG: delay initialization of DRBG method until instantiation#11111mspncp wants to merge 2 commits intoopenssl:masterfrom
Conversation
|
I note by the way that 11,111 is a product of 2 primes: 41 * 271 |
|
That's not enough for RSA, right? |
Not to do PKCS1 padding....not sure about "no padding". I think its safe to say I wouldn't trust my bank details with it. |
|
I'm tempted to (ab-)use this PR as a degenerate test case for the latest |
mspncp
changed the title
Sorry for spoiling your fun. I told you, it was only a placeholder for my next pull request ;-) |
What a shame, I was going to approve the empty list of commits since I was sure it was error-free 🤣 |
I don't think we'll be around when the next repunit prime is reached. |
mspncp
changed the title
mspncp
added
approval: review pending
providers/fips/self_test_kats.c
Outdated
There was a problem hiding this comment.
This looks like a NULL access of drbg?
There was a problem hiding this comment.
As Pauli already noted: it happens at compile time. So unless the compiler is buggy...
|
Should this be rebased after my PR goes in? |
|
Yes, that was the intention. |
mspncp
changed the title
Previously, the initialization was done immediately in RAND_DRBG_set(),
which is also called in RAND_DRBG_uninstantiate().
This made it difficult for the FIPS DRBG self test to verify that the
internal state had been zeroized, because it had the side effect that
the drbg->data structure was reinitialized immediately.
To solve the problem, RAND_DRBG_set() has been split in two parts
static int rand_drbg_set(RAND_DRBG *drbg, int type, unsigned int flags);
static int rand_drbg_init_method(RAND_DRBG *drbg);
and only the first part is called from RAND_DRBG_uninstantiate().
mspncp
changed the title
|
Ready for review. |
paulidale
left a comment
paulidale
left a comment
There was a problem hiding this comment.
A nice clean break up of the functionality.
paulidale
added
approval: done
|
Ready to merge! |
Previously, the initialization was done immediately in RAND_DRBG_set(),
which is also called in RAND_DRBG_uninstantiate().
This made it difficult for the FIPS DRBG self test to verify that the
internal state had been zeroized, because it had the side effect that
the drbg->data structure was reinitialized immediately.
To solve the problem, RAND_DRBG_set() has been split in two parts
static int rand_drbg_set(RAND_DRBG *drbg, int type, unsigned int flags);
static int rand_drbg_init_method(RAND_DRBG *drbg);
and only the first part is called from RAND_DRBG_uninstantiate().
Reviewed-by: Paul Dale <[email protected]>
(Merged from #11111)
…tiation Reviewed-by: Paul Dale <[email protected]> (Merged from #11111)
|
Thanks for doing this @mspncp |
|
You're welcome. Always a pleasure :-). |
6 participants
Here it comes: This pull request is based on #11010, see #11010 (comment) for a detailed explanation of what it does. I had to rebase @slontis' pull request in order to pick up @levitte's fix f93a17f. Only the last two commits are relevant:
commit f428aec8bd1094a7bc0ca95bb99750fe3be7eba4
commit bc826c0f35c1176314c31e9fbd4fb68305b13863
The pull request is marked WIP, because the test_rand is still failing. The internal logic of the delay initialization still needs some fine-tuning.