-
Notifications
You must be signed in to change notification settings - Fork 41
Conversation
This is some cool work, +1 on getting this reviewed and merged please (@btoews) |
I'm not at GitHub any more. @ptoomey3 might be able to help. |
/cc @github/prodsec for triage. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello! Thanks for the pull request, we'd love to be able to accept this PR after some questions are answered and some feedback is considered.
Aside from the inline comments and suggestions, can you please add some tests for this in certstore_tests.go
?
@@ -441,7 +457,8 @@ func (wpk *winPrivateKey) cngSignHash(hash crypto.Hash, digest []byte) ([]byte, | |||
} | |||
|
|||
// capiSignHash signs a digest using the CryptoAPI APIs. | |||
func (wpk *winPrivateKey) capiSignHash(hash crypto.Hash, digest []byte) ([]byte, error) { | |||
func (wpk *winPrivateKey) capiSignHash(opts crypto.SignerOpts, digest []byte) ([]byte, error) { | |||
hash := opts.HashFunc() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since CAPI does not support the RSA-PSS algorithm, would it make sense to check if capiSignHash
was given an opts
that successfully casts to rsa.PSSOptions
and return an error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you're saying, but will the PSS flow ever get to this func?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not, but I think it would add some clarity that PSS is never expected to work with CAPI, in case someone does manage to get in to this path. I'd rather a clear "not supported" error than a strange Win32 error or something not working.
certstore_windows.go
Outdated
enc := make([]byte, 2, 10) | ||
copy(enc, "0x") | ||
h := strconv.AppendUint(enc, uint64(ss), 16) | ||
return fmt.Sprintf("SECURITY_STATUS %s", string(h)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think something like this would be more idiomatic:
enc := make([]byte, 2, 10) | |
copy(enc, "0x") | |
h := strconv.AppendUint(enc, uint64(ss), 16) | |
return fmt.Sprintf("SECURITY_STATUS %s", string(h)) | |
return fmt.Sprintf("SECURITY_STATUS 0x%08X", ss) |
certstore_windows.go
Outdated
|
||
if pssOpts, ok := opts.(*rsa.PSSOptions); ok { | ||
saltLen := pssOpts.SaltLength | ||
if saltLen < 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SaltLength
has two magic values, PSSSaltLengthAuto
is 0 for an auto value, and PSSSaltLengthEqualsHash
is -1.
We should not set the saltLen
to len(digest)
for anything other than PSSSaltLengthEqualsHash/-1 (maybe a new magic value will be introduced in the future).
I don't believe CNG will accept a value of "0" to mean "auto" the same way that it means in other places. The documentation states that auto is:
PSSSaltLengthAuto causes the salt in a PSS signature to be as large as possible when signing, and to be auto-detected when verifying.
Can we replicate that auto length behavior if the value is 0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure. nice catch :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good points! applied most of them but I'd like to deepen the discussion about one of them. please tell me what you think :)
certstore_windows.go
Outdated
|
||
if pssOpts, ok := opts.(*rsa.PSSOptions); ok { | ||
saltLen := pssOpts.SaltLength | ||
if saltLen < 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure. nice catch :)
@@ -441,7 +457,8 @@ func (wpk *winPrivateKey) cngSignHash(hash crypto.Hash, digest []byte) ([]byte, | |||
} | |||
|
|||
// capiSignHash signs a digest using the CryptoAPI APIs. | |||
func (wpk *winPrivateKey) capiSignHash(hash crypto.Hash, digest []byte) ([]byte, error) { | |||
func (wpk *winPrivateKey) capiSignHash(opts crypto.SignerOpts, digest []byte) ([]byte, error) { | |||
hash := opts.HashFunc() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you're saying, but will the PSS flow ever get to this func?
@vcsjones, sorry for this nudge, just making sure you haven't missed my changes/comments 😊 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look good, but I think it would still make sense to add an explicit error in the PSS-CAPI path. Also, I think we need some tests around this to make sure things are working (and continue to).
@@ -441,7 +457,8 @@ func (wpk *winPrivateKey) cngSignHash(hash crypto.Hash, digest []byte) ([]byte, | |||
} | |||
|
|||
// capiSignHash signs a digest using the CryptoAPI APIs. | |||
func (wpk *winPrivateKey) capiSignHash(hash crypto.Hash, digest []byte) ([]byte, error) { | |||
func (wpk *winPrivateKey) capiSignHash(opts crypto.SignerOpts, digest []byte) ([]byte, error) { | |||
hash := opts.HashFunc() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not, but I think it would add some clarity that PSS is never expected to work with CAPI, in case someone does manage to get in to this path. I'd rather a clear "not supported" error than a strange Win32 error or something not working.
This project is now part of |
fixes #17