I spent this past Thursday and Friday meeting with Andy Neff of VoteHere. We discussed the details of his latest ideas for verifiable voting, and he asked me to help him with the write-up and framing of the issues. These will all be published in the near future, just like the rest of Andy’s protocols and code.

Over the next few weeks and months, I’m going to dedicate this blog to explaining why this is a big deal. The short story is this: for a few years now, cryptographic voting has theoretically promised a radically new type of election. An election where you, the individual voter, can verify that your vote has been counted correctly. Not just recorded correctly. Counted correctly. All the way from filling out your ballot to generating a tally. The problem is, this level of verifiability has been, historically, prohibitively inefficient and simply too difficult to use. Andy’s earlier work (2001) addressed the efficiency issues. Andy’s latest ideas address the usability issues. Truly verifiable elections are now a very real possibility.

More on this in the next few weeks. For now, what’s needed is complete disclosure, because I suspect my writing will ruffle some feathers. I have no financial interest in VoteHere. I have never been offered financial interest in VoteHere, and, if it were to be offered, I would refuse it. I welcome any challenge to these ideas. I encourage readers to keep an open mind and ask questions, either via comments or private email.

As a final note for now, here’s the email I sent yesterday to Andy and Jim (VoteHere’s President):

From:    ben
Subject: Thoughts on my visit and what comes next
Date:    December 10, 2005 1:04:55 PM EST
To:      Andy, Jim

Andy, Jim,

Thanks for having me over these past 2 days, it’s been a fantastically interesting time. I want to restate that I find Andy’s latest stream of enhancements fascinating and impressive. Each is independently impressive, but taken together, they amount to a real revolution in voting. I’m excited about what you’ve accomplished, and I would like to help get the word out about my most important conclusion: as of Andy’s latest improvements, I believe cryptographic voting is now truly usable and, thus, inherently superior, in every respect, to other voting techniques. What is needed now is significant work in explaining this to the research and election communities.

I think it’s going to be very difficult. It has been, and it will continue to be. This is an enormous education project, one that entails explaining to many truly well-intentioned people that their intuition about technology and information is wrong. The only way to accomplish this is through extensive education at all levels, a great deal of patience, and an extreme amount of openness. The critics must be answered carefully and patiently. There’s nothing to fear about this public debate, because the facts are on the side of cryptographic voting.

In the spirit of openness, I’m going to begin blogging my thoughts publicly at http://benlog.com. I will be fully upfront about the facts and my motivations: I believe cryptographic voting is the best way, by far, to give voters confidence in the system. The facts are that you guys paid for the bare essentials of my trip out to Seattle (

Also important is that, if I believe you guys are in the wrong at some point, I will state so without restraint. Alternatively, if another company or research group comes up with similarly powerful technology, I will endorse them as much as I endorse you. Of course, none of this should come to you as a surprise, because I will always be upfront with you, too.

There is an opportunity here to revolutionize the verifiability of our voting systems and the confidence of the electorate in their democratic process. This opportunity requires careful and open collaboration, because the critics will be harsh, numerous, and unfair. At the same time, the potential benefit of this technology is too fantastic to pass up.

It behooves us to teach others and to get the word out. This is simply too darn important.

-Ben

PS: feel free to forward this letter to fellow employees. I will also post it on my blog.

UPDATE: I edited the email addresses in the email above so that they wouldn’t be available to spam crawlers.

People are in shock that Sony is effectively installing spyware to help them in their DRM effort. How dare Sony surreptitiously install a program on your computer that effectively overrides the operating system’s default behavior when reading CDs? Haven’t they gone too far?

Yes, of course they went too far. But the line was crossed years ago, when the entire concept of DRM for personal computers was broached. After all, DRM is about control. More specifically, DRM is about taking control away from *you*, the user. Using spyware/malware/unintended-ware to implement DRM is just a slightly different tactic in the grand scheme to enforce the entertainment industry’s wishes. The Two Laws of DRM, if you will:

First Law of DRM: A computer will not violate its manufacturer’s orders, or, through inaction, allow its manufacturer’s orders to be violated.

Second Law of DRM: A computer will follow its user’s orders, except where those conflict with the First Law.

Is there room in the world for this “trusted computing” (where “trusted” means the manufacturer trusts the machine)? Of course there is. Hospital computers should keep medical records safe and disallow sharing of such records with computers that are not DRM-enabled. Voting machines should boot only voting software. ATMs should authenticate as official ATMs when connecting to the banking network.

But in all of these cases, there’s one salient fact: the machine does not belong to the user. The machine is there to serve a higher purpose. It’s the hospital’s data vault. It’s the enforcer of democracy. It’s the bank’s teller. It’s never the user’s machine.

So why are we surprised by Sony’s actions? DRM is about making your computer a tool of the entertainment industry. It no longer serves you, it serves the content distributors.

