Large file encryption/decryption

[paragonie-scott]

Differences from Crypto:

• AES-CTR instead of AES-CBC
• Operates on resources rather than strings
• Decryption is slightly slow; it recalculates the MAC over the entire file and doesn't decrypt if it fails to validate.

Changes to Crypto:

• All common denominators between the two classes have been moved to a separate class called Core.

Things we would like to test for before merging:

• Is nonce reuse sufficiently mitigated?
• Can we make the buffer size irrelevant to the decryption process?
• Should we implement versioning in the regular library before adding this feature, and then make the ciphertext here versioned too?

This should close #39 (and #38?) when it's merged.

[pnowosie]

What's the point to moving to AES-CTR?

[paragonie-scott]

OpenSSL with CBC mode adds PKCS7 padding to each chunk (for us, 8192 bytes), which adds 16 bytes of overhead to each chunk.

We also have to transform the IV after each chunk and we'd end up making a sort of counter anyway.

[defuse]

might return FALSE

[defuse]

Maybe more informative: "Incorrect key length." ?

[defuse]

I'm worried about 32-bit PHP and files > 2GB. Wouldn't that overflow the integer and give us something that's potentially non-exact?

[paragonie-scott]

Should we error on file sizes >= (PHP_INT_MAX - 1) >> 1?

[paragonie-scott]

Okay, that commit satisfied the code warts you spotted (thanks @defuse!).

• I still need to test incrementCounter() thoroughly to make sure it's doing The Right Thing (TM). Momma says nonce reuse is the devil.
• If I can guarantee it works properly, I need to find out why changing the buffer size causes decryption to fail after the first buffer chunk. Then we can make it irrelevant or configurable.
• We probably want to add version tagging to both libraries then rebase first. Version Tagging #34

If @zooko has any spare cycles to tell me, quickly, if I'm doing it wrong, that would be greatly appreciated too! (For quick reference, this is a "read the whole file, verify MAC, then decrypt" approach, so no random access within the file -- maybe a separate class can be made for that?)

[zooko]

I'm sorry! I can't look at this right now. Regards, Zooko

[paragonie-scott]

As per this comment in r/netsec I've added some basic documentation to this PR. I migrated the old documentation header from Crypto.php and wrote something similar for File.php.

Storing MACs in an array and re-verifying them on decryption (after the final HMAC has been verified) has been implemented, so race conditions against the filesystem should be effectively mitigated.

[paragonie-scott]

Should I resubmit or just force push to my branch?

[paragonie-scott]

Closing in favor of #78