Re: internet voting -- ICANN, SmartInitiatives, etc.
"Steven M. Bellovin" wrote: In message [EMAIL PROTECTED], Ed Gerck writes: Handling bugs is the major problem IMO (looks like we also agree here) after DDoS, privacy, security, integrity, etc are handled (which are not a small task, either). But this might not be so hard after all. Yes, an election is a mission-critical application but it is also a fixed application if you design it well with a database paradigm. The database changes for every election (candidates, offices, etc.) but the software is the same at each different stations (registration, voting, ballot box, tallying, reporting, auditing, etc.). Of course, the software isn't fixed, any more than any other package is fixed. If nothing else, each election will have software that includes the bug fixes and new features added since the last election. The real model for electronic voting isn't Florida, though; it's New Mexico. In Bernalillo County, which used optical mark ballots, the scanner was misprogrammed -- it ignored straight-ticket votes. In this case, once the problem was recognized, the fix was relatively easy -- they corrected the program and rescanned the ballots. If the voting had been online, there would have been no physical ballots to rescan. In 1982 a team of 4 students at Rensselaer Polytech. created a secure voting system. I was one of that team. We had many concerns to overcome, none the least of which was how to separate the vote gathering from the vote tallying. We separated out these functions precisely becase we were concerned about being able to hand-count the votes later. This system wasn't an academic exercise. Rather, it was driven by a desire to demonstrate the ability to apply technology to the campus elections. It worked well. Security was maintained by using physically separate terminals and relying on aspects of the operating system. We're talking 3270-style terminals and an IBM mainframe, for those curious. The terminals can be programmed such that all control comes from the host, making them ideal for the task. In our case, we stored each vote separately in a data file, effectively keeping each person's ballot together. We designed the system to write the files to multiple disk drives simultaneously, so we could compare the data later (and protect against a drive failure). This issue of having ballots available to look at later is important. In the town where I now live, we use traditional paper ballots. I expect it'd be a VERY difficult fight to move from them to ANYTHING automated. And despite having written an early voting system, I still prefer voting on paper. And, elections already use software -- even if you just use punch cards. So, this is NOT a new problem either. In fact, it is worse today because it all closed source software (in the good name of security). Believe me, that software scares me, too... And open source, though a help, is hardly a panacea; finding bugs is *hard*, and testing is not at all adequate. I echo Steve's sentiments here. With the system I worked on 19 years ago, we found bugs in the counting program once we had the final dataset (i.e. after the vote), and had to make some adjustments there. Election officials were in the room watching as we recoded a bit, got access to a newer compiler that didn't have as many bugs in it, and eventually got the results generated. The software continued to be used for quite a few years after that, and each year it'd get tweaked to fix problems, accomodate new ballots, and so forth. Security programming, encryption and transmission are far from the only areas where problems will exist. Election software isn't run often, and it's updated as needed for each election. The disk files we stored had the names of the candidates receiving votes in text, not in binary. As a result, if it'd been necessary, the votes could have been hand-tallied. I doubt I'll be dissuaded from a firm belief in the need for human-readable ballots which can be counted and recounted manually. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com
Re: internet voting -- ICANN, SmartInitiatives, etc.
the bggest problems with security ssytems are generally 90% to do with design errors at level 10 (human, not policitcal, economic, application, transport etc) it would be interestign to run a _real_ experiment in 3 types of voting (comuter based, networked computer based and traiditional) and see if the results came out the same - it should persist for several decades before one could believe that any adaption in the democratic process hd factored in human behavioural bias imho In message [EMAIL PROTECTED], Ed Gerck typed: Kai Henningsen wrote: [EMAIL PROTECTED] (Ed Gerck) wrote on 12.01.01 in [EMAIL PROTECTED]: No. Digital signatures such as X.509/PKIX do violate voter privacy, but never ballot secrecy. In all fairness to you, maybe there is a confusion with the word "privacy". In this case, maybe you write "secrecy" above but you mean "privacy". BIG DIFFERENCE, though. Indeed. The way you have it defined, both are one half of what must be achieved (impossible to identify voters, and impossible to identify votes), with both halves completely meaningless in isolation (which is why a traditional paper vote does achieve the combination, but neither half in isolation). Whereas the way most people define this, the two terms are two names for the same thing, which is the whole (it must be impossible to determine who voted what). The correlation is the problem, not the isolated facts. There is more obfuscation like that in your "16 requirements". Not what I'd consider a recommendation. Unless we define and isolate the concepts used, it is nearly impossible to meaningfully deal with them. This is basic scientific method. Thus, making a clear distinction between "secrecy" and "privacy", as well as between "identification" and "authentication" and "non-repudiation" is at the heart of the matter here. Doing otherwise is obfuscation -- "to make obscure." Safevote's open attack test described at www.safevote.com/tech.htm showed that the following attacks were 100% forestalled during the entire test for 24 hours a day in 5 days: (1) Denial-of-Service; (2) Large Packet Ping; (3) Buffer Overrun; (4) TCP SYN Flood; (5) IP Spoofing; (6) TCP Sequence Number; (7) IP Fragmentation; (8) Network Penetration; and other network-based attacks. Grand. It withstood network level attacks. That's about the most meaningless test possible - all it proves is the quality of the TCP stack, it tells absolutely bloody nothing about the voting system itself. Forestalling Denial-of-Service attacks was unheard of and called "impossible" in Internet voting until we showed how it could be done in one specific network configuration useful for elections in precincts. There are other configurations where it can be done as well, as we shall show in the future. This was one Holy Grail in Internet elections, and we got it. The same applies to other 7 attack types mentioned -- so this was no easy feat for 5 days, 24 hours/day attacks, with full disclosure and a help line. Conclusion of the test: "Internet" does not mean "insecurity". Just because it uses the Internet it does not mean it MUST be insecure. Contrary to lore, Internet communications can be made arbitrarily safe and reliable (Shannon) if you take into account all the systems connected to it. The first step is to recognize that any communication channel has a boundary, which is quite arbitrary. By properly recognizing the sub-communication channels inside a boundary and by properly placing such boundaries, the point I make is that it is possible to have the communication system (roughly): registration -- voter -- ballot box -- tally -- report as error-free, anonymous and secret as anyone else may wish (Shannon). Here, the systems connected to an Internet-base channel are not ignored. They are taken into account and with adequate error-correction channel(s) (Shannon). Again, this is a lot easier in the praxis for precinct-based Internet voting. Which is all we are talking about at this time. Home/office-based Internet voting is IMO too political to be meaningfully discussed at this time. Even though we do have the technological answer for remote voting as well, we would lose too much time in discussing it now. Rather, we prefer to focus on precinct-based solutions, at a fraction of the price of DREs (electronic voting) and with better assurances. Cheers, Ed Gerck cheers jon
Re: internet voting -- ICANN, SmartInitiatives, etc.
In message [EMAIL PROTECTED], Jon Crowcroft writes: the bggest problems with security ssytems are generally 90% to do with design errors at level 10 (human, not policitcal, economic, application, transport etc) Mostly right, though one shouldn't rule out the possibility of layer 10-inspired insider tampering with the software. Nor should one ignore the possiblity of simple bugs -- the electronic equivalent of hanging chad. See http://www.notablesoftware.com/evote.html for more details. But the hard parts of the electronic voting problem have nothing to do with crypto, firewalls, protocols, DDoS attacks and the like -- and I say that as an expert in those fields. --Steve Bellovin, http:/www.research.att.com/~smb
Re: internet voting -- ICANN, SmartInitiatives, etc.
Jon Crowcroft wrote: the bggest problems with security ssytems are generally 90% to do with design errors at level 10 (human, not policitcal, economic, application, transport etc) Explorers of any kind oftentimes are led to believe in monsters at the "end of the sea", but not all of them and so they move forward. Security experts today are divided in two camps. Those many that believe we can never make anything secure and those few that believe we can make a system be as close to perfect security as desired. it would be interestign to run a _real_ experiment in 3 types of voting (comuter based, networked computer based and traiditional) and see if the results came out the same - it should persist for several decades before one could believe that any adaption in the democratic process hd factored in human behavioural bias imho This would make sense in a statistical approach based on frequency of events, where we need many events and even then we are never sure because we did not run an infinite number of tests. So, what you suggest is bound to fail, as a practical matter. Instead, we follow a two-track approach using real-time auditing built into the protocol in a secure zero-knowledge formalism so that auditing during voting neither tampers nor learns anything from the voting process (keys, votes, voter identities, msgs, etc.), and the Bayes approach to statistics, also used by Shannon, where we deal with conditional probabilities in multiple channels of information. In other words, Safevote's protocol provides a neutral observer that goes undetected by all machines (and software) and yet allows all processes pertaining to that observer to be recorded, followed in real-time and fully verified against 100% trusted (yes, such a thing exists and there are many practical ways to do it in elections) records of what it should be. Thus, trust on the election system is earned as anyone can see that the system does exactly what is expected, for a random message, any number N of times. By increasing N, we decrease the probability that an error can occur in N+1, N+2, etc. Key to this method is that it must be fully undetectable by the system, so that the system has no way of knowing whether it is facing a voter or an observer in auditing. There are other auting processes that must be enabled as well and, in fact, auditing must be built-in into the entire system from voter registration to ballot reporting by means of closed loops of trust (not to be confused with closed loops of authorization). Cheers, Ed Gerck
Re: internet voting -- ICANN, SmartInitiatives, etc.
"Steven M. Bellovin" wrote: In message [EMAIL PROTECTED], Jon Crowcroft writes: the bggest problems with security ssytems are generally 90% to do with design errors at level 10 (human, not policitcal, economic, application, transport etc) Mostly right, though one shouldn't rule out the possibility of layer 10-inspired insider tampering with the software. Nor should one ignore the possiblity of simple bugs -- the electronic equivalent of hanging chad. Mostly right also, but it is a bug to say that bugs are somehow equivalent to hanging chads. Dimples, pregnant chags and hanging chads are digitization errors, bound to happen in any process that goes from analog to digital (because a digital process has steps and an anlog process is stepless). So, chad problems are inevitable in any system that uses punch cards to record votes (btw, a technology that was first used in 1890 in the US Census). Chad problems can never be entirely fixed or avoided as long as you have that punch card. Bugs, however, can be either fixed or avoided. So, even though many people like to talk in terms of dumbed down soundbytes, one cannot derive any logical conclusion from such soundbytes. Cheers, Ed Gerck
Re: internet voting -- ICANN, SmartInitiatives, etc.
In message [EMAIL PROTECTED], Ed Gerck writes: Bugs, however, can be either fixed or avoided. This is the fundamental point where we differ -- the former is difficult and itself bug-prone, and the latter is impossible in a system of any realistic size. --Steve Bellovin, http:/www.research.att.com/~smb
Re: internet voting -- ICANN, SmartInitiatives, etc.
"Steven M. Bellovin" wrote: In message [EMAIL PROTECTED], Ed Gerck writes: Bugs, however, can be either fixed or avoided. This is the fundamental point where we differ -- the former is difficult and itself bug-prone, and the latter is impossible in a system of any realistic size. I thought we would differ on how to treat bugs and I am glad we agree (so it seems) that bugs are not the electronic equivalent of chads. In other words, hanging/pregnant/dimpled chads are a problem we cannot solve because they lie at the analog/digital interface and represent the digitization error. But bugs are a problem we can deal with without any fundamental law that says we cannot reduce them. The first problem regarding bugs is, of course, that we do not (usually) know what or where they are. This is another difference to chads, because we know very well what and where they are. Handling bugs is the major problem IMO (looks like we also agree here) after DDoS, privacy, security, integrity, etc are handled (which are not a small task, either). But this might not be so hard after all. Yes, an election is a mission-critical application but it is also a fixed application if you design it well with a database paradigm. The database changes for every election (candidates, offices, etc.) but the software is the same at each different stations (registration, voting, ballot box, tallying, reporting, auditing, etc.). And, elections already use software -- even if you just use punch cards. So, this is NOT a new problem either. In fact, it is worse today because it all closed source software (in the good name of security). This is thus another point for open source and peer review of election software, as I presented to the FEC and at the IVTA, and frequently suggest. My article "Reflections on the August 11th FEC Meeting" was published in The Bell of September 2000, together with two other articles on open source for Internet voting by Thom Wysong and Jason Kitcat. A copy is available at http://www.thebell.net/archives/thebell1.5.pdf Cheers, Ed Gerck
Re: internet voting -- ICANN, SmartInitiatives, etc.
What is it about the IETF list that draws people who demonstrate disinterest in the common meanings of our jargon (e.g. "bug," "denial of service," "digital," and "analog") but nevertheless try to sell us technology** using those words? For example, if Mr. Gerck understood "bug" or "database" as most of us do, he wouldn't talk about a "database paradigm" as a panacea against bugs. He would know that the phrase "database paradigm" is quite evocative, but not in a good way. If he meant familiar things by "digital" and "analog," he wouldn't have said that making a hole in card stock is analog but touching a keyboard or touch sensitive screen is digital. If he were familiar with analog computers, he would not have said that only digital computers have "steps." If he knew what denial of service attacks are, I hope he would not have claimed to have demonstrated a complete defense against them. If hew knew what the open source movement is about and sympathized with it, it should have been possible to decide from his statements if he intends to offer free licenses for his patents or if he is using similar but different words in the hope of selling to people who know only that "open source" is an up and coming buzz word. Or perhaps he is among those who think "open source" is a magic phrase that compels programmers to provide free code reviews, debugging, and enhancements to purely proprietary systems. If he were selling anything I'd want to buy, he would not have equated the effects of bugs in paper ballot counting software with the effects of bugs in completely computerized voting systems. In other words, what can be done to convince Mr. Gerck to stop flooding the IETF list with his advertising and to join Mr. Flemming, Mr. Allisat, and others who are working on IPv8 and other leading edge technologies**? I fear that as long as he continues to get little worse than a lukewarm reception here, M.r Gerck will continue to try elicit responses and that he will report them elsewhere as endorsements. Vernon Schryver[EMAIL PROTECTED] ** by the T word, I mean its primary modern meaning, which is unrelated to its old meaning.
Re: internet voting -- ICANN, SmartInitiatives, etc.
Vernon Schryver wrote: For example, if Mr. Gerck understood "bug" or "database" as most of us do, he wouldn't talk about a "database paradigm" as a panacea against bugs. He would know that the phrase "database paradigm" is quite evocative, but not in a good way. If he meant familiar things by "digital" and "analog," he wouldn't have said that making a hole in card stock is analog but touching a keyboard or touch sensitive screen is digital. I never said what you wrote above. In fact, I might say that you got it reversed in your last phrase. And in everything else. But, the subject in this thread was what the IETF was doing in terms of Internet voting protocols. Attacking me, personally, will not make this thread more interesting, I believe. If we want to use public discussions to mine the gold of truth, then I think that calcite and rhyolite must not be not all that we can get ;-) Cheers, Ed Gerck
Re: internet voting -- ICANN, SmartInitiatives, etc.
From: Ed Gerck [EMAIL PROTECTED] For example, if Mr. Gerck understood "bug" or "database" as most of us do, he wouldn't talk about a "database paradigm" as a panacea against bugs. He would know that the phrase "database paradigm" is quite evocative, but not in a good way. If he meant familiar things by "digital" and "analog," he wouldn't have said that making a hole in card stock is analog but touching a keyboard or touch sensitive screen is digital. I never said what you wrote above. In fact, I might say that you got it reversed in your last phrase. And in everything else. I could quote Mr. Gerck's words to show that he recently wrote each of the things I claimed, but that would bore all of us and convince no one. Mr. Gerck would remain convinced that he has been having a technical discussion and not see how his words might say what most of us understood them to mean. He would honestly not understand why "legacy programmers" are so picky about insignificant technical details and mere semantics. But, the subject in this thread was what the IETF was doing in terms of Internet voting protocols. Attacking me, personally, will not make this thread more interesting, I believe. ... No, this thread has been about advocating Mr. Gerck's products, and as such, has no business here. Discussions about Mr. Gerck's products might but would probably not be appropriate in an IETF Working Group chartered to consider voting protocols. Even if Mr. Gerck were not mistaken about the nature of his comments, they would be inappropriate here. It might be appropriate to consider creating an IETF WG on voting protocols, but as far as I recall, Mr. Gerck has not raised that issue. Perhaps his sense of the likely consensus on that question matches mine. I'm confident that politicians and salespeople will ensure that there is no shortage of forums outside the IETF for discussing on-line voting. Moreover, the focus of the IETF on technical trivia would be incompatible with the needs of almost all participants in those discussions. Vernon Schryver[EMAIL PROTECTED]
Re: internet voting -- ICANN, SmartInitiatives, etc.
In message [EMAIL PROTECTED], Ed Gerck writes: Handling bugs is the major problem IMO (looks like we also agree here) after DDoS, privacy, security, integrity, etc are handled (which are not a small task, either). But this might not be so hard after all. Yes, an election is a mission-critical application but it is also a fixed application if you design it well with a database paradigm. The database changes for every election (candidates, offices, etc.) but the software is the same at each different stations (registration, voting, ballot box, tallying, reporting, auditing, etc.). Of course, the software isn't fixed, any more than any other package is fixed. If nothing else, each election will have software that includes the bug fixes and new features added since the last election. The real model for electronic voting isn't Florida, though; it's New Mexico. In Bernalillo County, which used optical mark ballots, the scanner was misprogrammed -- it ignored straight-ticket votes. In this case, once the problem was recognized, the fix was relatively easy -- they corrected the program and rescanned the ballots. If the voting had been online, there would have been no physical ballots to rescan. And, elections already use software -- even if you just use punch cards. So, this is NOT a new problem either. In fact, it is worse today because it all closed source software (in the good name of security). Believe me, that software scares me, too... And open source, though a help, is hardly a panacea; finding bugs is *hard*, and testing is not at all adequate. --Steve Bellovin, http:/www.research.att.com/~smb
Re: internet voting -- ICANN, SmartInitiatives, etc.
"Steven M. Bellovin" wrote: In message [EMAIL PROTECTED], Ed Gerck writes: Handling bugs is the major problem IMO (looks like we also agree here) after DDoS, privacy, security, integrity, etc are handled (which are not a small task, either). But this might not be so hard after all. Yes, an election is a mission-critical application but it is also a fixed application if you design it well with a database paradigm. The database changes for every election (candidates, offices, etc.) but the software is the same at each different stations (registration, voting, ballot box, tallying, reporting, auditing, etc.). Of course, the software isn't fixed, any more than any other package is fixed. If nothing else, each election will have software that includes the bug fixes and new features added since the last election. Yes in a small part. Elections cannot have added features so easily because the election machines must be state certified (a lengthy and costly procedure) and the ballots must comply to current laws (Palm Beach being the exception that justifies the rule). So, a "vote for one" race or "vote for three" is pretty much the same for almost 100 years now in terms of features and ballot lay-out. And election officials prefer it so -- their mantra (and a good one in this case but not if taken too much to the letter) is "if it ain't broken don't fix it". The only thing that should change is the bug fixes, which should also taper off after a while since there should be no new features driving new bugs. The real model for electronic voting isn't Florida, though; it's New Mexico. In Bernalillo County, which used optical mark ballots, the scanner was misprogrammed -- it ignored straight-ticket votes. In this case, once the problem was recognized, the fix was relatively easy -- they corrected the program and rescanned the ballots. If the voting had been online, there would have been no physical ballots to rescan. Not true, not even with current minimum FEC standards. And note that the draft for future FEC standards for online voting defines online voting as a branch of electronic voting. The point is that what was wrong in New Mexico as you report was the tallying and this could be redone by re-running the ballot images mandated by the FEC to be stored in the ballot box part of each electronic voting machine. If this same requirement is kept for online voting, then remote ballot boxes would hold copies of all ballots and they could be re-tallied with the bug fixed. Once the same type problem is recognized, the fix is even easier since there are no ballots to be rescanned, just re-tallied. Cheers, Ed Gerck And, elections already use software -- even if you just use punch cards. So, this is NOT a new problem either. In fact, it is worse today because it all closed source software (in the good name of security). Believe me, that software scares me, too... And open source, though a help, is hardly a panacea; finding bugs is *hard*, and testing is not at all adequate. --Steve Bellovin, http:/www.research.att.com/~smb
Re: internet voting -- ICANN, SmartInitiatives, etc.
Ed, why do you insist on advertising your patent-pending voting solution on the IETF mailing list? It does not involve any IETF protocol work, does it? --Paul Hoffman, Director --Internet Mail Consortium
Re: internet voting -- ICANN, SmartInitiatives, etc.
Paul Hoffman / IMC wrote: Ed, why do you insist on advertising your patent-pending voting solution on the IETF mailing list? It does not involve any IETF protocol work, does it? ;-) SMTP, HTML, TLS, PGP, and others, including TCP/IP. Pls do not be so bent out of shape by the word "patent". I think we have a fair proposal for it, which we call FREE patent, and is much the same as FREE software. However, I respect your disagreement. Hope we can meet some day. Cheers, Ed Gerck
Re: internet voting -- ICANN, SmartInitiatives, etc.
[EMAIL PROTECTED] (Ed Gerck) wrote on 12.01.01 in [EMAIL PROTECTED]: [long, but worth every megabyte] From: "Stephen Sprunk" [EMAIL PROTECTED] Throwing encryption at voting is not enough to solve algorithmic problems. Digital signatures violate ballot secrecy and provide no protection against most forms of fraud. No. Digital signatures such as X.509/PKIX do violate voter privacy, but never ballot secrecy. In all fairness to you, maybe there is a confusion with the word "privacy". In this case, maybe you write "secrecy" above but you mean "privacy". BIG DIFFERENCE, though. Indeed. The way you have it defined, both are one half of what must be achieved (impossible to identify voters, and impossible to identify votes), with both halves completely meaningless in isolation (which is why a traditional paper vote does achieve the combination, but neither half in isolation). Whereas the way most people define this, the two terms are two names for the same thing, which is the whole (it must be impossible to determine who voted what). The correlation is the problem, not the isolated facts. There is more obfuscation like that in your "16 requirements". Not what I'd consider a recommendation. Safevote's open attack test described at www.safevote.com/tech.htm showed that the following attacks were 100% forestalled during the entire test for 24 hours a day in 5 days: (1) Denial-of-Service; (2) Large Packet Ping; (3) Buffer Overrun; (4) TCP SYN Flood; (5) IP Spoofing; (6) TCP Sequence Number; (7) IP Fragmentation; (8) Network Penetration; and other network-based attacks. Grand. It withstood network level attacks. That's about the most meaningless test possible - all it proves is the quality of the TCP stack, it tells absolutely bloody nothing about the voting system itself. Which in itself tells us something, and it's not a compliment. MfG Kai
Re: internet voting -- ICANN, SmartInitiatives, etc.
Kai Henningsen wrote: [EMAIL PROTECTED] (Ed Gerck) wrote on 12.01.01 in [EMAIL PROTECTED]: No. Digital signatures such as X.509/PKIX do violate voter privacy, but never ballot secrecy. In all fairness to you, maybe there is a confusion with the word "privacy". In this case, maybe you write "secrecy" above but you mean "privacy". BIG DIFFERENCE, though. Indeed. The way you have it defined, both are one half of what must be achieved (impossible to identify voters, and impossible to identify votes), with both halves completely meaningless in isolation (which is why a traditional paper vote does achieve the combination, but neither half in isolation). Whereas the way most people define this, the two terms are two names for the same thing, which is the whole (it must be impossible to determine who voted what). The correlation is the problem, not the isolated facts. There is more obfuscation like that in your "16 requirements". Not what I'd consider a recommendation. Unless we define and isolate the concepts used, it is nearly impossible to meaningfully deal with them. This is basic scientific method. Thus, making a clear distinction between "secrecy" and "privacy", as well as between "identification" and "authentication" and "non-repudiation" is at the heart of the matter here. Doing otherwise is obfuscation -- "to make obscure." Safevote's open attack test described at www.safevote.com/tech.htm showed that the following attacks were 100% forestalled during the entire test for 24 hours a day in 5 days: (1) Denial-of-Service; (2) Large Packet Ping; (3) Buffer Overrun; (4) TCP SYN Flood; (5) IP Spoofing; (6) TCP Sequence Number; (7) IP Fragmentation; (8) Network Penetration; and other network-based attacks. Grand. It withstood network level attacks. That's about the most meaningless test possible - all it proves is the quality of the TCP stack, it tells absolutely bloody nothing about the voting system itself. Forestalling Denial-of-Service attacks was unheard of and called "impossible" in Internet voting until we showed how it could be done in one specific network configuration useful for elections in precincts. There are other configurations where it can be done as well, as we shall show in the future. This was one Holy Grail in Internet elections, and we got it. The same applies to other 7 attack types mentioned -- so this was no easy feat for 5 days, 24 hours/day attacks, with full disclosure and a help line. Conclusion of the test: "Internet" does not mean "insecurity". Just because it uses the Internet it does not mean it MUST be insecure. Contrary to lore, Internet communications can be made arbitrarily safe and reliable (Shannon) if you take into account all the systems connected to it. The first step is to recognize that any communication channel has a boundary, which is quite arbitrary. By properly recognizing the sub-communication channels inside a boundary and by properly placing such boundaries, the point I make is that it is possible to have the communication system (roughly): registration -- voter -- ballot box -- tally -- report as error-free, anonymous and secret as anyone else may wish (Shannon). Here, the systems connected to an Internet-base channel are not ignored. They are taken into account and with adequate error-correction channel(s) (Shannon). Again, this is a lot easier in the praxis for precinct-based Internet voting. Which is all we are talking about at this time. Home/office-based Internet voting is IMO too political to be meaningfully discussed at this time. Even though we do have the technological answer for remote voting as well, we would lose too much time in discussing it now. Rather, we prefer to focus on precinct-based solutions, at a fraction of the price of DREs (electronic voting) and with better assurances. Cheers, Ed Gerck
IVTA, Re: internet voting -- ICANN, SmartInitiatives, etc.
Paul: In the interest of dialogue, I wish to remind you that this thread started yesterday when someone asked what was the IETF doing on voting protocols. Going further back, almost one year ago when the IVTA was to be founded to -- quess what -- discuss Internet protocols (as the Internet Voting Technology Alliance), I sent the following email to this list: / List: Announcement ivta.org Internet voting is a case where privacy must be protected, so that arguments to justify losing voter privacy in the good name of security are simply not possible. Which firmly posits security as a protection of privacy -- not as an enemy of privacy -- in the problem-solving assumptions to be considered. In this context, an international team of experts and companies are calling for open discussions on Internet voting technology. A public founding assembly will take place February 28 in Washington D.C. at 9 a.m. Details at http://www.ivta.org / In the discussion that followed, it was clear that the collective mind of the IETF did not want to develop Internet protocols and that the IVTA was a good move to take such subject elsewhere, to an application-specific forum. Of course, this was all before Florida, when "chad" was likely to be seen as a misspelling for something else. So, there is a forum already for discussing Internet voting protocols -- it is the IVTA. The tech list charter is archived at http://www.ivta.org/tech/charter.txt and the archives are at http://www.mail-archive.com/tech@ivta.org/ Needless to say, the IVTA was founded based on some ideas from the IETF, including open peer review as a mechanism of choice for defining Internet protocols and the idea of favoring consensus building ove rmajority decisions. Cheers, Ed Gerck Ed Gerck wrote: Paul Hoffman / IMC wrote: Ed, why do you insist on advertising your patent-pending voting solution on the IETF mailing list? It does not involve any IETF protocol work, does it? ;-) SMTP, HTML, TLS, PGP, and others, including TCP/IP. Pls do not be so bent out of shape by the word "patent". I think we have a fair proposal for it, which we call FREE patent, and is much the same as FREE software. However, I respect your disagreement. Hope we can meet some day. Cheers, Ed Gerck -
Re: internet voting -- ICANN, SmartInitiatives, etc.
James:
Pls take a look at www.safevote.com -- including
www.safevote.com/tech.htm
Also at www.ivta.org, and www.thebell.net
Cheers,
Ed Gerck
Original Message
Date: Fri, 12 Jan 2001 04:46:30 -0800 (PST)
From: "James P. Salsman" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: internet voting -- ICANN, SmartInitiatives, etc.
X-Loop: [EMAIL PROTECTED]
Was the ICANN election by Instant Runoff Voting or Condorcet?
The terms are defined at: http://www.fairvote.org/irv/
and: http://www.vision25.demon.co.uk/pol/votefaq.txt
It is great it was by were choice ballots. As there seems to
be a renewed commercial interest in election equipment, would
an Internet Voting BOF be a good idea at this point? I would
like to see the IETF take the lead in fraud prevention measures,
and with luck produce some sane accurate advice to balance the
commercial hype that is sure to spew forth very soon.
Here is an interesting effort to use certificate authentication
("digital signature") technology to put California's signature
gathering process online:
http://www.smartinitiatives.org
I think that is a good first step; far better than general
"internet voting" in regular elections, which hasn't been
demonstrated to be more fraud-resistant than absentee paper
ballots by any government that I know of. Are there any such
examples that I just haven't heard of yet?
Cheers,
James
--
The COOK Report on Internet, 431 Greenway Ave, Ewing, NJ 08618 USA
(609) 882-2572 (phone fax) [EMAIL PROTECTED] Index to 9 years
of the COOK Report at http://cookreport.com Why ICANN is illegal.
See 5 page version at http://cookreport.com/illegal.shtml and 168 page
version at http://www.law.miami.edu/~froomkin/articles/icann.pdf
Re: internet voting -- ICANN, SmartInitiatives, etc.
Thus spake "James P. Salsman" [EMAIL PROTECTED]
Here is an interesting effort to use certificate authentication
("digital signature") technology to put California's signature
gathering process online:
http://www.smartinitiatives.org
I think that is a good first step; far better than general
"internet voting" in regular elections,
Throwing encryption at voting is not enough to solve algorithmic
problems. Digital signatures violate ballot secrecy and provide no
protection against most forms of fraud.
which hasn't been demonstrated to be more fraud-resistant than
absentee paper ballots by any government that I know of. Are there
any such examples that I just haven't heard of yet?
The de facto (and in some places legislated) standard for electronic
voting security is the absentee paper ballot. Aside from technical
details, both have the same fundamental problems:
o Ballots are subject to coercion, theft, and sale.
o The voter may not know if the balloting medium is compromised.
o A voter can sign an affidavit and vote again at the polls.
o Ballot secrecy can be broken by government conspiracy.
All of these fraud methods are already available today, and it is
possible to design an electronic voting system which introduces no new
methods. It is also possible to make the first three reversible after
detection, which can't be done with paper ballots now.
Schneier's _Applied Cryptography_ is a good place to start reading up on
secure elections. Alas, the first round of "Internet Voting" being
fueled by California and Texas appears to focus on data encryption and
"secure" hardware, not truly secure algorithms which can be performed in
the clear at minimally-trusted machines.
Cheers,
James
S
| | Stephen Sprunk, K5SSS, CCIE #3723
:|::|:Network Design Consultant, GSOLE
:|||: :|||: New office: RCDN2 in Richardson, TX
.:|||:..:|||:.Email: [EMAIL PROTECTED]
Re: internet voting -- ICANN, SmartInitiatives, etc.
[long, but worth every megabyte] From: "Stephen Sprunk" [EMAIL PROTECTED] Throwing encryption at voting is not enough to solve algorithmic problems. Digital signatures violate ballot secrecy and provide no protection against most forms of fraud. No. Digital signatures such as X.509/PKIX do violate voter privacy, but never ballot secrecy. In all fairness to you, maybe there is a confusion with the word "privacy". In this case, maybe you write "secrecy" above but you mean "privacy". BIG DIFFERENCE, though. Now, my affirmation (and it does NOT depend on implementation) is that Safevote's system uses digital certificates (the DVC) and yet provides fail-safe, absolute protection for voter privacy -- simply because to use the DVC the voter never discloses any identifying information (name, address, etc.) in order to be strongly authenticated in our system. In other words, with the DVC technology even if *everything* fails, *everyone* colludes, there is a court order, still there is no way that we or anyone else can link a voter to a vote. And yet, we can strongly (in mathematical terms) link a voter with the right to vote, with the correct ballot style to be used by that voter and with the vote cast by that voter -- as well as a series of non-repudiation and verifiability proofs in support of auditing. The DVC technology is described in our documentation made public (eg, at http://www.safevote.com/aboutus.htm) and in The Bell newsletter, December edition, copy available at http://www.thebell.net/archives/thebell1.8.pdf in the article on fail-safe voter privacy The de facto (and in some places legislated) standard for electronic voting security is the absentee paper ballot. No. The standard is the FEC standard. Period. Aside from technical details, both have the same fundamental problems: o Ballots are subject to coercion, theft, and sale. o The voter may not know if the balloting medium is compromised. o A voter can sign an affidavit and vote again at the polls. o Ballot secrecy can be broken by government conspiracy. You forgot tampering and other problems. However these are not the most important sources of fraud, in many cases. Fraudulent or mistaken voter registration is, often, the single most important source of problems. All of these fraud methods are already available today, and it is possible to design an electronic voting system which introduces no new methods. No. The use of an electronic voting system introduces software fraud as a new fraud method. There are others, such as virus, weak password compromise, etc. It is also possible to make the first three reversible after detection, which can't be done with paper ballots now. No, again. "Reversible after detection" buys you nothing, because a good fraud is one which is not detected. In any case, in case of detected fraud, there is always the recourse of a new election. Schneier's _Applied Cryptography_ is a good place to start reading up on secure elections. If you want just a one-sided theoretical view of some aspects of voting. Voting is much more complex than most people (and cryptographers) imagine. And, it needs to keep this complexity. For example, with many ballot styles, diverse rules for ballot rotation, provisional ballots, logic and accuracy tests, etc. For example, it is not enough to authenticate the voter, you must also ofentimes authenticate information that depends where the voter lives (encoded in the ballot sytle) -- for example, what school board to vote to. I believe Schneier also needs to rethink his attribute list for voting, as well as his vision that multiple "translation steps" would make errors increase. It is desirable in voting systems that no one could be, at the same time, jury, judge and executioner. Dividing tasks into stages is important to deter collusion, provide auditing trails and allow for the famous "need to know" principle to be applied. When you work with election systems for some time, you also begin to appreciate that open-loop solutions do not work. Printing a piece of paper, expensive at it is, does not provide for closed-loop verification of even simple attributes, for example -- whether the voter received the correct ballot style approved to that voter. Besides, you run the danger that one voter may disrupt the system -- he may declare that the paper does not correspond to his vote, while it does. So, you need a third system, and so on. The solution is to allow for multiple channels of trust, and this is why printing *one* piece of paper simply does not cut it. Voting is also very much like an iceberg -- most of it is hidden from you, until it hits you. In a conventional voting system, the process of registering voters and producing voters lists and/or voter credentials often accounts for more than fifty percent of the overall cost for administering elections. Harry Neufeld, "The Range of Advanced Technologies Available for Election
