# Re-encrypt modified file section with AES-CTR

I am trying to encrypt a file using AES/CTR/NoPadding. The goal is to re-encrypt the new/changed blocks and leave the old ones unchanged then generate a new MAC.

My thinking is that when the file changes I’d identify the blocks that changed and encrypt the updated blocks while all unchanged blocks would reuse their existing nonce as to not change their encrypted result.

I understand that reusing nonce’s is not ideal, is there a better alternative to achieve what I’m trying to do?

Forgive my lack of experience in cryptography. I tried searching but couldn’t find an answer that addressed my use case.

• What is the size of the file? What are the attack vectors? Does the data send over the network? – kelalaka Oct 22 '20 at 6:40
• File size could be anywhere between 100KB to 5GB. Only the encrypted patched modifications would be transmitted over the network. The server would merge the modified blocks into the existing blocks. Attack vectors would maybe be on the server machine monitoring the changes to the encrypted file. – Loligans Oct 22 '20 at 8:05
• Why don't you use TLS 1.3 where a record size at most $2^{14}$ bytes and each record requires a new key? As you can see, the best solution is splitting the file into parts and using a new key and/or new IV for each part. – kelalaka Oct 22 '20 at 8:14
• Is there an attack vector or cryptographic vulnerability for generating a new cryptographic nonce only for modified blocks and keeping the unchanged blocks the same nonce? – Loligans Oct 22 '20 at 15:56
• If you keep the CTR mode nonce 92-bit and counter as 36 bits, then the chance of hitting the same none can be calculated for 1GB as; 1GB is $2^{30}$ bytes. Therefore for a file, you will need $2^{16}$ IV's. Now use a birthday attack calculation with $2^{92}$ and $2^{16}$ see the probability of hitting. Note that, actually, $2^{14}$ bytes needs only 10 bits counter. – kelalaka Oct 22 '20 at 16:10