Score:1

Ensuring Data Security During Decryption and Re-encryption Process

ls flag

Scenario:

Consider a scenario where Server 1 stores a 600-800 KB ebook encrypted with a certain private key. Server 2, a computation-purpose server, holds this private decryption key and get access to the encrypted file. Its task involves decrypting the file and re-encrypting it with a public key using a specific algorithm.

Problem:

The problem lies in ensuring that Server 2 doesn't create a local copy of the decrypted file during the computation process. The objective is to guarantee that the decrypted content is never exposed, only a new encrypted file should be generated as an output.

Questions:

  • How can one ascertain that Server 2 refrains from storing the decrypted file during the computation process?
  • What type of decryption-encryption algorithm is suitable for achieving this goal? The intention is to produce a new encrypted file without generating the decrypted content as an output.
  • Is the preferable solution software-engineered, such as using a Homomorphic encryption computation? Alternatively, would a hardware-oriented approach like Trusted Execution Environments (TTE) or Secure Enclaves be more effective in this context?

Your insights and expertise would help me a lot to select an approach that effectively maintains data security and privacy throughout the decryption and re-encryption process.

Eugene Styer avatar
dz flag
Note we usually use public-key encryption to establish a shared private key which is then used to encrypt the data.
Score:0
bn flag

In this scenario it seems like you must trust one party, and based on the fact that server 1/client holds the encrypted ebook, you don't trust them, thus you must trust server 2.

A potential (and simple) solution to your specific problem would be to trust server 2 and implement controls to prevent this by the trust party operating the server(s). This decryption process could only be done in memory, for example, and then the file system is never touched which solves the core issue. This would be especially helpful if you file is only a few KB anyways. Of course at scale, this could present challenges but I'm not sure this is the best question/problem to be introducing at scale.

I don't think we know enough about the specifics of the goal you are trying to achieve through this post, so nuances are likely to come up from answers. In terms of algorithms that you asked about, this would depend on your application again. If this is a production system, perhaps there are guidelines on the type of information you are storing from a regulatory body if you must be compliant in a certain framework.

JeremyDEX avatar
ls flag
Ok thanks. My problem is that I shouldn't trust server 2. Anyone could be server 2. I give the secret key to decrypt file, but I want to be sure that even with that secret key, it's impossible to store/read the decrypted file. Is there an algorithm that can only decrypt and re-encrypt in chunks for example?
JeremyDEX avatar
ls flag
Server 2 has the role to decrypt and re-encrypt a file with a public Key of a client, and then only client can decrypt complete file with his own private key.
JeremyDEX avatar
ls flag
If I only accept trusted environnement for a server 2, problem is that I still give secret key. So the security should come from the protocol itself. Anyone with a secret key could only re-encrypt the file without never read the file.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.