zipaes v1.1

Copyright 2005, Edward K. Chew, All rights reserved.

(Note: zipaes was totally rewritten in version 1.1.)

zipaes is a set of tools for copying, archiving, and encrypting your data under Mac OS X 10.3 or later. Notable features include:

Most of the functionality comes from two command line tools: zipaes and rditto. Both are shell scripts which call on other tools built into Mac OS X, such as ditto and openssl. There is also a simple drag-and-drop utility called DropZipAES (an AppleScript which calls zipaes). Dragging files on it will create encrypted archives, and dragging encrypted archives on it will retrieve the files contained therein.



You can drag the three files anywhere you like, but it is most convenient to keep them together in the same folder. DropZipAES needs to be able to find zipaes which, in turn, needs to be able to find rditto. DropZipAES will ask you where zipaes can be found if you separate the two. It will try to remember the new location, but may forget under certain circumstances. zipaes keeps the location of rditto in a variable near the beginning of the script.

My own strategy has been to keep them all in the same folder, but use aliases or symlinks to make them available wherever I want. For example, I symlinked zipaes and rditto into /usr/local/bin and aliased DropZipAES onto the Desktop.


While there are no man pages for rditto or zipaes, running either script without any parameters will cause it to spew usage notes to stderr. The zipaes notes sort of assume you have already had a look at the rditto notes. I will not duplicate those notes in this documentation, but concentrate more on examples instead.


Mac OS X includes a command line tool called ditto, which can copy files from place to place and also create archives of your data. One thing it is not good at doing is copying to/from remote Macs, which is why I came up with rditto. rditto uses an ssh connection to achieve this, so the data should be secure while in transit. (Be sure to have Remote Login switched on in the Sharing preferences of the remote computer.)

rditto is similar to ditto in many ways, but those familiar with the latter should read the usage notes carefully, as there are some important differences. For example, when rditto is copying files, it assumes that the last argument is always a destination directory. Consider the following:

ditto foo bar
rditto foo bar
ditto will replace bar with foo. rditto will copy foo into bar, resulting in bar/foo. You cannot rename a file as you copy it using rditto.

The syntax for specifying files on remote hosts is similar to what you find in other tools like scp and rsync. These two lines copy a directory called bar within /foo to and from a remote host, showing the file-by-file progress with -V:

rditto -V /foo/bar/
rditto -V /foo/
As a rule, you should always end directory names with a trailing slash. There are times when rditto uses the slash to distinguish between files and directories, which is necessary due to some peculiarities of ditto. (Specifically, it checks for the slash after source paths on remote hosts, since it is cumbersome to examine remote files up close.)

rditto can also archive files directly to a remote volume. This time, we back up to and restore from to a zip file at the other end.

rditto -ck /foo/bar/
rditto -xk /foo/
rditto uses pipes internally to handle these remote connections, but you can use them in inventive ways yourself. For example, many Internet providers give you some space on a web server to set up a home page. Let's say yours asks you to upload the page to a www directory using ftp. You could post bar to the web by writing something like this:
rditto -ck /foo/bar/ "-" | curl -T "-" -u user:password
You could then use either a web browser or curl and rditto once again to download file:
curl | rditto -xk "-" /foo/

(Note: Depending on the ISP, the ~ may or may not be necessary.)
Unlike the regular ditto, rditto allows you to combine several items into a single archive, as in:
rditto -ck foo/ bar/
This involves creating temporary copies of foo and bar which are eventually deleted after the archive has been created. (These copies go into the Temporary Items folder of your home folder, so make sure you have enough disk space left on that volume.) By default, the copies are deleted with a simple rm instruction, but you can choose to securely delete them using the -r# option. -r0, -r1, -r2, and -r3 correspond to rm (simple unlink), srm -s (single pass overwrite), srm -m (7 passes), and srm (35 passes), respectively.

Alternatively, you can have rditto create one archive for each item using the -b batch mode:

rditto -ck -b ".zip" foo/ bar/ dest/
This should result in dest/ and dest/ As you can see, -b expects the suffix that goes with the archives.


As zipaes is basically just a layer on top of rditto, the syntax is much the same. Since it only creates encrypted zip archives, you can drop the -k option. The only added consideration is in how to provide the password to be used in encrypting and decrypting the data. The default behaviour is to have openssl (the encryption tool used by zipaes) prompt you for it itself. This is arguably the most secure approach, but it can be awkward at times. In particular, if you have turned on verbose mode (-v or -V), the password prompt can appear at the most inopportune moment and be obscured by comments.

