1

I am working on an text editor type application that runs something like this (it is a small scale app):

  1. Client can use app for an hour after running it. The app is in a boxed environment where they cannot leave the app without losing all their data.
  2. Once the time is up, the program will save the client's text input in a file to their local directory.
  3. Client can then turn this file in.

It's step 2 that I am thinking about. I want to design the application so that once the time is up, the file on the clients local directory is encrypted so that they cannot view the text contents of it again. I know I can use checksums to track any tampering after the time is up, but that is not what I am asking. I need them to not be able to recover the text input they put in the first place.

My immediate idea was to provide each client with a public key, and store a server side private key for each client. When the application closes, their text is RSA encrypted using the provided public key and only I will be able to encrypt the submission from the private keys I hold.

However I know RSA is not a good approach for encrypting actual data. As I understand, it is used more for encrypting the keys to some symmetric encryption system.

Should I just use RSA here or is there a better approach?

gowrath
  • 113
  • 3
  • 2
    Have a look at how PGP works or simply use PGP to encrypt the file for the final recipient of the data. This will implicitly use a combination of public key cryptography (like RSA) and symmetric cryptography (like AES). – Steffen Ullrich Apr 18 '17 at 04:48
  • 1
    Why not just submit the file automatically after the time is up? – ste-fu Apr 18 '17 at 06:59
  • You will not be able to use RSA only to archive what you want. See [this](https://security.stackexchange.com/questions/33434/rsa-maximum-bytes-to-encrypt-comparison-to-aes-in-terms-of-security) and [this](http://stackoverflow.com/questions/5583379/what-is-the-limit-to-the-amount-of-data-that-can-be-encrypted-with-rsa) as to why. The approach outlined by @thel3l is the right way to go. You will generate a key in memory and use it to encrypt the data. You will then encrypt this key with RSA and store it. If you worry that your key is in memory, so is your plaintext. – Marko Vodopija Apr 18 '17 at 14:13
  • @MarkoVodopija You are right; my question is kind of ill formed. Thank you for the help. – gowrath Apr 19 '17 at 03:15
  • @ste-fu Potential lack of internet connectivity. – gowrath Apr 19 '17 at 03:15

1 Answers1

1

What you ask for can be safely done with RSA, but is generally not preferred due to the amount of computation that it would take when compared to any other symmetric encryption routine.

What you need is a hybrid cryptosystem, something that uses both public key cryptography with symmetric cryptography, client side.

Example straight from the Wikipedia page:

To encrypt a message addressed to Alice in a hybrid cryptosystem, Bob does the following:

  • Obtains Alice's public key.

  • Generates a fresh symmetric key for the data encapsulation scheme.

  • Encrypts the message under the data encapsulation scheme, using the symmetric key just generated.

  • Encrypt the symmetric key under the key encapsulation scheme, using Alice's public key.

  • Send both of these encryptions to Alice.

To decrypt this hybrid ciphertext, Alice does the following:

  • Uses her private key to decrypt the symmetric key contained in the key encapsulation segment.

  • Uses this symmetric key to decrypt the message contained in the data encapsulation segment.

And further reading.

Community
  • 1
thel3l
  • 3,384
  • 11
  • 24
  • I'm aware of this approach. The issue is that Bob, after encapsulating the data via symmetric encryption, can then decrypt the data after the time limit is over, because he has the symmetric key too. This method keeps the data secure from outside parties, but not from Bob himself. This scenario is rather strange, but I basically need Bob to be able to encrypt his data with a lock that only I can open. In other words, when the time is up, the application will lock his data in a way that Bob can't open it; only I can. – gowrath Apr 18 '17 at 06:54
  • @gowrath This is not how encryption works. Hashes would be useless to you too. The only solution I can think of is to Nuke the keys on Bob's side after encryption, but he would again have access to the keys for some time. I dont know :\ – thel3l Apr 18 '17 at 06:57
  • 1
    If this was a common encryption problem I wouldn't be asking about it :D. I think RSA can achieve this because once the data is encrypted via public key, although the file is on Bob's computer, there is no way for Bob to decrypt it and edit it. Sure Bob could recreate an identical version (if he could reverse engineer the program) and then encrypt it and send that instead, but I think that is outside the realm of possibility for Bob. – gowrath Apr 18 '17 at 07:09
  • @gowrath I'm beginning to understand. I can still see Bob scanning the system's memory to look for the unencrypted data, but eh. Good luck. – thel3l Apr 18 '17 at 07:19
  • `"What you ask for can be safely done with RSA"` -- this part is not entirely correct. You will need to have RSA key slightly larger than the text to be encrypted. And it will get prohibitively large very fast. Please see [this](https://security.stackexchange.com/questions/33434/rsa-maximum-bytes-to-encrypt-comparison-to-aes-in-terms-of-security) and [this](http://stackoverflow.com/questions/5583379/what-is-the-limit-to-the-amount-of-data-that-can-be-encrypted-with-rsa). The scheme you propose is in fact the right way to go. – Marko Vodopija Apr 18 '17 at 14:08
  • @Marko Vodopija - split the data into multiple blocks? That's always the way to go when you *need* to use RSA with large files. – thel3l Apr 18 '17 at 15:09
  • @thel3l In the first link I gave you can find a section dedicated to splitting the data into blocks and why it might not be a good idea. – Marko Vodopija Apr 18 '17 at 15:37