Asymmetric encryption of transaction log file: is RSA the correct algorithm

Question

I want to produce a transaction log that is encrypted while being produced. I'd prefer asymmetric encryption. It is possible that my program will terminate without writing any closing blocks, so my output can't depend upon being able to write any end-of-file blocks the encryption scheme may require.

I can open new transaction logs as needed and do not require the ability to append to a previous one.

I believe I can do this by storing the public key on the server (and hiding the private key), choosing the proper algorithm, and using a stream encryption writer in my output.

Later, when viewing the transaction log, I can just do everything in reverse. And in this way, my transaction logs are always stored encrypted at rest.

Is RSA the correct algorithm? If not, what should I use instead?

Coding is in C++. I presume I can do what I need to do with crypto++.

Answer 1

You probably want to use hybrid encryption, i.e. a combination of public key and symmetric encryption. Public key encryption is very limited in the amount of data that can be encrypted. For example, with RSA the amount of data that can be encrypted is somewhat less than the key size, so with a 2048 bit RSA key you're going to be able to encrypt somewhere around 230-240 bytes. I'm guessing your transaction log is longer than that.

With hybrid encryption (used in things like PGP, S/MIME, etc.) you generate a random symmetric key and encrypt your "big" data with that. You then encrypt the symmetric key along with identity other information using the public key. The private key can then be used to decrypt that header which includes the symmetric key and that key can then be used to decrypt the "big" data.

Answer 2

It's understandable that you want to use public key encryption to separate the encrypting key from the decrypting one, but that doesn't mean you can't utilize symmetric encryption.

Probably your best option is to use something like a stream cipher (such as AES-256 in CTR mode or any other suitable algorithm you prefer) which is capable of encrypting each bit independently, but then make sure that the symmetric encryption key is protected via the public (say RSA) key.

Then, when you want to retrieve the logs and decrypt them on the machine that contains the private key, first you decrypt the symmetric key, and then use it to decrypt the logs.

Apart from that, note that in general encrypting a massive amount of information via public key encryption is undesirable due to performance and in most cases also security reasons.