Re: Asymetric crypto and OpenSSL 3.0 deprecated functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <tmraz@xxxxxxxxxx> 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.]
> 
> 





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux