In my I was clutching my pearls over a 13 year old MSDN article that had the gall to be written by somebody not familiar with the proper usage of cryptographic initialization vectors. Some of my fans were nice enough to point out that in all of my histrionic ranting and raving I forgot to say anything useful, like how you’re supposed to encrypt a file. last post actually So without further ado, here is how you encrypt and decrypt a file: $ gpg -c --cipher-algo AES128 [file] # Encrypt$ gpg -d [file].gpg # Decrypt Anticlimactic, right? It doesn’t even mention IVs, but that’s kind of the point. A tutorial about file encryption that includes manual handing of IVs is kind of like a tutorial about setting up a web server that includes reimplementing TCP. There’s literally no benefit to doing it and you’re almost guaranteed to do it wrong. It’s the difference between and . The first is a common task for a programmer and the second shouldn’t be attempted by a non-crypto-expert. Microsoft should know better than to conflate the two, especially in a tutorial intended for a lay audience. encrypting a file implementing file encryption GPG? This post isn’t supposed to be a tutorial about GPG, but if anybody actually wants to take my advice, please check out . And if you’re looking to do file encryption in [target language], just do the equivalent operations with an OpenPGP implementation in that language. the documentation programming Wow So PGP is Infallible? Oh god no. It has many flaws, the biggest of which is probably the awful key distribution. It just happens to have a decent implementation of file encryption that’s available on just about every platform and in just about every programming language. If you want to be thoroughly confused about this topic, here are and shitting all over PGP. Matthew Green Filippo Valsorda Hey, I Came Here For the Crypto Details! Alright so now that we’re all clear that when you want to encrypt a file you should just use a mainstream, high-level crypto library and not touch the primitives yourself, here is a basic way to implement file encryption that isn’t completely terrible: Select a secure, modern block cipher. I’d stick with AES128 unless you’ve got a really compelling reason to use something else. You can use AES256 if you want but realistically it’s not going to increase . Your password will have nowhere near 128 bits of entropy so it’s going to be by far the weakest link in this chain. security Obtain a cryptographically secure random value to use as an initialization vector. (hint: use ) /dev/urandom Obtain a high entropy key. In this case I’d say select a strong password (another topic entirely), then run it through for . For simplicity you could use the IV as the salt. bcrypt key stretching Using your block cipher, the key created from sending your password through bcrypt, and the IV generated from /dev/urandom, perform to encrypt your plaintext. cipher block chaining Append the IV to the beginning of the ciphertext, then run that whole thing through , preferably using SHA2 or SHA3. Note that we’re authenticating after encrypting, avoiding the . HMAC doom principle Append the output of the HMAC to the IV and ciphertext, and output the result. So your output should be IV || CT || HMAC(IV || CT) There you go, implementing file encryption in 6 easy steps. If you need a library that contains the primatives mentioned here, OpenSSL is a good option . If you want to decrypt, verify the HMAC by recomputing it from the IV || CT and compare with the given HMAC, then just undo the CBC encryption. That’s Cool…But Why Did We Do All That Stuff? The randomized IV and cipher block chaining achieve so that we don’t end up leaking information. The HMAC achieves and . Key stretching with bcrypt makes the key generated from your password slightly less terrible. semantic security data integrity authentication If you want to learn by playing around with these things programmatically (and you can tolerate a webapp with a UI designed by hackers) checkout . https://id0-rsa.pub/ is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories
