KDF: Add configuration options to disable many of the KDF algorithms.#29576
KDF: Add configuration options to disable many of the KDF algorithms.#29576slontis wants to merge 1 commit intoopenssl:masterfrom
Conversation
|
Would it be possible to add a commit marked with DROP that will switch the run-checker-daily to be run on PR to see if all the new |
|
I tested this by manually configuring each test one at a time and building and testing for each option so it should be good. |
|
@t8m Added the commit to trigger the CI and it somehow picked up a issue and it now passes, I will drop this commit from the PR now that it is tested. |
56cb90e to
2b666de
Compare
|
rebased and dropped the temporary run-daily-checker |
|
|
||
| ### enable-lms | ||
|
|
||
| Enable Leighton-Micali Signatures (LMS) support. |
There was a problem hiding this comment.
The text here being deleted is unfortuate - rationalising the enable-{algorithm} stuff makes sense - but then we have no note or comment on lms which should remain.
We probably should have a clear note as to why each thing we have disabled by default is disabled - and that too could go in the enable-{algorithm} area.
But then again is this valuable enough a comment - we don't really explain why. Maybe just some generic text on "use at your own risk" if you choose to enable something we have off by default?
There was a problem hiding this comment.
There is no 'risk' for LMS as it only does the verify, which is completely safe. If we did sign then that comment would be valid.
Most algorithms have an associated pod file so I am not seeing the point of the description in INSTALL.md.
There was a problem hiding this comment.
I didnt even realise there was a no-{alg} section until I looked for scrypt, so we had 2 styles going on here..
There was a problem hiding this comment.
There is no 'risk' for LMS as it only does the verify, which is completely safe.
You miss the point being made - LMS as an algorithm itself has issues because of the operational requirements for signature implementations. Those operational requirements are what make the algorithm itself much less acceptable for general use for many.
It is not enabled by default - and noting why in a clearer manner would make sense. It appeared to be losing some information on that - but I also think we haven't made it clear in the docs / comments as to why it isn't enabled - and I think for anything we have turned off by default we really should have more documentation for our users to look at before they go turning on non-default options.
t-j-h
left a comment
There was a problem hiding this comment.
Approved with or without addressing the comment ...
|
This PR does not deal with some more common KDF's. I may do other PR's at some point later. |
|
This pull request is ready to merge |
2b666de to
7625eb1
Compare
|
No need for a re-review, CHANGES.md had a merge conflict. |
This includes KDF's for ss,x963,hmac-drbg,KB,KRB5,PVK,SNMP,SSH and X942. SSKDF/X963KDF Changes: Modify code to handle algorithms being disabled via configuration options.
7625eb1 to
895ea4c
Compare
|
Collapsed PR down to one commit with no changes. |
This includes KDF's for ss,x963,hmac-drbg,KB,KRB5,PVK,SNMP,SSH and X942. SSKDF/X963KDF Changes: Modify code to handle algorithms being disabled via configuration options. Reviewed-by: Tim Hudson <[email protected]> Reviewed-by: Paul Dale <[email protected]> (Merged from #29576)
|
Thanks for reviewing. merged to master. |
This includes KDF's for ss,x963,hmac-drbg,KB,KRB5,PVK,SNMP,SSH and X942. SSKDF/X963KDF Changes: Modify code to handle algorithms being disabled via configuration options. Reviewed-by: Tim Hudson <[email protected]> Reviewed-by: Paul Dale <[email protected]> (Merged from openssl#29576)
This includes KDF's for ss,x963,hmac-drbg,KB,KRB5,PVK,SNMP,SSH and X942.
Checklist