I need to decrypt a huge file that I own previously encoded by myself with a RSA

Question

I need to decrypt a huge file that I own previously encoded by myself with a RSA public key (it's possible for this step using a symmetric algorithm key). Problem is that I can't load it in my disposable memory for specific embedded architecture reasons.

I need to decrypt it with the private key associated to the identity of that architecture (or the shared symmetric case if there were the algorithm chosen). I want to know if its possible to decrypt the file loading it in memory by parts and decrypting each of them, without losing security against brute force attacks. As far as I know, in a typical RSA encoding process first you transform the whole char string that is the file into a number, to be encrypted, so my assumption is that is not possible in a typical RSA encoding-decoding process. However, as I have the file I can encrypt it line by line or char by char, instead of encoding the whole, to decrypt it later again slice by slice. I'm assuming that a line or a char after encryption would have the same length in bytes, which may be a wrong assumption.

Explanation / Answer

As far as I know, in a typical RSA encoding process first you transform the whole char string that is the file into a number, to be encrypted, so my assumption is that is not possible in a typical RSA encoding-decoding process.

That's not typical. A typical real world RSA encryption process uses hybrid encryption, encrypting the data with a single-use symmetric key that is then encrypted using the actual RSA algorithms.

Depending on what the symmetric encryption is, you may be able to "seek" within the encrypted file without decrypting other parts. In most cases you'll at least be able to read it from the start and throw away decrypted parts as you go, avoiding excessive memory use.

However, as I have the file I can encrypt it line by line or char by char, instead of encoding the whole, to decrypt it later again slice by slice. I'm assuming that a line or a char after encryption would have the same length in bytes, which may be a wrong assumption.

Is this a feasible solution? Am I losing efficiency and would be more exposed to brute force attacks?

Using context-dependent (e.g. lines) blocking could leak data on the plaintext, so I wouldn't recommend it.

If you need to be able to quickly jump within the encoded file, you should use a symmetric encryption algorithm (under RSA if you want) that makes this easy. For example, AES in CTR or CBC modes. You will not be able to safely modify a small part of the file, but for read-only access that would be fine.

  In that case, I would divide the file into constant-sized blocks that get independently encrypted using any symmetric encryption algorithm that accepts a large nonce (24+ bytes would be good, but 16 at the very least). Generate a single symmetric encryption key, which you encrypt with RSA. For each block generate a random nonce/IV that gets prepended to the ciphertext. When something is modified, rewrite the whole block(s), generate new random nonces.

Block size should be chosen to balance the memory expansion caused by nonces with the write amplification caused by rewriting blocks. Something like 4KiB blocks would probably be OK, I would think.

Instead of random nonces, one could use an incrementing counter, but in that case there might need to be additional safeguards to prevent an attacker feeding you an old version of the file, so random nonces are simpler.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.