And the question we must ask is simple. Who should control your home computer? You, or the manufacturer? You, or the entertainment industry?

Voting is terribly hard to administer.

I voted yesterday in Boston. I was handed voting lists by partisans about 50 feet outside the voting location, which is technically illegal. Once I came into the voting location, the overeager voting administrator confiscated my “voting paraphernalia,” even though it’s technically perfectly okay for me to come in with a voting list of candidates I’d like to select. Meanwhile, as I voted, the TV was on in the polling station, so poll workers could watch the talk shows. And of course, my name was checked off both lists at the same time, rather than once at the entrance, and once at the exit.

Meanwhile, Arnold Schwartzenegger almost had to vote provisional. Why? Because someone had used his name during the testing phase, and had forgotten to “cancel the transaction.” How many other voters had the same problem? How many of them had the courage to stand up and say this was a mistake?

This is difficult stuff. It probably always will be.

So, it’s time I begin describing the work my research team (Susan Hohenberger, Ronald L. Rivest, and myself) has been doing to fight phishing attacks (and maybe even spam). Over the next few posts, I’ll describe the building blocks, and eventually piece them together into a solution. Feel free to ask questions in comments or by email.

First, let’s talk about the overall problem and high-level approach.

Email isn’t trustworthy. When you receive email, you have no way to verify the authenticity of the sender’s address. That leads to a number of forms of anonymous spam (the kind you can’t complain about or unsubscribe from), and, most importantly, to phishing attacks, where the sender address is spoofed so as to mislead you into revealing confidential information (like your password). One obvious solution is to find some mechanism to authenticate this sender address. The not-so-obvious part is: how? Though we’ve known how to do digital signatures for more than 20 years, we still don’t have an easy mechanism that is truly deployable on a large scale. Most approaches require establishing a public-key infrastructure, where each user is responsible for generating a personal key and getting it certified. That generally requires significant user education and effort – and in the realm of security, where the payoff is only clear once the damage has been done, that education never happens in time.

A number of people will tell you that, even if you can authenticate an email sender, that’s not enough, because someone could send you email from “b1gbank.com” instead of “bigbank.com” (notice the “1″ instead of an “i?”), and though the email will be authentic, you’ll still be fooled. That’s true. Email authentication is not enough to stop phishing and spam. But it is necessary. Not sufficient, but necessary. Email authentication can provide the basic platform of trust for email, much like SSL provides a platform of trust for the web. Once this platform is established, a number of reputation-management systems can be deployed to help users make that final trust decision. But without the platform, there can be no such reputation management. We need a platform of trust to provide basic accountability for email.

So our goal is to provide this platform of trust. We’re not trying to be 100% secure. We’re trying to be “just secure enough” to prevent email-based phishing attacks. Our solution isn’t appropriate for authorizing nuclear missile launches, but of course, most users’ email hardly ever needs to be.

In the end, our solution is very simple: we make it such that, if you want to successfully authenticate your emails as coming from “alice@wonderland.com,” you must be able to receive emails sent to “alice@wonderland.com.” Sound familiar? It should. It’s the same mechanism that numerous web sites use to authenticate you the first time you register for an account or when you lose your password: they just send you an email. Conceptually, our solution is quite similar. At a lower level, it’s much more powerful. We use cryptography to (1) capture Alice’s ability to receive email at a given address and (2) prove to another user, Bob, that she has this ability. And we do it without any extension to SMTP, the mail protocol. Deployment can happen at the client level (upgrade Outlook), OR at the server level (upgrade qmail, sendmail, exchange), which means it’s compatible both with web-based email providers and with mobile users accessing their mail from a heavily-firewalled place like China.

So, to summarize:

• we need to authenticate emails to provide a basic platform of trust.
• we’re going to provide this by tying email authentication for an address with the ability to receive emails at that address.
• our solution requires no significant change, and is deployable today at the client or server level.

In my next post, I’ll describe Identity-Based Signatures, a super-cool crypto concept that is the key (no pun intended) to our solution.

Four weeks ago, a few fellow crypto people from MIT and I wrote a letter to the Dean of the MIT Sloan School concerning the applicant hacking incident.

The Dean answered. So we wrote back. And he wrote back. And the discussion was quite interesting. I fully admit that I was surprised: I didn’t expect the Dean to take as much time as he did to answer as thoughtfully as he did. And it’s not like we agreed in the end, either. We ended up disagreeing on the notion of notification of private online spaces. That said, one thing is clear: MIT Sloan did not make this call lightly, and as much as I continue to strongly disagree with their decision, I also strongly respect their decision process.

At the very least, this was a victory for honest and open debate. You can read the entire exchange.

By now you’ve probably heard about Harvard, MIT, and Carnegie Mellon business schools rejecting MBA applicants who “hacked” into the admissions web site to see their acceptance status early. The problem is, what they did amounts to little more than curious exploration, not hacking: they just twiddled a URL on a horribly insecure web site.

