It was actually quite simple to switch. DAIMI uses the UW-IMAP server configured to store mails in mbx files which work similar to mbox files except that they contain some extra meta data that should speed up access to them. In my experience it still took the IMAP server 10–30 seconds to look at my 35 mailboxes only to determine that all but one contained no new messages!

I have had great success with the Dovecot IMAP server in the past, so that is what I switched to. It is very fast, easy to configure, and robust. Dovecot can use the excellent Maildir mailbox format which I like because it is simple and fast. Each mail sits in its own file which makes it fast to delete a single message or more it from one folder to another since you don’t have to rewrite a 200 MiB mbx file…

Converting the mbx files to Maildir directories was a two-step process: first I used mailutil to convert from mbx to mbox files:

for f in *; do mailutil -verbose copy $f "#driver.unix/../mboxes/$f"; done

That was done in the root IMAP folder used by UW-IMAP. The result is a bunch of mbox files in a directory called mboxes besides the IMAP directory. Converting these into Maildir directories was done using the mb2md tool. I first converted /var/spool/mail/mg into ~/Maildir:

mb2md -m

I then converted the mbx files in mboxes:

mb2md -s mboxes

It might have been better to use the -f flag which seems to strip out the dummy messages inserted by UW-IMAP. But deleting them afterwards was easy:

rm ~/Maildir/.*/cur/*.000000.*

I first looked at the files with cat to verify that they were all dummy messages. A final problem was the INBOX file which ended up as ~/Maildir/.INBOX where it was shadowed by the normal ~/Maildir/{cur,new,tmp} directories (which represent INBOX in Dovecot). Moving the contents of ~/Maildir/.INBOX/{cur,new,tmp} to ~/Maildir/{cur,new,tmp} makes the old inbox messages visible again.

After the conversion I had a nice ~/Maildir directory which can be read directly by Gnus and other mail clients. But I also want to read it remotely from my home machine. This is where Dovecot comes into the picture — I wanted to use it to present the Maildir as an IMAP server to my Gnus at home. This was very easy:

(setq imap-shell-program "ssh mail.daimi.au.dk dovecot --exec-mail imap")
(setq gnus-secondary-select-methods '((nnimap "daimi" (nnimap-stream shell))))

This makes Gnus connect to DAIMI via SSH and launch dovecot as an IMAP server. Dovecot defaults to look at ~/Maildir so this works out of the box. And it is much faster than the old UW-IMAP server, scanning for new mail now takes about 1 second.

Getting new mail into the Maildir instead of the usual place is a simple matter of making a .forward file:

"|/mail/mg/opt/libexec/dovecot/deliver"

I compiled Dovecot using --prefix=$HOME/opt so its local delivery agent ends up at $HOME/opt/libexec/dovecot/deliver. I actually use maildrop to sort and SPAM check my mail (the DAIMI filter is way to lenient) before passing it on to deliver. But the principle is the same.

What I am missing out on here is the ability to use the webmail interface offered by DAIMI. I mostly used this to check that I really saw all message in Gnus since the old IMAP server would often fail to show me new messages in INBOX. That should no longer be necessary with Dovecot… I guess I could also install my own webmail if needed — it just has to be able to manipulate a Maildir.

For the next release we are working on improving the documentation by using the excellent Sphinx documentation generator. This is the same system used by Python itself and I really like the way it encourages us to write documentation for humans instead of computers. By that I mean that the documentation is more free-form and so you automatically stop writing stuff like

@param share_a: The first share.
@type share_a: Share

which adds nothing to the documentation, except filling out some blanks in the generated API doc.

If you have any ideas for VIFF, then please let us hear! We would love to see more people use it — please tell us what is good and what is bad about the framework.

• VIFF 0.4 was released two weeks ago. It has the usual number of bug fixes and introduces new asymmetric commands. This means that you can write MPC programs where only a subset of the players give or receive output.

• Mercurial 1.0 has been released! I have been a happy Mercurial user for about a year now, and I must say that I’m very impressed with the speed and flexibility it offers. Subversion was simpler and cleaner than CVS, and Mercurial is even simpler, yet more powerfull. I strongly suggest that you consider using Mercurial for your next project, it is already used by large players like Mozilla and Solaris.

• Twisted 8.0 is also freshly released. We are using Twisted in VIFF, and I have been very happy with it. The Twisted code has this nice property that when you read it you realize that there is no magic going on and that things are generally written the way you would expect them to be.

Happy hacking!

You can download VIFF from http://viff.dk/.

Implemented overloaded arithmetic operators, so w = x + y * z now adds and multiplies the three shares as expected. Updated API documentation. Released using a Distutils setup.py script.

Get it at http://viff.dk/

I packaged things up in a 0.1 release — VIFF is now online at http://viff.dk/ with the Mercurial repository at http://hg.viff.dk/viff/. If you are interested in the development of VIFF, then consider subscribing to new releases on Freshmeat. There will be a mailinglist up as soon as Gmane approves my application, stay tuned!

A week ago I asked you to help me find a name for a project I am working on. The project is a library of tools for writing secure multi-party computations in Python, and thus I have been calling it PySMPC until now. But since the project might one day be rewritten in another language, I would prefer to have another name.

Tord, Dan and Chris suggested new names, and including the ones I had come up with myself, we now have (in alphabetical order):

• AMPC: Asynchronous Multi-Party Computation, 1 vote
• AntiTrust
• DTTP: Distributed Trusted Third Party, 1 vote
• Jokke: no idea what that would mean, but Rune votes for it. 1 vote
• NoTrent
• NoTTP: No Trusted Third Party
• NoTrust
• PEBLE: Paranoid Economy Benchmarking Liability Elimination
• SMPC: Secure Multi-Party Computation, 2 votes
• smpacman: secure multi-party comp. manager, 1 vote
• Trent
• VIFF: Virtual Ideal Functionality Framework, 3 votes (give or take an ∞ or two…)

Please vote for your favorite name (multiple votes are okay) by leaving a comment.

It is a library which enables you to write multi-party computations (MPC) in an easy way. A secure MPC protocol is a protocol between a number of players who seek to execute some joint computation, but done in a way in which they reveal nothing about their inputs. If the computation is the evaluation of a function f, then imagine each player Pi holding an input xi. When the protocol is finished, all players must know y = f(x1, x2, …, xn), but nothing more.

As an example where MPC is helpful, consider a bunch of companies that want to know how they compare to each other. So they want to compute their average profit, but are of course unwilling to share the private information about their expenses and incomes. This is the problem of benchmarking and traditionally this has been solved by having the companies reveal their sensitive information to a mutually trusted third-party. This could be a consulting company which has been paid so much money by the benchmarking participants that they can trust the consulting company not to cheat (the companies have essentially bribed the consulting company to be honest).

Paying a third-party so much money that he or she has no incentive to collude with a player is of course an expensive option. A secure multi-party computation can do the same, but without a trusted third-party. The protocol is designed in such a way that it acts as if there was a trusted third-party, a so-called ideal functionality present. An ideal functionality (IF) should be thought of as a computer which cannot be hacked and which faithfully carries out the program put into it. The players can therefore trust this computer and should simply reveal their private inputs to it.

In real life there is not such computer, but the MPC protocol creates a situation that look exactly as if there had been. This is the definition of security: the real protocol must look exactly as a protocol done in an ideal world. Because no attacks can occur in the ideal world (the IF cannot be attacked by definition) then we conclude that no attacks can occur in the real world as well. And so the protocol is called secure.

My library is written in Python and program written using it looks like this:

import sys
from X.field import GF
from X.config import load_config
from X.runtime import Runtime
from X.util import dprint

Z31 = GF(31)
my_id, conf = load_config(sys.argv[1])
my_input = Z31(int(sys.argv[2]))

rt = Runtime(conf, my_id, 1)
x, y, z = rt.shamir_share(my_input)
result = rt.open(rt.mul(rt.add(x, y), z))

dprint(”Result: %s”, result)
rt.wait_for(result)

This program starts by including some stuff from X, which stands for the package name of my library. It is this X that I want to see replaced by something else. The program then defines a field for the computation, loads the configuration and input. A Runtime is then created. The Runtime is used for all computations, it has methods for addition, multiplication, comparison and so on. In this example we compute (x+y)*z. The result is opened, printed and finally we ask the runtime to wait for the result.

The last point where we wait for a result is necessary since my library is asynchronous. The wait_for method goes into an event loop and only returns when the variables given have received a value. I use Twisted for the asynchronous infrastructure and it has worked extremely well.

So, if you’re with me so far, then you should have at least a rudimentary knowledge about MPC and what it is good for. I have already some name suggestions and I hope to get some feedback on them (listed in no particular order):

• NoTTP, short for No Trusted Third-Party. This is what MPC does: it removes the trusted third-party. But does it look good if you write from nottp.field import GF256? Also, the name almost sounds like NoTCP which could be some weird project that loves UDP :-)

• PySMPC, short for Python Secure Multi-Party Computation. The library is written in Python and does SMPC. One might drop the “S” and go with PyMPC since nobody wants to deal with in-secure MPC anyway :-) I don’t like that the name ties the library to Python since I might want to rewrite it in another language in the future.

• Trent or NoTrent. Accourding to Wikipedia, Trent is sometimes used as the name of the trusted arbitrator in cryptographic protocols (like Alice and Bob is used instead of A and B). So this library could be said to give you a virtual “Trent” and help you get rid of a real one. I don’t like the word “Trent” since I don’t think it is that widely used.

• VIFF, short for Virtual Ideal Functionality Framework. The library helps you create protocols that look exactly as if there has been an IF present. Therefore I think it can be said to create a virtual ideal functionality. Accourding to Google, VIFF mostly stands for “Vancouver International Film Festival“.

• AMPC, short for Asynchronous Multi-Party Computation. This emphasizes the asynchronous nature of the library. I think it is somewhat difficult to pronounce “AMPC”.

Any other suggestions? Which name do you like the most? Please vote by leaving a comment! (Those of you who already know the name I have used so far are kindly asked not to reveal it — I want to collect some opinious first.)

By the way: instead of the abbreviations, I would prefer a name like “Twisted” or “Python” which can be pronounced and which people know how to spell and capitalize. There is another project in this area called FairPlay and I think this is a very good name: easy to remember, it can be abbreviated to just FP, and it actually says a bit about the project. So if you could suggest something along the lines of that it would be great! :-)

We tried a lot of different small cars, and the Colt was the one that fitted our needs and budget the best. It comes with three years of insurance for only 6,900 DKK ($US 1,300, 925€) which is very cheap in Denmark for first-time drivers. The normal prices are around 10,000–15,000 DKK per year.

Now we just have to wait nine days… I’m so looking forward to it!

I’ll put the pictures up somewhere later — for now the “preview” on the right will have to make do. Thanks again to everybody for all the presents, thanks for being there and celebrating with us!