modify_file_inplace

This describes the design decisions, restrictions and requirements for this function

This is the real meat of the project, and performs all of the crypto.

Modify_file_inplace() takes three arguments:

• the path of the file to be encrypted/decrypted.
• a function which takes a string and returns a string of the same length.
• an integer to represent the block size. Defaults to 16 bytes.

Parameter one is self explanatory.

Parameter two: this must be a function that takes only one parameter, the string, and outputs a string of the same size (a stream cipher)

Parameter three: because it's a stream cipher, the block size is mostly irrelevant and only needed for speed and efficiency. It has a default value, so leaving it out is probably best.

Why is it this way?

This function writes in place. This comes with many benefits, and imposes several restrictions. Many ransomware will write to a new file, then delete the old one. This can fail if:

• the device is full or lacks enough free space to hold another full copy of the file
• the current context does not allow deleting files.
• the program is terminated before it can delete the old file
• the file has multiple hard links, so deleting it doesn't actually delete it
• the user trys to recover deleted plaintext files from slack space.

Writing over the file where it lives solves all these problems but imposes a few restrictions:

• the algorithm must be a stream cipher with no padding, returning the same length cipher text
• the stream cipher must not include any AEAD or authication tags, hashing, or other data. (So no GCM)

For these reasons, I recommend and use CTR mode. It is a nice, well respected, unauthenticated stream cipher mode. But you could use any other stream cipher like OTP, substitution ciphers, Caesar, etc.

Any underlying algorithm would be acceptable with CTR mode, but I chose AES because it is well supported and very secure.

The algorithm you choose is not specified in this function, but is passed in the second parameter.