Getting Smaller Output From Public Key Cryptography In PHP

Question

I have a website in a shared hosting environment, and I'm also planning to back up in multiple locations. All of that introduces vulnerability where the data could get intercepted, stolen, or misused by authorized parties. The data isn't actively used on an ongoing basis, but only used very occasionally.

In order to protect against disclosure if the database gets breached, I'm working on a public key cryptographic scheme whereby a public key is used to encrypt the data when it's stored. An unchanging private key, stored offline, would then be required to access the information, which could be done in a secure environment and such that the sensitive data never leaves a temporary existence in RAM. This should massively reduce the attack surface from anywhere the data exists (original or backup), to the single points in time where the data is being accessed.

I've been starting with this first example here (with the openssl library):

https://stackoverflow.com/questions/4629537/how-to-encrypt-data-in-php-using-public-private-keys

The problem I'm running into is that the encrypted result is 512 bytes. (4096 bit.) For many fields. That's significantly larger than I'd like to store in the database.

I would ideally like to know if there's an algorithm which generates smaller results such as 64 bytes or 128 bytes, that can also be implemented reasonably easily in PHP. Is there an algorithm which gives more control over the size of the encrypted result? Perhaps I could even have different sizes of results with the same private key?

Since I'm new, I'm hoping for something which is reasonably easy to use. Thanks so much!

Answer 1

For RSA, the public key size determines the size of the ciphertext, and you need quite long public keys to achieve adequate security. However, there are actually quite a lot of problems with using RSA for encryption of arbitrary data (for example, if any datum is even almost as long as the public key, or longer, is it significantly more complicated to do the encryption securely). Although there are other public-key cryptosystems that have shorter public keys and can be used for encryption, they all have drawbacks of their own, and in many cases require additional data with the ciphertext that increases its size again.

The usual approach that addresses the problems with public-key cryptography is to use a hybrid cryptosystem, where an asymmetric algorithm is used to encrypt or exchange a secret symmetric key securely, and then the symmetric key is used for all data encryption/decryption and authentication. Most symmetric encryption constructions produce a ciphertext that is at most a short fixed length (perhaps a few tens of bytes) longer than the plaintext. Of course, there's also the one-time overhead of storing the encrypted symmetric key (or other data necessary to rederive it using the private key), which will be at least as long as the public key even before any "real" data are encrypted. For very short total lengths of data this might take more total space than using public key encryption directly, but for the size of most real-world data, or for anything where the data must be encrypted individually, hybrid cryptosystems are vastly more efficient in addition to other benefits.

---

Obligatory reminder: crypto is hard, and designing a secure cryptographic scheme (even using existing, well-implemented primitives) is still best left to the experts. While I applaud your efforts to learn more in this space, and don't want to discourage hobby projects, your evident level of familiarity with cryptography suggests that it is very unlikely you will successfully produce a secure system yourself. If this is for a business or public-sector purpose, I strongly advise hiring a security expert who understands cryptographic systems and their threat models, or using an existing, well-vetted product.