7

I am about to go paperless, and I want to protect the documents that I scan. The use case is that I'll be scanning paper documents, encrypting each file, and storing them locally and on various backup destinations. I've been researching various ideas for how to protect those documents, but I need more guidance. Here are the details of the system I'm trying to implement:

  • Protection is at file level. If someone gets their hands on a file, I want them to be unable to use it.
  • Transmission safety is out-of-scope, and assumed to be handled by whatever system is transporting the file.
  • The files will be encrypted on a Mac.
  • Decryption should be as widely-available as possible. For example, if I want to view a file on my iPhone, I should be able to use an existing library to write an app to do so.

I've looked at using security and encryption libraries in OS X to make a lightweight tool for this. I'm a software engineer, so I'm perfectly comfortable with writing my own application, but I am new to security. I am not comfortable making the security decisions without consulting people who know more than I do.

  • I've considered AES, but then I read about padding and encryption modes, and I got lost in the details of which to choose.
  • I've considered GnuPG, but I don't like the idea of having to download a separate tool. Yes, it's open source, but if I can use functionality built into the OS, that would be preferred.

Is there a recommended approach for this?

Anders
  • 64,406
  • 24
  • 178
  • 215
Halen
  • 171
  • 2
  • "Decryption should be as widely available as possible" seems to conflict with an OS level tool. Maybe that's not an issue if you're exclusively in the OSX/iOS world, but even then you may have differences in version and inclusion, and if not now then next release cycle. http://www.tgdaily.com/software-features/62970-apple-ios-and-os-x-will-not-converge[link] – Dave Feb 10 '16 at 00:04

1 Answers1

3

You can use openssl like this:

openssl enc -e -aes-256-cbc -salt -a -in /file/to/encrypt -out /file/encrypted

Replace -e with -d to decrypt. It should work both on OS X and Linux, don't know on other systems however. man openssl to list the options and the available cipher.

Edit: looks like openssl applies few rounds of MD5 (not the best hashing algorithm) to the key derivation. This makes brute force attacks easier.

A better solution could be GnuPG (i know you asked for a preinstalled tool by the way):

To encrypt:

gpg -c -a --cipher-algo AES256 /file/to/encrypt

To decrypt:

gpg /file/to/decrypt
Matteo
  • 243
  • 1
  • 7
  • 1
    This may not be a great solution. http://security.stackexchange.com/questions/31492/file-security-when-encrypting-files-directly-with-the-openssl-command-and-what – Halen Jan 10 '16 at 16:28
  • Matteo, I think if you add a few comments about the limitations of this solution, it will be a good answer. – Neil Smithline Jan 10 '16 at 19:31
  • @NeilSmithline I think you are referring to Halen's comment, he posted the security implications. – Matteo Jan 10 '16 at 20:53
  • I am, but you can incorporate the info into your answer. What you wrote isn't really wrong, it just has limitations. – Neil Smithline Jan 10 '16 at 21:21
  • @NeilSmithline Updated the answer – Matteo Jan 10 '16 at 21:31
  • I'm warming up to the idea of using gpg. I read that using the same encryption key for multiple pieces of data is insecure. Is this something I should worry about? How should I choose/generate an encryption key for gpg? – Halen Jan 11 '16 at 01:49
  • Looks like symmetric gpg derives the key from a passphrase. Is it safe to use the same passphrase for every document I encrypt? Obviously if the passphrase is stolen then everything would be compromised, but is it cryptographically worse to use the same one? – Halen Jan 11 '16 at 02:13
  • This goes beyond my knowledge, i'm absolutely not a cryptography expert. – Matteo Jan 11 '16 at 07:12
  • @Halen: the risk about the use of the same password or passphrase for different files is another and interesting question you might search a good answer here. The core of the question is "Is sharing of secret good or bad to secret?". – dan May 09 '16 at 10:37