I have been trying to implement a high-volume symmetric (AES256) encryption/decryption pipeline for files on disk.
Originally, I tried to do this by having scripts call command-line tools such as gpg2
, openssl
, or mcrypt
, but I found this approach unworkable. The root of the problem is that all these command-line tools impose too many restrictions on what the user can and cannot do. For example, openssl
won't encrypt stdin
; mcrypt
won't allow one to specify the name of the encrypted file; gpg2
requires gpg-agent
to run, etc., etc., etc.1
I also looked into Python's cryptographic libraries, but I read that they are not suitable if one needs to encrypt/decrypt very large files or if performance is important, both of which apply to my project.
So I think I'm going to have to bite the bullet and code this in C (at least as a C extension of Python).
For my needs, the ideal library would be one that had functions that took three arguments: an input stream, an output stream, and a key. They would then AES-256-{en,de}crypt the input stream using the key, and write the encrypted content to the output stream.
Can someone recommend a C library that has this sort of functionality, can be used safely by someone without much formal training in cryptography, and is under active development?
BTW, I did try libmcrypt
but when I attempted, as a test, to compile the mcrypt
utility from source, the resulting executable crashes with a malloc(): memory corruption
error. I spent many hours trying to fix this without success. Then I looked for a developers' mailing list for the mcrypt project to post a question to, but it appears that the project is now defunct.
1 Please, do not address these issues in this question. I just wanted to provide a few examples of the issues I've run into; I've run into many more than these.
cryptography
) both employ C already for the main bottlenecks. – John Y Feb 22 '19 at 15:12cryptography
and sounds almost exactly like what you're looking for (in terms of functionality, if not necessarily speed). Please understand I am not trying to be dismissive of your question. You may well need a C-based solution. But it would be kind of silly not to at least try Python, just because you read something that said "Python will be too slow, don't bother". – John Y Feb 22 '19 at 15:22