Add a primitive API for RSA about cryptography

[alex]

Needed for #114

[Ivoz]

I would have thought that a Public/Private keypair need not be specific to RSA?

Or do you think it's best to use separate classes for separate asymmetric ciphers?

How about def import(self, bytes or FileLike, format='x509') and analogous export?

[alex]

So, the API I originally outlined here isn't very consistent with how we do symmetric encryption stuff.

Seems like we want something more like AssymetricEncryptor(RSAPublicKey(...)).encrypt() or something. We need to figure out how consistent we want to be (i.e. are they both incremental?)

[public]

@Ivoz There are certainly variations in the data associated with the various keys in different asymmetric key ciphers.

@alex I think we should probably offer the same buffering facilities offered by other libraries but we can't process any output until they finalize() it. We can return b"" for update() calls though.

Is this API only the raw RSA operation or does it include PKCS#1 or OAEP padding? There aren't quite such a wide range of modes in use for asymmetric keys afaik but we should probably support them through a similar interface to the symmetric cipher modes.

[alex]

Where padding goes is definitely a huge question, particularly for people
who are going to do things like use modulus=3.

Alex

On Fri, Dec 6, 2013 at 9:56 AM, Alex Stapleton [email protected]:

@Ivoz https://github.com/Ivoz There are certainly variations in the
data associated with the various keys in different asymmetric key ciphers.

@alex https://github.com/alex I think we should probably offer the same
buffering facilities offered by other libraries but we can't process any
output until they finalize() it. We can return b"" for update() calls
though.

Is this API only the raw RSA operation or does it include PKCS#1 or OAEP
padding? There aren't quite such a wide range of modes in use for
asymmetric keys afaik but we should probably support them through a similar
interface to the symmetric cipher modes.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/197#issuecomment-30004775
.

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

[Ivoz]

I think it'd make sense to include the mode with instantiation of the cipher, similar to what happens in the symmetric API. RSA needs padding even more than most symmetric algorithms to make its basic operation effectively secure.

[reaperhulk]

@public are you aware of any incremental encryption APIs for asymmetric? Since the total size is very limited it seems like a one shot API is the most common. OpenSSL does have the EVP_Seal* functions, but they are really convenience functions for composition of RSA (only RSA) + symmetric encryption. If this is something we can expect to be available in most of our backends I would be happy to implement it, but in my (admittedly limited) search I didn't find anything. We could also choose to build this construction ourselves.

For signing OpenSSL has (in addition to the low level methods that allow signing arbitrary bytes + specifying padding) EVP_Sign* functions that provide hashing before signing, but you can't choose the padding explicitly so I'd prefer to avoid them. The docs mention EVP_SignDigest* (but it turns out they mean EVP_DigestSign* which has more flexibility. Unfortunately the latter is not supported in 0.9.8 so we can't use it.

[public]

@reaperhulk RSA is definitely "one shot" I don't think we should actually attempt to do some sort of actually incremental API for it. I do think we should match the API of the symmetric ciphers are much as possible though. I tentatively imagine something like update() adding data to an internal buffer (and returning an empty bytes) and finalize() actually doing the encryption and so on. The backend doesn't need to cope with the buffering.

Does OpenSSL expose OAEP as a single operation for us? Seems like we might need to treat it as an algorithm mode rather than a Padder if not?

[alex]

Closing this as a dupe of #508