fix(sspi): DH client default parameters: remove leading zero #514
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
I fixed the scard-based auth AS exchange in our Kerberos implementation. The problem (surprisingly) was in the default DH credentials. The leading zero is the cause of the invalid public key generation:
Why did we have the leading zero?
Because around 3 years ago (#61), it was written as it is. It worked well with the previous bigint dependency, but not with the crypto-bigint.
Why did we hardcode them?
I think they should be randomly generated. But it is not a major security issue because the private key is still randomly generated. I propose to fix it in the future and replace hardcoded public key parameters with their random generation on each logon
cc @thenextman