A few members of the Crypto Group here at MIT wrote to MIT Sloan to explain how qualifying this as hacking is dangerous and erroneous. After all, if an admissions staff member mistakenly posted the results in a public hallway, students would hardly be held responsible. The web is no different.

My sister just got me an iPod Shuffle for my birthday, which is really nice. I’m surprised by how light and convenient it is. For all of those people who are worried about using an ipod for working out, this is your solution.

But it got me thinking. If this iPod does on-the-fly decryption of DRM’ed songs like other iPods, then it’s got enough computing power to perform AES encryption. It’s got its own input mechanism (those buttons). Of course, it has no display, but maybe that’s not immediately necessary.

How about storing your private key on your iPod Shuffle, where the key is unlocked by a secret sequence of button presses? This may be the tiniest and cheapest secure storage device out there. 512 megs of secure storage with trusted inputs. I wonder how difficult it would be to write new firmware for this functionality….

So it seems the Napster “music for rent” DRM scheme has been broken. This is not surprising. Apple’s iTunes was broken with PlayFair a few months after launch. In general, DRM is breakable on any hardware that doesn’t have a trusted computing element to it. And that’s a good thing, but it’s not what I want to discuss right now.

Instead, let’s look at why this is a bigger deal than Apple’s break. Let’s examine why, even though Apple’s iTunes DRM is not exactly bulletproof, users aren’t rampantly breaking it, while Napster may not be so lucky. It’s about user expectation.

What Apple did right is build a system that users understand. You buy a song, you “own” the song. After you’ve paid your 99 cents, you can play it just about anywhere you’d like. You can burn the song a large number of times, large enough that most people will never hit the upper limit. You can download it to as many ipods as you’d like. And you can share the song between up to 5 computers. What that means is that most users are never stifled by the DRM.

On the other hand, Napster’s rental model claims that you can listen to all the songs you want for $15/month. Until you stop paying, that is. And that’s just not what users expect. The idea of a music subscription fee is simply not mainstream. Some people like it, but they are in the minority. So when Bob realizes that he must continue to pay up forever or lose his entire music collection, he’ll find a way around it. He’ll download the software that hooks into his sound card and rips the DRM right out. And he won’t feel all that bad about it, either, because darnit it’s his music and he paid for it.

Maybe one day we’ll all be paying subscription fees for everything we do. But so far, the buy-and-own music model is the dominant mindset. People fondly remember the first CD they ever bought. Doubtful that they’ll ever remember the first CD they ever rented.

Bloggers – Atrios and Kos – are upset about an optical scan failure in Daytona Beach, Florida.

In fact, you have to give credit to the election officials who did exactly the right thing. With tens of thousands of voting machines out there, some are bound to fail. Apparently, as soon as the election officials detected this failure, they did exactly the right thing: they contacted party representatives and proceeded to secure the ballots. They then recounted the ballots with party representatives present.

What more could you ask for? This is exactly what you want election officials to do in case of failure. And certainly, as Atrios at least points out, it would be much worse with a non-paper electronic voting machine.

Now, the questions to really ask are: what allowed the officials to detect this failure? Are election officials at all polling locations given information on what red flags to look out for? In other words, were we just lucky to detect this failure, or is there a good process in place to detect these failures with high probability? That’s really what the press should be looking into.

CNET reports that voters are not worried about voting machines, but experts are.

Some people are using this observation as an excuse to dismiss the worries of security experts. To paraphrase Avi Rubin, it makes about as much sense to ask voters what they think of election machine security as it does to ask patients what they think of various artery graft options in heart bypass surgery. If you want an expert opinion, ask the doctor, not the patient.

However, that’s not to say CNET’s report is useless. The voter’s perception, like the patient’s, is tremendously important. A democratic election can only succeed if it is actually secure and if it is perceived to be secure. The question to ask is: why have the experts been unable to communicate their worries to voters?

I don’t have a satisfying answer to that question. Surely, part of the problem is that security experts are sometimes not very good at marketing their ideas. Another part is that certain vendors are spending much time and money convincing people that their machines are secure and no further discussion is required. Yet another part is that the security issue has become entangled with the voter disenfranchisement issue, because the new, worrisome machines also happen to be the machines that, for the first time, provide people with disabilities the ability to vote on their own.

All of these issues can be resolved in time. One issue, however, will probably always haunt the election problem: people don’t understand security. It’s part of the reason why auto insurance is legally mandated. If it weren’t, many people simply wouldn’t get it because the risk/protection tradeoff is not a natural connection to them.

Whatever opinion one holds about voting machine security, let’s remember one thing: voter opinion on voting security matters as an indicator of how well experts are doing their job, not as another input into the security debate.