I’ll note that encryption is _not_ an integrity check. Depending on how the AES encryption is done, this could be a significant hole.
Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 25 May 2020, at 10:12 pm, Tomas Mraz <tm...@redhat.com> wrote: > > On Mon, 2020-05-25 at 13:20 +0200, Emmanuel Deloget wrote: >> Hello everybody, >> >> I'm pretty sure this has already been discussed somewhere but >> grepping >> through the whole openssl-user list does not gave me the answer I'm >> searching for, so here am I. >> >> In my development I'm using a idiom that's not as widely used as I >> thought (as I get it after multiple days of searching out there). In >> order to securely distribute a binary, I encrypt it using an AES key >> and the AES key itself is encrypted using a /private/ RSA key I own. >> Only owners of the /public/ key (which, as it is a publilc key, may >> leak) can decrypt the AES key, and therefore the binary. The reason >> why I do this is that I cannot encrypt using the recipient public key >> because I don't know how many different recipient I have when I >> generate the encrypted binary ; and generate the binary on request is >> not feasible. >> >> With this idiom, recipient can check that I crypted the binary, and >> the binary itself cannot be decrypted unless you're a recipient (i.e. >> you have the public key). This has worked well for a few years. >> >> Of course, in order to do this I rely on RSA_private_encrypt() and >> RSA_public_decrypt() because EVP_PKEY_encrypt() / EVP_PKEY_decrypt() >> cannot be used(*). >> >> So, after that long introduction, here is my question : is there any >> OpenSSL 3.0 sanctionned, EVP_PKEY-based way to crypt using a private >> key and decrypt using a public key? >> >> While I fully understand the need to streamline the library interface >> and to remove the low-level RSA functions, it seems to me that not >> allowing this is going to be problematic for those who, like me, rely >> on public key decryption in their process. I also fully understand >> that it's not the prefered way to do it but I (and some others, I >> guess) deal with a use case which is not ideal here, and the >> possibility to use asymetric crypto in this way really saves me. >> >> Best regards, >> >> -- Emmanuel Deloget >> >> (*) tests on OpenSSL 1.0.2 (Ubuntu 16.04) and OpenSSL 1.1.1c (Ubuntu >> 19.04) shows that it segfaults in EVP_PKEY_decrypt() when feeded with >> a public key. In OpenSSL 3.0, EVP_PKEY_decrypt() does not appear to >> be >> able to decrypt using a RSA public key (it calls >> RSA_private_decrypt() >> internally, via rsa_decrypt()). > > The proper protocol would be to just sign the binary by your private > RSA key and encrypt it with a symmetric key, that you directly pre- > distribute to your recipients via the same channel that you now use to > distribute your public RSA key. > > It would have practically the same properties and would not use the RSA > private encryption directly. > > > -- > Tomáš Mráz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > >
