Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing DecryptPKIEnvelope/Success methods signature #13

Closed
dselyuzhitskiy opened this issue Jan 30, 2024 · 8 comments · Fixed by #14
Closed

Changing DecryptPKIEnvelope/Success methods signature #13

dselyuzhitskiy opened this issue Jan 30, 2024 · 8 comments · Fixed by #14
Assignees
Labels
enhancement New feature or request needs triage

Comments

@dselyuzhitskiy
Copy link

dselyuzhitskiy commented Jan 30, 2024

Hello!

I'am trying to use scep library with external Decrypter/Signer. It is ok, because pkcs7.Decrypt could use privateKey as crypto.Decrypter interface, so i can use any implementation. But in scep library DecryptPKIEnvelope/Success use rsa.PrivateKey instead of interface, so i need to provide private key.

Could we change signature of DecryptPKIEnvelope/Success methods and instead of rsa.PrivateKey use crypto.PrivateKey from pkcs 7 lib?

@dselyuzhitskiy dselyuzhitskiy added enhancement New feature or request needs triage labels Jan 30, 2024
@hslatman hslatman self-assigned this Jan 30, 2024
@hslatman
Copy link
Member

Hey @dselyuzhitskiy, thank you for opening the issue. This seems reasonable, indeed. Instead of taking the *rsa.PrivateKey we can take a crypto.Decrypter as argument. The tricky part is that we currently only support decryption using RSA keys, so IMO we would need to handle non-RSA keys adequately. That could mean just failing on the decrypt operation, but I'll have to se what we can do.

@dselyuzhitskiy
Copy link
Author

Thanks for quick response @hslatman. I'm not an expert in crypto, but what non-RSA keys do you mean? May be i can try to found some solution for this

@hslatman
Copy link
Member

hslatman commented Jan 31, 2024

@dselyuzhitskiy with the non-RSA keys I mean any object adhering to the crypto.Decrypter interface, but not actually representing an RSA key. Currently we don't support SCEP decryption using the challenge password, as described to be used when there's an ECDSA key in use, for example (and we would likely need a different decryption method, anyway). We should be able to check the public part to be an RSA key; crypto.Decrypter does provide the Public() method, after all. So, there's a path forward 🙂

@dselyuzhitskiy
Copy link
Author

Looks like we just need to cast crypto.PublicKey to rsa key, but give me some time to discover best solution

@hslatman
Copy link
Member

hslatman commented Feb 1, 2024

Yes, should be just a matter of calling Public(), and checking that to be an RSA public key; I was overthinking this 😅

@dselyuzhitskiy
Copy link
Author

Read some RFC and yes, for encryption based on PasswordRecipientInfo we should provide other recipientInfo structure, parse tags and provide different Decryption method, so i think, for begin we could just check that key is rsa

@hslatman
Copy link
Member

hslatman commented Feb 7, 2024

I've opened #14. You can give it a try 😄

@dselyuzhitskiy
Copy link
Author

Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needs triage
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants