Post

First, this is really unfortunate, and I feel really bad. Sure, you can say "the trustee should have saved their secret key", but ultimately, as a system designer, I want my systems to be resilient to human mistakes. To be human is to err. Although, it's really hard to strike the right balance.

If you want voter privacy, even from me, the administrator of the Helios server, you need to use strong encryption on the ballots – in fact you need a special form of encryption that allows for accumulating votes under the covers of encryption.

1 repost10 likes

And then you need to manage how the decryption of the tally is performed, and the only way we know how to do that reasonably well is by having a set of trustees where no single individual can go rogue and break privacy. But there's a very specific design tradeoff here.

Do you require all trustees to be present for decryption, or do you tolerate a minority of trustees to be absent? For resilience, it seems clear you should tolerate some trustees being absent. But that complicates the setup process: all trustees need to log in once, then a second time.

And of course this is where designing Helios for different audiences is really tricky. Some users, like the IACR, are super expert and they can go through the complex setup process. Other users don't even understand what a key is.

I used to regularly get emails saying "I lost my private key, can you send me a new one?" But ... that doesn't work. So I made the trustee function really scary. By default, Helios manages the key, and privacy is not as strong. There's an ugly scary popup if you try to set up trustees.