(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.
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.
zipaes, running either script without any parameters will cause it to spew usage notes to
zipaesnotes sort of assume you have already had a look at the
rdittonotes. I will not duplicate those notes in this documentation, but concentrate more on examples instead.
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
sshconnection 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,
rditto is copying files, it assumes that the last argument is always a
destination directory. Consider the following:
ditto foo bar
rditto foo bar
foointo bar, resulting in
bar/foo. You cannot rename a file as you copy it using
The syntax for specifying files on remote hosts is similar to what you find in other tools like
rsync. These two lines copy a directory called
/foo to and from a remote host, showing the file-by-file progress with
As a rule, you should always end directory names with a trailing slash. There are times when
rditto -V /foo/bar/ email@example.com:/foo/
rditto -V firstname.lastname@example.org:/foo/bar/ /foo/
rdittouses 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/ email@example.com:/foo/bar.zip
rditto -xk firstname.lastname@example.org:/foo/bar.zip /foo/
rdittouses 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
wwwdirectory using ftp. You could post
barto the web by writing something like this:
You could then use either a web browser or
rditto -ck /foo/bar/ "-" | curl -T "-" -u user:password ftp://homepages.isp.com/www/bar.zip
rdittoonce again to download file:
Unlike the regular
curl http://homepages.isp.com/~user/bar.zip | rditto -xk "-" /foo/
(Note: Depending on the ISP, the
~may or may not be necessary.)
rdittoallows you to combine several items into a single archive, as in:
This involves creating temporary copies of
rditto -ck foo/ bar/ foobar.zip
barwhich 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
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:
This should result in
rditto -ck -b ".zip" foo/ bar/ dest/
dest/bar.zip. As you can see,
-bexpects the suffix that goes with the archives.
zipaesis 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
-koption. 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), the password prompt can appear at the most inopportune moment and be obscured by comments.
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
stdin, since that is reserved for the archive data.) You can enter it
directly on the command line or via an environment variable.
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
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/
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
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
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.|
Normally, DropZipAES runs
|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.|
I basically rewrote everything. I had this tool called
rdittokicking around, and it occurred to me one day that I should combine the functionality of
rdittoand it would really kick arse. A lot of the time, I like to archive stuff to another networked computer, and now I can create encrypted backups over there with a single command. How cool is that?
The mind-meld between the two tools inevitably led to some changes in usage, so I'll go over the main differences for those who got used to 1.0.x.
- There is no
unzipaestool anymore. From now on, use
zipaes -cto create archives and
zipaes -xto expand them.
zipaesno longer deals with unencrypted zip archives, except that it can convert between encrypted (.zipaes) and unencrypted (.zip) versions through the
-zoption. All other .zip file operations are handled by
-rno longer deletes the source files. (I found that was a bit too much of a liability.) It only applies to the temporary files, so it is now more like
-tr. Moreover, I simplified the syntax so that you now just specify a score from 0 to 3, depending on how thoroughly you want to the temporary files deleted.
-pnow uses the
opensslcolon-delimited format for password entry.
I will try not to have another big shake-up like that, and apologize for the inconvenience.
This usually means you entered the decryption password wrong, but it could also mean the archive got corrupted.
Yes. They do not check if the destination path is already occupied, so be careful.
I double-quote file paths, so white space characters should be safe, though there may be some special characters like “$” which are still interpreted in special ways by the shell. Also, stay away from the likes of “/” and “:&rdquo. I ran into some file names containing a date of the form “mm/dd/yyyy” which caused me grief. Apparently, OS X turns slashes in the Finder into colons behind the scenes, and
rdittolooks for a colon to delimit the remote host from the path.
In the current implementation, password strings are not quoted (because the quotes were somehow getting incorporated into the encryption keys and causing confusion). This may eventually change, but for now, avoid white space characters and other characters (e.g. “$”, “*”) which might be interpreted by the shell in special ways.
Not directly. You could decrypt the archive first and use
zipinfoto have a peek.(The
zipaes -xz foo.zipaes foo.zip
zipinfo foo.zip | grep -v __MACOSX
grepcommand filters out the sequestered Mac meta-data from the listing, which tends to be a distracting nuisance in this case.)
I don't recommend it. zipaes was meant for smaller data sets you can quickly archive or unarchive in their entirety, so there should be no need to micro-manage the contents. For larger backups, you might consider setting up a disk image with Disk Utility. (These can be encrypted in the same way as zipaes archives.)
Yes. If you are using the
zipcommand line tool, you can specify encryption with
-e. There are two reasons why I chose not do this:
- I am not using
zip, but rather
ditto(so that I can create Finder-compliant zip archives), and the latter does not give you the
- I trust open source encryption algorithms more than proprietary ones, and zip's internal implementations are proprietary. In fact, there are at least two different algorithms in use (depending on whether you use the PKZip or WinZip engine). I just don't wanna go there...