If you work with sensitive (human) data (e.g. anything that contains an identifier of an individual), you occasionally want to share that data. The most straightforward way to do so is to send them by email (and yes - we are all guilty of that!). The problem arises, if the data get into wrong hands. Let's say you send the email accidentally to the wrong person. Or worse, without your knowledge, the email gets into the wrong hands.
The good news is, that there is a secure & handy solution for this. But let's first have a look at some other solutions.
One (common) option is, to dump the data onto a file hosting site (like dropbox) and allow only certain users to access the files.
This is considered unsafe, mostly due to multiple security incidents.
You are essentially relying on a company's capacity to take care of your privacy ¯\_(ツ)_/¯
.
And SwitchDrive? Collaborators of Swiss universities have access to this service to store and share data. Data transfer is protected by SSL. Files can be either made public or shared with other Switch users. In both cases files can be password protected and have a download expiration date assigned. If the files are shared with another Switch user, this is probably a safe option, but making it public + password protected and then sending the link and a password to an external collaborator, is not safe (see 👆 what can happen to emails).
So if dropbox & co are not a safe option to share sensitive data, despite safer options, why are they then still heavily used?
I believe that one reason lies in the whole packaging. Dropbox is easy to install, to use and offers another benefit too (storage). Encryption on the other hand - although easy to install and use - is considered nerdy and thus not easy to use. But it totally is, which is what I want to show with this post.
If this (the hard way 👇) is too complicated, then go for either
- ProtonMail which has encryption by default (hat tip by Jean-Pierre Ghobril). It is probably the easiest & safest solution, but requires you and the recipient to create an account and send and receive your emails from there.
- keybase.io
Let's get back to the solid solution: encryption of documents. For this we need PGP keys. PGP keys are used to encrypt the documents before sending them by email (or sharing them via a server).
What is encryption? Here is a < 5 min video explaining asymmetric encryption. It starts by explaining symmetric encryption and goes on to compare asymmetric encryption to a mailbox on the street.
Asymmetric encryption is actually very easy to do, independent of platforms. There are a handful of options for encryption, but here we will use GPG. All you need to do is:
- Create yourself a pair of keys: a private key 🔑 and a public key 🔐 (this is nice to have, but is not really needed if you are the person sending the document)
- Tell the recipient of the document to do the same: create a private key 🔑 and a public key 🔐
- Exchange the public keys: 🔐
↔️ 🔐 - Encrypt the file with the public key of the recipient : 🔐 + 📄 → ⬛
- Share the encrypted file ⬛ however you want (email, file hosting, ...): 📧
- The recipient will then decrypt the file with the private key: ⬛ + 🔑 → 📄
Below are detailed instructions on how to encrypt a document. It is most convenient to use a terminal for this.
To simplify life for the recipient, you can send these instructions.
MacOSX: brew install -v gpg
Linux: sudo apt-get install gnupg2
Windows: Best is, if you install git bash. This will give you git
, but also gpg
.
(If you are not familiar with a terminal, there is www.gpg4win.org.)
The person receiving the document needs to have a set of keys. Strictly speaking, you, the sender of the document, do not really need to generate a set of keys, but for the sake of illustration, we do it nevertheless.
Generate a set of keys:
gpg --gen-key
Here you will give your name, family name and your email address.
There is an option to use a server for this. But we will stick to the terminal.
Export your public key
gpg --export -a "Your Name" > your.key
Send your public key your.key
to the recipient.
The recipient can now import the your public key:
gpg --import your.key
Ask the recipient to do the same and send you the public key, which you then need to import.
Now you know each others public keys that you can use using the name "My Name"
or "Recipient Name"
, or via the email address that is also attached to the public key.
Let's first generate a toy document:
echo "This is confidential data" > data.txt
Now we are ready to encrypt the file. These three are all leading to an identical results:
gpg --encrypt --recipient "Recipient Name" data.txt
gpg -e -r "Recipient Name" data.txt
gpg --encrypt --recipient [email protected] data.txt
Now send or upload the encrypted file data.txt.gpg
.
The recipient can now decrypt the document using the follwing command.
gpg -o data.txt -d data.txt.gpg
And while we are at it, let's get into the habit of using sha256sum.
Applying sha256sum
to a file, will return some sort of unique identifier/summary of that file (called hash), and sending this identifier file along with the original file will help checking if the file has been fully transferred (e.g. download via a server).
Here is a mini example that you can try in a terminal:
echo "This is your data" > myfile.txt ## this creates a text file
shasum -a 256 myfile.txt > hash.txt ## this creates a string we store along with the text file
shasum -c hash.txt ## this is the command somebody would use that has downloaded or received the text file. Should return OK