Fortunately, openssl provides other means of entering the password, and zipaes lets you specify the one you want using -p. (The only one you must expressly avoid is stdin, since that is reserved for the archive data.) You can enter it directly on the command line or via an environment variable.

zipaes -c -p pass:shazam foo/bar/ bar.zipaes
zipaes -x -p pass:shazam bar.zipaes foo/

password="shazam"; export password
zipaes -c -p env:password foo/bar/ bar.zipaes
zipaes -x -p env:password bar.zipaes foo/
The second form should be a bit more secure than the first (as long as you don't keep that environment variable alive), as someone logged into your computer could easily eavesdrop on what you are typing into the command line using ps. (Environment variables are only accessible by the shell which exported them and any child processes.)

zipaes also lets you enter -p env without specifying the variable name. In this case, zipaes itself will prompt you for the password, which it will then pass on to the to openssl through an environment variable. From an outside perspective, this works much like the default password prompt from openssl, but plays nicer when you have verbose mode on.

Note that when you are addressing remote hosts, you may see a second password request coming out of ssh. If you do a lot of remote copying and archiving, you might want to look into setting up public keys and ssh agents. (Read man ssh-keygen and man ssh-agent to set it up yourself or try a third party utility like SSH Agent.)


There is not much to DropZipAES usage. That's the point. You drag your files onto it and it archives or unarchives them as appropriate. As yet, there is no support for archiving to remote hosts and stuff like that. The command line tools are a lot more powerful.

Make sure your archive names end in “.zipaes”. DropZipAES looks for that to determine if the file is an archive to be expanded or a file to be compressed.

If you open up AppleScript in Script Editor, you will see a number of user-defined properties at the top you can edit to customize the behaviour somewhat.
request_destination Always ask you where you want to put things. By default, the archive goes into the same folder as the original files, though DropZipAES may ask you for the destination anyway if there is any ambiguity.
use_Terminal Normally, DropZipAES runs zipaes in an internal shell, but you can elect to have it open Terminal windows to execute commands. The main motivations for doing this would be to see a more verbose output and/or to use a more secure password entry. (DropZipAES normally just calls zipaes with the password on the command line.)
zipaes_options These are options to add to the zipaes command line. The default is "-r1", which has DropZipAES to a quick overwrite of temporary copies of your data as a security precaution. In conjunction with use_Terminal, I like to use "-r1 -V -p env" so that I can watch everything that's going on.
beep_when_done This only comes into effect when use_Terminal is false, but that tends to be when you need the most feedback about script completion anyway.


Version History

  • Added some error reporting for when DropZipAES calls either zipaes or unzipaes. (This only applies to when use_Terminal is set false; I figure you will see the error message in the Terminal window otherwise.)
  • Finally ran zipaes for the first time under Panther (Mac OS X 10.3), and trouble promptly ensued:
    • Fixed an incompatibility in the shell scripts (who would have thought Panther's grep doesn't support the -o option…sheesh!).
    • Passwords typed into DropZipAES dialogs are displayed for all to see as you type them (instead of being masked by • characters as in Tiger). Ah well…it's not like they were all that secure to begin with (see note about setting the use_Terminal flag).
    • So where's the beef? Sometimes the archive file doesn't immediately reveal itself in the Finder after you archive it. Rest assured it's there…it just decided to play hide-and-seek. This seems to be a problem in Panther when you do stuff at the command line level. If you get desperate, try a Find… from the Finder. (If anyone knows a good workaround, please drop me an e-mail).
  • Added request_destination and beep_when_done properties to DropZipAES.
  • Changed the extension from “.zip.aes” to “.zipaes”.
  • Moved DropUnzipAES functionality into DropZipAES. The latter now knows what to do by examining the file names for a .zipaes extension.
  • Fixed a minor problem when archiving multiple files with the -z option.
  • First general release.


zipaes is freeware. It may be used and distributed in its unmodified form, but not sold. You may make modifications to the script for your own personal use, but I ask that you submit to me any changes you would like to see in the public distribution, as it is important to
me to retain version control.


The author will not be held responsible for any data lost or damaged on account of this software. This software does possess the potential to render your data inaccessible. Use it at your own risk.