As stated in these other answers, decryption time is essentially independent of file size with standard encryption methods.
However the decryption time can be proportional to file size with some (non-standard) form of dual encryption such that fully decrypting the outer layer is necessary to start the decryption of the inner layer.
Such dual encryption could be as follows:
- Draw a random secret 256-bit key $K$.
- Encrypt the file with key $K$ per AES-256-CTR, yielding intermediary ciphertext $I$.
- Hash $I$ with SHA-256, yielding $H$.
- Compute salt $S\gets K\oplus H$.
- Stretch the password into a 256-bit derived key $D$ with salt $S$ per PBKDF2-HMAC-SHA-256 and 10000 rounds (a common if not recommendable practice).
- Encrypt $I$ with key $D$ per AES-256-CTR, yielding ciphertext $C$.
- Form the encrypted file as $S$ followed by $C$.
Standard password-based encryption would typically consist of generating a random salt $S$, then performing steps 5/6/7; so we are merely extending practice. A competent password cracker or state-level actor would be able to attack that if the password is only fair, using GPUs, FPGAs or ASICs to speed up the password search, because it's used PBKDF2 (using Argon2 instead would be state-of-the-art, and make password search considerably more constly)
The best way to find the password and decipher goes:
- Parse the encrypted file to get prefix $S$ and the rest $C$.
- For each password to test (mostly: from most to least probable):
- Perform step 5, yielding some $D$.
- Decrypt $C$ with key $D$ per AES-256-CTR, yielding some $I$.
- Hash $I$ with SHA-256, yielding some $H$ (as in step 3).
- Compute some $K\gets S\oplus H$ (reversing step 4).
- Decrypt the beginning of $I$ yielding the beginning of the file if the password is correct, or meaningless garbage otherwise.
- Test if that beginning of the file is plausible (that's possible quickly and with near certainty for most practical files: Anything uncompressed, compressed video, zip archive, JPEG image); if so, decipher the rest.
The critical point is that it's necessary to decrypt the whole of $C$ into the whole of $I$, and hash that, in order to test if the correct password was found. When the file is large, that will dominate the cost of password search, to the point of making the key stretching of step 5 a negligible part of the deciphering cost.
An edit to the question adds:
Neither file is plain text. They are email databases of some unspecified, proprietary format, which means if you were to try to open them with a text editor, you'd get gibberish. So, basically I expect that, in order to see if a password was right, you'd have to decipher the whole thing and plug it into the email software to see if it is read correctly.
No! For the overwhelming majority of file formats and standard encryption methods, including databases of proprietary format and AES-256 in all standard modes, it's easy to distinguish if a partial decryption was made with the correct key or not. It's used that the data in the partial decrypt is distinguishable from random for the correct key only. As a proof of concept, the standard
ent tool will reliably make the differences between 4kiB bytes of
/dev/urandom, and a 4kiB segment in a database.
In order to get the decryption time by competent actors proportional to the file size, we need a special kind of encryption as I describe, involving dual encryption, and some twist as in my steps 3/4.