Safe from prying eyes: a free script app for robust encryption

There are lots of good – and legitimate – reasons for wanting to encrypt documents, but not everyone is content to use the command line in Terminal.

Here is a free, completely trustworthy, open source droplet to encrypt and decrypt documents, using the same technique approved for highly classified US military secrets.

I assure you that it is trustworthy – there are no back doors, no shady code which might send a security agency your password – as every step in its chain of trust is visible to you. The droplet is coded in plain AppleScript (no suspect extensions) which I explain below. It calls on OpenSSL to perform the encryption and decryption, using the same commands which I gave previously. OpenSSL is open source, which you can download and inspect. If you don’t trust Apple’s bundled OpenSSL, you can compile and install your own and tweak the script to use that. It has no secrets or back doors.

(It is also worth mentioning in passing that El Capitan’s SIP security protection should also make it very hard for anyone to tamper with your OpenSSL installation.)

There is one droplet app, Escrypto, to perform encryption, and one, Descrypto, to decrypt. They do not work on folders, only groups of one or more files. Some files – like apps – need to be turned into archives or disk images before being compressed. It is also slightly picky about file names, which should not include single quotation marks. You can tweak the source yourself if you want to improve that.

It will not encrypt/decrypt massive files: it is good for a couple of hundred MB, but may well not bother with single files larger than that.

In accordance with recommendations, it uses ‘salt’ together with your password to generate the key. This effectively strengthens the password against brute force attack. The ‘salt’ is generated from random numbers.

Here it is, as a Zip archive:crypto

Now let’s step through its source code and explain what it does and how it works.

cryptscript1As an AppleScript droplet, it is called when the Finder asks it to open the items which you drop onto it, and that wraps the main code shown above, for the encryptor.

AppleScript does not come with sophisticated support for dialogs, so I have kept them simple. The Finder will first prompt you to confirm whether you want to run the script. Assuming you answer OK, the first two dialogs simply ask you to enter the password which you want to use. It is entered twice, in plain script and for all to see, so that you can ensure that it is correct on both occasions.

If the two copies do not match exactly, it quits. If they match, then you are presented with a final dialog which asks you to choose whether to encrypt to binary, or whether you want the encrypted file converted into text using Base64 encoding, so that it can be sent as an attachment to a message (the default).

Then it constructs the ‘salt’ from four different random numbers, converted into hexadecimal, making a 16-digit hexadecimal string.

With those elements in place, it simply iterates through the list of files which were dropped on it, calling the subroutine process_item. As soon as it encounters an error, it displays that and quits.

cryptscript2The process_item subroutine first gets the POSIX path to the file it is processing. That is used to generate the name of the encrypted file, either by appending .base64 if it is so encoded, or .crypt if it is left in binary. It then assembles the text string which it needs to run from the command shell, as given previously, and calls that. If you want to check this, comment out the line containing do shell script, and uncomment that beginning display dialog theCmd, and it will display commands rather than execute them.

cryptscript3The other subroutine is used to convert the random integers into four bytes of hexadecimal string, and was borrowed from Nigel Garvey’s elegant solution on MacScripter. Thank you, Nigel.

cryptscript4Decryption is rather simpler, and based on the encryption code. You are first prompted for the password twice, and if the two copies match it then asks you whether you want to decrypt from binary or Base64 encoded. Although this could auto-detect on the basis of the extension, that would require you to retain the extension, which you may not wish to do. This does have the disadvantage that you can only decrypt all binary or all Base64 files in a single batch, and you cannot mix them.

It then iterates through the list of files, calling its version of process_item on each in sequence.

cryptscript5This time the command to be constructed is simpler, as it lacks the ‘salt’, only differing according to whether it is working from binary or Base64 files.

As you see, I am dedicating this tool to TalkTalk, in the hope that it might see the benefits of more extensive encryption and protection of its customer data, and the UK’s draft Investigatory Powers Bill, as no one should be able to open a back door to decrypt any of these files. And there is no point in running to me asking for golden keys, because as you can see plainly, there aren’t any. So there. If you lose/forget your password, you will never be able to decrypt these files.