-
-
Notifications
You must be signed in to change notification settings - Fork 757
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
Add encrypt module and RSA OAEP support #1384
Conversation
It looks like |
@sfackler Thank you so much for your review.
I totally forgot about checking if I needed to use specific |
@sfackler I found that using |
Thanks! |
Introduce a new module
encrypt
, with the two structsEncrypter
andDecrypter
, pretty similar toSigner
andVerifier
. With the introduction ofEVP_PKEY_CTX_set_rsa_oaep_md
inopenssl-sys
, this new abstraction allows to perform RSA OAEP encryption and decryption without directly relying ofunsafe
calls.As already discussed with @sfackler, there is a pretty good amount of code duplication, there is a good opportunity to use traits to abstract away sign and encrypt algorithms (i.e. OAEP can only be used for encryption, PSS only for signing). This PR could be a good starting point to analyze the current situation and, maybe, to understand how in the future the abstractions could be improved.
I would like some feedback, mostly because I could have missed some potential problem. Let me know what you think and just tell me what's missing.
Closes #1383
EDIT: I forgot to mention: I copied the API from
Signer
/Verifier
, but I think that having to preallocate a buffer without knowing the exact size needed is pretty inconvenient. IMHO two versions ofencrypt
anddecrypt
should be provided, one that returns aVec<u8>
, the other that takes a buffer. I would like to hear your opinion about naming, because if I follow something likeencrypt(in: &[u8]) -> Vec<u8>
andencrypt_buf(in: &[u8], out: &mut [u8])
(which would be my approach), I will immediately break the API convention ofSigner
/Verifier
. Moreover, I also think that taking a&mut Vec<u8>
could be convenient, to allow automatic buffer resizing, but on the other hand some questions would rise: thevec
should be automatically cleared if non-empty? Or it should follow the same principles ofRead::read_to_end
and similar?P.S.: there is an issue about invalid C compiler parameters, which breaks the CI because
-Werror
is enabled, you probably already know that.TODO