Zephyr at MIT doesn’t support* limiting who can sub to a zephyr class, so if you want to have reasonably private conversations, encrypting them is a good idea. zcrypt is the standard tool for that.

zcrypt encrypts message bodies, but not the message metadata. In particular, instances are visible to anyone who receives a message (as are senders, times, zsigs, etc., though that’s less-frequently an issue).

Creating a zcrypted zephyr class

The main requirement for a zcrypted zephyr class is to distribute a key to all the intended users of the class. Typically, this is done by storing the key in AFS. You can set that up like this:

# Pick an arbitrary label for your class.
mkdir -p ~/Public/zcrypt/label/
# Keep randoms from reading your key
fs setacl -dir ~/Public/zcrypt/label/ -acl system:anyuser none
# Allow an appropriate user/group to read the key
fs setacl -dir ~/Public/zcrypt/label/ -acl system:groupname read
# Generate a 126-byte key with no NUL or newline bytes
tr -d '\000\n' < /dev/urandom | head -c 126 > ~/Public/zcrypt/label/key.zcrypt

The first three lines create a directory to store the key, and set the permissions properly. You should replace label with an appropriate name; you may want to use something besides the class name in order to help keep the class name private. Subbing to the class will disclose traffic patterns and instances used, so you may want to use the traditional “secret class” (keeping the name secret) as a first line of defense, in addition to zcrypt.

The last line creates the key, which should be a random byte string of at least 126 characters, none of which should be null or newlines. (Nulls and newlines terminate the key, so if /dev/urandom happens to give a null or newline early (which is certainly plausible) you could end up with a much weaker key than you expected.)

Subbing to a zcrypted zephyr class

This may vary between clients. For traditional zephyr clients, you should sub as usual (in BarnOwl, run :sub classname, or edit your .zephyr.subs file, then run :loadsubs in BarnOwl).

You should also have been told a key path. In the example above, that would be /mit/user/Public/zcrypt/label/key.zcrypt (where user is your Athena username).

You can configure the key by running

echo "crypt-classname: AES:/mit/user/Public/zcrypt/label/key.zcrypt" >> ~/.crypt-table

Replace classname and the path appropriately. (You can also leave off “AES:” to use the key with 1DES, but that is very weak, and should not be used in new classes.)

* This is only mostly true. Zephyr supports limiting who can sub to zephyr classes, and Moira has support to control zephyr’s support. However, there’s no self-service support for setting up ACL’d classes, and I don’t believe anybody with the relevant bits is interested in setting up classes for student groups or similar uses, so the technical ability isn’t practically useful.