Would a 20'F temperature differential be the only factor in determining the forces involved? Seems to me it might be offset by the fact that colder air would have a tendency to be denser, thus potentially offsetting your figure of 16,000lbs...
Um, it's the greater density of colder air that *creates* the lift.
If you're upgrading a database that has been used with a previous version (which required the database to use the latin1 character set), you need to fix your database.
Not exactly. The various MythTV binaries are supposed to cleanly update any 0.21 database to 0.22. The character set conversion issue described on that page is due to the default MySQL settings as shipped with Gentoo.
With MythTV 0.22, the database is expected to be configured with the UTF-8 character set. If you're upgrading a database that has been used with a previous version (which required the database to use the latin1 character set), you need to fix your database.
I would guess that if you're using MythTV as packaged by a major distro, by the time your distro delivers 0.22 it will probably handle the character set conversion automatically.
Stringing many miles of additional wire costs more, particularly since the fact that the power company owns the wire doesn't do anything to eliminate the need for proper protection of data or authentication of commands delivered over it.
Yep. We lost the terminology war a decade ago. It's time we deal with it.
Whatever. Language is context-sensitive. I have no problem with the media using the term one way while I use it another. For that matter, I use the word both ways, depending on who I'm talking to.
So is this basically assuming that the Q table will never get leaked? *confused*
Very good question. It took me some time to dig into it to figure out the answer.
The answer is yes. The system assumes that the full contents of the tables will never get leaked. Table P is never revealed at all and table Q is partially revealed according to a specific scheme. Access to the full contents of Q, R and S allows the reconstruction of P. Access to P reveals the structure of all ballots.
Improper access to the contents of the tables, plus access to a voter's verification codes reveals who that voter voted for.
The authors' solution to this is in assumption 5 of section 5.2.1: "Election officials use a special trusted computer workstation (as described in [14]) to enforce the privacy of the tables of confirmation codes."
The secure diskless workstation mentioned in [14] is adequate for a university election, but in my opinion it's insufficiently secure for an important election. However, I think that an adequate machine can be built, and I build high-security cryptographic key management systems for a living. The same techniques and approach used to protect the master cryptographic keys that protect hundreds of billions of dollars should be sufficient.
My recommendation would be to use something like an IBM 4764 cryptographic coprocessor -- or any other programmable FIPS 140-2 level 4 certified device. Use it to generate P, and program it to output P for external storage (because P is likely too large for internal storage) only in encrypted form. Likewise with Q. The selective revelation of Q should be done by the secure device, with an external input providing the "coin flips".
The source code for the device should be open source and published, and the binary should also be published. The 4764 already includes a very clever and very secure mechanism for incrementally loading verified software, starting with a dead simple boot loader which is trivial to verify and produces hashes of each further loading stage. Loading should be done under oversight by all interested parties.
If generation of P is done by a deterministic PRNG, then you can have P generated in parallel by multiple identical devices, one under the control of each major party and perhaps a watchdog group or two as well, and all can verify that the encrypted version of P is identical. The way to do that is to start with one device and then use a secure clone operation to replicate the master key and the PRNG seed from one device to another.
Even though the devices are highly, highly resistant to penetration (millions must be spent in multiple serious attempts to penetrate a device in order for it to achieve level 4 certification), all parties operating such a device must allow oversight from any other interested parties. This is also necessary to ensure that no unauthorized clones are created -- though the software should make use of the device's hardware "security ratchet" to ensure that once put into the "generate P" mode, the cloning functionality is disabled.
After the partial revelation of Q (done in parallel), all of the devices should be breached, in public, under oversight, which will cause them to destroy their master keys. The devices should probably also be publicly destroyed.
The final potential weakness is pre-tampering with the devices. If the device could be subverted even before the first software is loaded, then all of the security disappears. Manufacturers of such devices take great pains in the manufacturing process to be able to prove that they produce reliable devices, but those measures are insufficient for something like a major election.
I think another iteration of the cut-and-choose style verification Chaum is so fond of is the solution. Or in this case perhaps it should be called 'choose and cut'. The election officials should de
If the fake ballots don't have the codes in the order specified in the S-pointer column of the Q table, then the votes would in fact get redirected to different candidates. However, those ballots would be identified as fake by any of the ballot audits, whether the audits done pre-election, post-election by voters, or post-election by poll workers.
I wish I could say you're wrong, but you're not. Not only is there the issue you mention, that it may be harder for the family of the intruder to sue than the intruder, but if the civil jury finds against you the damage calculations are likely to be much worse if the intruder lived.
The reason is that when someone dies, damages for the wrongful death are calculated based on what that person could have earned had he not died. In the case of most burglars, that's not much (relatively speaking). But if he lives, then damages are calculated on a more subjective scale based on pain and suffering inflicted. When the result of the shooting is that the intruder will be in severe pain the rest of his life juries award crazy sums.
Luckily, I live in a state with a "Castle Doctrine" law that states that if someone breaks into my home and I reasonably believe he's there to harm someone or to commit a felony (like burglary) then whatever response I take is presumed to be "reasonable" for purposes of both criminal and civil cases. The burden is then on the plaintiff to prove that my action was unreasonable.
Still, civil liability issues aside, I'll stick with the ethical standard. I'd rather have the jury take everything I own than to have to live with having executed a man in cold blood just to avoid a civil suit.
What defines a "widespread pattern of errors?" In small elections or close elections, changing a small fraction of votes could affect the outcome.
The use of the three-letter codes allows most errors (whether deliberate or accidental) to be weeded out because the odds of accidentally providing a valid code are small. The remaining complaints are called "plausible discrepancies" and the paper explains how to calculate an appropriate trigger threshold, based on the number of plausible discrepancies vs the total discrepancies, the number of candidates, the size of the code space and the degree of certainty required (which is dependent on the closeness of the race). If the trigger threshold is exceeded, then there is evidence of systemic failure and an investigation is required.
A three digit code is probably adequate, but I'd have probably opted for a longer value. It depends on how the code is used and what it represents. I'm assuming it represents a given candidate, as you're unlikely to have more than 1000 candidates for a given district but will likely have more than 1000 voters in a given voting station.
The three-digit code doesn't represent a given candidate, except on a given part of a given ballot.
Suppose that the ballot had only one race (any more complex ballot can be decomposed into a set of such simple ballots, so this assumption doesn't limit generality). Each slot in that ballot, corresponding to a candidate, has a three-letter code, which is only revealed to the voter when he or she selects that candidate. That same set of three letter codes, but WITHOUT any association between code and candidate, is a row in table "Q".
After the election, you can look up your ballot on-line and it will show you all of the three-letter codes that were on your ballot. You verify that the one you revealed is in the list.
But what if it isn't? That's when you come forward to say there's a problem. There are two basic possibilities: either you are wrong or the system is wrong. Either possibility could come about through either error or malice. If you made a mistake, or invented a code, the probability that your erroneous or invented code is in the list for your ballot is determined by the code length. The three-letter codes were chosen because they make that possibility sufficiently small that few voter errors will go undetected. A statistical model is used to decide when those that do (called "plausible discrepancies") are numerous enough to indicate a likelihood of system error/fraud.
Of course with a little help from your local ISP, they can see who is viewing what ballots, tie that to an IP and an IP to a home or in some cases a specific user.
True. There are some protections against this loss of anonymity, though.
First, only voters who choose to verify have any risk, and of those only the ones who choose to verify from a location that can be connected to them. Since only a tiny percentage of voters need to verify in order to statistically exclude the possibility of ballot loss or alteration, you only need a small number of people willing to take the "risk".
Second, it's only possible to match voter with ballot if you have possession of the physical ballots. The system is designed so that no one needs access to the full set of ballots after they've been scanned. Verification of the integrity of both counting and collection can be done without access to the ballots. Some verification of cast ballots needs to be done, but that requires only small sample (at most a couple thousand randomly-chosen ballots).
You want to have it so no one holds all the data so correlations can't be made without everyone being in on it, while at the same time allowing verification to be possible. It is a non-trivial task and I don't think a magic bullet will pop up.
Agreed, the ideal is probably information-theoretically impossible. However, as a practical matter, successfully defrauding a Scantegrity II election with any degree of real oversight in place would be impossible. Well, to be precise, it would be very, very unlikely. With probabilistic verification methods, there's always a chance of failure, but that chance can be made arbitrarily small.
Much like computing however, there is rarely a major breakthrough, its almost always incremental based on previous experience and innovations.
I think from the perspective of real-world, in-use voting systems this IS a breakthrough. Of course, the approach itself was developed incrementally, starting with some secure but completely impractical approaches, gradually refined (Punchscan, Scantegrity I) into something usable. And there's no doubt that further refinements will be applied.
But from a real-world perspective, this system (and it's immediate ancestors) is the first one that provides a way to mathematically prove (with probability p) that ballots were not discarded or altered, yet retaining an extremely high degree of anonymity.
So it's, after all, not that much different from a voting system where your name is printed on the ballot.
That's quite a stretch.
If logs aren't kept, you can't be linked to your ballot.
If ballots are secured, you can't be linked to your ballot.
If you choose not to verify, you can't be linked to your ballot.
If you choose to verify from a public Internet connection, you can't be linked to your ballot.
If any ONE of the above hold, then you're anonymous, and two of the four are entirely within your control. Oh, and better make sure you wear gloves when you vote so that you don't leave fingerprints on the ballot.
And the old system is verified just as well. The verification comes from the ballot handling and counting being done together by a group of diverse people, at least one person for each candidate, so they don't have the motivation to collude to commit fraud.
But that verification has been shown not to do a good job of preventing ballots from getting lost or ignored. This system closes that hole while maintaining the other advantages of a paper ballot system.
Another hyped e-voting system that is no good.
This is not an e-voting scheme. There is no requirement for any computerization at all; the whole thing can be done manually. It's more convenient to process the results electronically, but it's not necessary, and doing so in no way compromises the integrity of the result. In the words of the authors, it's a mathematical voting system, not an electronic voting system.
A good reason for not keeping logs -- and if you're really concerned about it, for not verifying your vote. The system doesn't need *everyone* to verify, just a small percentage.
Actually, I realized that it would have to shift every 25 ballots. Otherwise, it would repeat every 26th ballot; for all values of n, (n * 26) MOD 26 = 0. Oops. Still, if you have 300 candidates/ballot measure checkboxes, that gives you, if my sleepy math is right, about 7500 ballots before you repeat at all. That would be good enough for many smaller districts.
Any such pattern would be pretty easy to detect by examining table Q. Also, part of proper oversight of a Scantegrity II election would be verification that the PRNG used to generate the codes is cryptographically sound and properly employed.
First, to be secure, this assumes that the auditor can remember every code from previous ballots to verify that are unique. Yet the instructions seem to indicate that the auditor sees only one ballot at a time instead of half a dozen ballots.
You should read section 4.3 of the paper. I think most of your concerns about it are addressed there.
For this part, the auditor is comparing the ballot with the relevant row of table Q, which specifies what the codes are -- but not which candidates they correspond to. And by examining table Q as a whole, the auditor can verify overall uniqueness. As long as the ballots to be audited are selected at random, the scheme is secure.
This is a cool idea, but ultimately electronic voting can provide much better protections against vote fraud than paper voting, assuming you do it correctly (with mandatory paper trail, separate manufacturers for a vote verifying machine than the vote taking machine, paper tokens from the verifier machine with cryptographic hashes of the vote using a UUID generated instantaneously at vote time keyed off the voting machine/time of day/PRNG, and so on. And still none of that guarantees that your vote really got counted, but the ability to total up the numbers in multiple places at least makes it very hard to inject or discard votes without going through the disenfranchisement process.
This system provides all of the benefits you describe. The only difference is that the crypto work in ballot preparation is done in advance, rather than at the time of voting, which allows several additional verifications of the process to be done, AND allows you to verify (statistically) that your vote got got counted. More precisely, it provides an assurance that any systematic exclusion or alteration of ballots will be detected with very high probability.
This system also allows ANYONE to perform that statistical verification that the aggregation was done correctly.
If you haven't read the research papers that underly the system, I recommend that you do. They're from some serious security researchers, including the likes of David Chaum and Ron Rivest. If you can find significant holes in their scheme, they'd be glad to hear it.
So, while it may seem like voting 3rd party is throwing your vote away, it isn't. You can think of it as voting against both parties
That's correct, but it misses an important point: Unless both of the major parties are equally repugnant to you, you are probably voting against your own interests. Third parties primarily draw votes from the major party that is ideologically closest to them, which tends to give the election to the major party that is ideologically furthest from them.
So, if you see the Reps and the Dems as essentially equivalent (as I do), then there's no problem with voting third party. If, however, you mostly align with one or the other, voting for a third party just strengthens the one you most disagree with.
Actually, I hadn't finished this version of the paper. I was basing my comments on previous iterations, which were slightly different.
That said, if the Scantegrity II sytem is begin operated as designed, it is not the case that the voting authority has the paper ballots. After scanning, they should be locked away, since they're not needed for counting or integrity verification. They're only needed to handle disputes, and even then the voting authority doesn't need to actually handle the ballots.
In the case that ballots are not locked away as they should be AND web logs are kept AND voters can be identified from the logs, then those voters who verified their votes could lose the anonymity of their votes.
You are correct. If someone has access to both the physical ballots (which no one should; the system is designed so that no such access is needed for normal verification), and to the web logs, and can link the web logs to individual identities, then that person can find out how voters who verified their votes voted.
Not keeping web logs is a good idea. Securing the ballots is a good idea.
You are correct. I hadn't fully read the paper, but was basing my understanding on previous incarnations of the system.
Scantegrity II assumes that the physical ballots are stored security after scanning and not made available to anyone trying to link voters to ballots.
I wouldn't consider this a fatal flaw in the system, though. If ballots are handled properly, there is no risk to voter anonymity, and the system is designed so that the paper ballots are not needed to verify the integrity of the election, so there's no reason for them not to be locked away. Even if they're not locked away, any voter who wishes to ensure his or her anonymity can simply not take the receipt.
I'm far more concerned about phantom votes being counted than real votes not being counted.
Both are real issues. There are plenty of examples of ballot boxes getting "lost", so those are real problems. Dead people voting, multiple votes, systematic exclusion of voters (not losing their ballots, but preventing them from voting), all of these things are problems.
This system doesn't solve all of those other problems, but it does solve the problem of votes getting lost, altered or counted incorrectly. And it does it in a mathematically-provable fashion.
And if they have access to the actual ballots, who you voted for. A non-transparent system with a way to match voters with their votes that has been "verified to be secure by the brightest minds at MIT". Every dictators wet dream.
There's nothing to connect the information displayed with the physical ballot. The linkage to vote selection cannot be made.
Slashdot Mirror
Would a 20'F temperature differential be the only factor in determining the forces involved? Seems to me it might be offset by the fact that colder air would have a tendency to be denser, thus potentially offsetting your figure of 16,000lbs...
Um, it's the greater density of colder air that *creates* the lift.
If you're upgrading a database that has been used with a previous version (which required the database to use the latin1 character set), you need to fix your database.
Not exactly. The various MythTV binaries are supposed to cleanly update any 0.21 database to 0.22. The character set conversion issue described on that page is due to the default MySQL settings as shipped with Gentoo.
Thanks for the correction.
Did they fix the database encoding in this one?
That depends on what you mean by "fix".
With MythTV 0.22, the database is expected to be configured with the UTF-8 character set. If you're upgrading a database that has been used with a previous version (which required the database to use the latin1 character set), you need to fix your database.
I would guess that if you're using MythTV as packaged by a major distro, by the time your distro delivers 0.22 it will probably handle the character set conversion automatically.
Which costs more to implement?
Stringing many miles of additional wire costs more, particularly since the fact that the power company owns the wire doesn't do anything to eliminate the need for proper protection of data or authentication of commands delivered over it.
Yep. We lost the terminology war a decade ago. It's time we deal with it.
Whatever. Language is context-sensitive. I have no problem with the media using the term one way while I use it another. For that matter, I use the word both ways, depending on who I'm talking to.
So is this basically assuming that the Q table will never get leaked? *confused*
Very good question. It took me some time to dig into it to figure out the answer.
The answer is yes. The system assumes that the full contents of the tables will never get leaked. Table P is never revealed at all and table Q is partially revealed according to a specific scheme. Access to the full contents of Q, R and S allows the reconstruction of P. Access to P reveals the structure of all ballots.
Improper access to the contents of the tables, plus access to a voter's verification codes reveals who that voter voted for.
The authors' solution to this is in assumption 5 of section 5.2.1: "Election officials use a special trusted computer workstation (as described in [14]) to enforce the privacy of the tables of confirmation codes."
The secure diskless workstation mentioned in [14] is adequate for a university election, but in my opinion it's insufficiently secure for an important election. However, I think that an adequate machine can be built, and I build high-security cryptographic key management systems for a living. The same techniques and approach used to protect the master cryptographic keys that protect hundreds of billions of dollars should be sufficient.
My recommendation would be to use something like an IBM 4764 cryptographic coprocessor -- or any other programmable FIPS 140-2 level 4 certified device. Use it to generate P, and program it to output P for external storage (because P is likely too large for internal storage) only in encrypted form. Likewise with Q. The selective revelation of Q should be done by the secure device, with an external input providing the "coin flips".
The source code for the device should be open source and published, and the binary should also be published. The 4764 already includes a very clever and very secure mechanism for incrementally loading verified software, starting with a dead simple boot loader which is trivial to verify and produces hashes of each further loading stage. Loading should be done under oversight by all interested parties.
If generation of P is done by a deterministic PRNG, then you can have P generated in parallel by multiple identical devices, one under the control of each major party and perhaps a watchdog group or two as well, and all can verify that the encrypted version of P is identical. The way to do that is to start with one device and then use a secure clone operation to replicate the master key and the PRNG seed from one device to another.
Even though the devices are highly, highly resistant to penetration (millions must be spent in multiple serious attempts to penetrate a device in order for it to achieve level 4 certification), all parties operating such a device must allow oversight from any other interested parties. This is also necessary to ensure that no unauthorized clones are created -- though the software should make use of the device's hardware "security ratchet" to ensure that once put into the "generate P" mode, the cloning functionality is disabled.
After the partial revelation of Q (done in parallel), all of the devices should be breached, in public, under oversight, which will cause them to destroy their master keys. The devices should probably also be publicly destroyed.
The final potential weakness is pre-tampering with the devices. If the device could be subverted even before the first software is loaded, then all of the security disappears. Manufacturers of such devices take great pains in the manufacturing process to be able to prove that they produce reliable devices, but those measures are insufficient for something like a major election.
I think another iteration of the cut-and-choose style verification Chaum is so fond of is the solution. Or in this case perhaps it should be called 'choose and cut'. The election officials should de
If the fake ballots don't have the codes in the order specified in the S-pointer column of the Q table, then the votes would in fact get redirected to different candidates. However, those ballots would be identified as fake by any of the ballot audits, whether the audits done pre-election, post-election by voters, or post-election by poll workers.
That's why voters should also audit the ballots at random. Read the paper for a description of how this is done.
I wish I could say you're wrong, but you're not. Not only is there the issue you mention, that it may be harder for the family of the intruder to sue than the intruder, but if the civil jury finds against you the damage calculations are likely to be much worse if the intruder lived.
The reason is that when someone dies, damages for the wrongful death are calculated based on what that person could have earned had he not died. In the case of most burglars, that's not much (relatively speaking). But if he lives, then damages are calculated on a more subjective scale based on pain and suffering inflicted. When the result of the shooting is that the intruder will be in severe pain the rest of his life juries award crazy sums.
Luckily, I live in a state with a "Castle Doctrine" law that states that if someone breaks into my home and I reasonably believe he's there to harm someone or to commit a felony (like burglary) then whatever response I take is presumed to be "reasonable" for purposes of both criminal and civil cases. The burden is then on the plaintiff to prove that my action was unreasonable.
Still, civil liability issues aside, I'll stick with the ethical standard. I'd rather have the jury take everything I own than to have to live with having executed a man in cold blood just to avoid a civil suit.
Hmm, I ought to send that one in. Seeing them try to scale this one up could be fun.
Poor Buster...
What defines a "widespread pattern of errors?" In small elections or close elections, changing a small fraction of votes could affect the outcome.
The use of the three-letter codes allows most errors (whether deliberate or accidental) to be weeded out because the odds of accidentally providing a valid code are small. The remaining complaints are called "plausible discrepancies" and the paper explains how to calculate an appropriate trigger threshold, based on the number of plausible discrepancies vs the total discrepancies, the number of candidates, the size of the code space and the degree of certainty required (which is dependent on the closeness of the race). If the trigger threshold is exceeded, then there is evidence of systemic failure and an investigation is required.
A three digit code is probably adequate, but I'd have probably opted for a longer value. It depends on how the code is used and what it represents. I'm assuming it represents a given candidate, as you're unlikely to have more than 1000 candidates for a given district but will likely have more than 1000 voters in a given voting station.
The three-digit code doesn't represent a given candidate, except on a given part of a given ballot.
Suppose that the ballot had only one race (any more complex ballot can be decomposed into a set of such simple ballots, so this assumption doesn't limit generality). Each slot in that ballot, corresponding to a candidate, has a three-letter code, which is only revealed to the voter when he or she selects that candidate. That same set of three letter codes, but WITHOUT any association between code and candidate, is a row in table "Q".
After the election, you can look up your ballot on-line and it will show you all of the three-letter codes that were on your ballot. You verify that the one you revealed is in the list.
But what if it isn't? That's when you come forward to say there's a problem. There are two basic possibilities: either you are wrong or the system is wrong. Either possibility could come about through either error or malice. If you made a mistake, or invented a code, the probability that your erroneous or invented code is in the list for your ballot is determined by the code length. The three-letter codes were chosen because they make that possibility sufficiently small that few voter errors will go undetected. A statistical model is used to decide when those that do (called "plausible discrepancies") are numerous enough to indicate a likelihood of system error/fraud.
Of course with a little help from your local ISP, they can see who is viewing what ballots, tie that to an IP and an IP to a home or in some cases a specific user.
True. There are some protections against this loss of anonymity, though.
First, only voters who choose to verify have any risk, and of those only the ones who choose to verify from a location that can be connected to them. Since only a tiny percentage of voters need to verify in order to statistically exclude the possibility of ballot loss or alteration, you only need a small number of people willing to take the "risk".
Second, it's only possible to match voter with ballot if you have possession of the physical ballots. The system is designed so that no one needs access to the full set of ballots after they've been scanned. Verification of the integrity of both counting and collection can be done without access to the ballots. Some verification of cast ballots needs to be done, but that requires only small sample (at most a couple thousand randomly-chosen ballots).
You want to have it so no one holds all the data so correlations can't be made without everyone being in on it, while at the same time allowing verification to be possible. It is a non-trivial task and I don't think a magic bullet will pop up.
Agreed, the ideal is probably information-theoretically impossible. However, as a practical matter, successfully defrauding a Scantegrity II election with any degree of real oversight in place would be impossible. Well, to be precise, it would be very, very unlikely. With probabilistic verification methods, there's always a chance of failure, but that chance can be made arbitrarily small.
Much like computing however, there is rarely a major breakthrough, its almost always incremental based on previous experience and innovations.
I think from the perspective of real-world, in-use voting systems this IS a breakthrough. Of course, the approach itself was developed incrementally, starting with some secure but completely impractical approaches, gradually refined (Punchscan, Scantegrity I) into something usable. And there's no doubt that further refinements will be applied.
But from a real-world perspective, this system (and it's immediate ancestors) is the first one that provides a way to mathematically prove (with probability p) that ballots were not discarded or altered, yet retaining an extremely high degree of anonymity.
So it's, after all, not that much different from a voting system where your name is printed on the ballot.
That's quite a stretch.
If any ONE of the above hold, then you're anonymous, and two of the four are entirely within your control. Oh, and better make sure you wear gloves when you vote so that you don't leave fingerprints on the ballot.
And the old system is verified just as well. The verification comes from the ballot handling and counting being done together by a group of diverse people, at least one person for each candidate, so they don't have the motivation to collude to commit fraud.
But that verification has been shown not to do a good job of preventing ballots from getting lost or ignored. This system closes that hole while maintaining the other advantages of a paper ballot system.
Another hyped e-voting system that is no good.
This is not an e-voting scheme. There is no requirement for any computerization at all; the whole thing can be done manually. It's more convenient to process the results electronically, but it's not necessary, and doing so in no way compromises the integrity of the result. In the words of the authors, it's a mathematical voting system, not an electronic voting system.
A good reason for not keeping logs -- and if you're really concerned about it, for not verifying your vote. The system doesn't need *everyone* to verify, just a small percentage.
Actually, I realized that it would have to shift every 25 ballots. Otherwise, it would repeat every 26th ballot; for all values of n, (n * 26) MOD 26 = 0. Oops. Still, if you have 300 candidates/ballot measure checkboxes, that gives you, if my sleepy math is right, about 7500 ballots before you repeat at all. That would be good enough for many smaller districts.
Any such pattern would be pretty easy to detect by examining table Q. Also, part of proper oversight of a Scantegrity II election would be verification that the PRNG used to generate the codes is cryptographically sound and properly employed.
First, to be secure, this assumes that the auditor can remember every code from previous ballots to verify that are unique. Yet the instructions seem to indicate that the auditor sees only one ballot at a time instead of half a dozen ballots.
You should read section 4.3 of the paper. I think most of your concerns about it are addressed there.
For this part, the auditor is comparing the ballot with the relevant row of table Q, which specifies what the codes are -- but not which candidates they correspond to. And by examining table Q as a whole, the auditor can verify overall uniqueness. As long as the ballots to be audited are selected at random, the scheme is secure.
This is a cool idea, but ultimately electronic voting can provide much better protections against vote fraud than paper voting, assuming you do it correctly (with mandatory paper trail, separate manufacturers for a vote verifying machine than the vote taking machine, paper tokens from the verifier machine with cryptographic hashes of the vote using a UUID generated instantaneously at vote time keyed off the voting machine/time of day/PRNG, and so on. And still none of that guarantees that your vote really got counted, but the ability to total up the numbers in multiple places at least makes it very hard to inject or discard votes without going through the disenfranchisement process.
This system provides all of the benefits you describe. The only difference is that the crypto work in ballot preparation is done in advance, rather than at the time of voting, which allows several additional verifications of the process to be done, AND allows you to verify (statistically) that your vote got got counted. More precisely, it provides an assurance that any systematic exclusion or alteration of ballots will be detected with very high probability.
This system also allows ANYONE to perform that statistical verification that the aggregation was done correctly.
If you haven't read the research papers that underly the system, I recommend that you do. They're from some serious security researchers, including the likes of David Chaum and Ron Rivest. If you can find significant holes in their scheme, they'd be glad to hear it.
So, while it may seem like voting 3rd party is throwing your vote away, it isn't. You can think of it as voting against both parties
That's correct, but it misses an important point: Unless both of the major parties are equally repugnant to you, you are probably voting against your own interests. Third parties primarily draw votes from the major party that is ideologically closest to them, which tends to give the election to the major party that is ideologically furthest from them.
So, if you see the Reps and the Dems as essentially equivalent (as I do), then there's no problem with voting third party. If, however, you mostly align with one or the other, voting for a third party just strengthens the one you most disagree with.
:-)
Actually, I hadn't finished this version of the paper. I was basing my comments on previous iterations, which were slightly different.
That said, if the Scantegrity II sytem is begin operated as designed, it is not the case that the voting authority has the paper ballots. After scanning, they should be locked away, since they're not needed for counting or integrity verification. They're only needed to handle disputes, and even then the voting authority doesn't need to actually handle the ballots.
In the case that ballots are not locked away as they should be AND web logs are kept AND voters can be identified from the logs, then those voters who verified their votes could lose the anonymity of their votes.
You are correct. If someone has access to both the physical ballots (which no one should; the system is designed so that no such access is needed for normal verification), and to the web logs, and can link the web logs to individual identities, then that person can find out how voters who verified their votes voted.
Not keeping web logs is a good idea. Securing the ballots is a good idea.
You are correct. I hadn't fully read the paper, but was basing my understanding on previous incarnations of the system.
Scantegrity II assumes that the physical ballots are stored security after scanning and not made available to anyone trying to link voters to ballots.
I wouldn't consider this a fatal flaw in the system, though. If ballots are handled properly, there is no risk to voter anonymity, and the system is designed so that the paper ballots are not needed to verify the integrity of the election, so there's no reason for them not to be locked away. Even if they're not locked away, any voter who wishes to ensure his or her anonymity can simply not take the receipt.
But the whole system wouldn't work at all if there was not a linkage between your three letters and the Candidate's name SOMEWHERE.
Incorrect. Those letters have nothing to do with your vote selection, they're just an integrity check.
Again, read the paper.
Clearly you understand the SOMEONE knows exactly which candidate those letters on your specific ballot refer to?
No, the system is carefully design to ensure that NO ONE knows who those letters refer to.
Read the paper.
I'm far more concerned about phantom votes being counted than real votes not being counted.
Both are real issues. There are plenty of examples of ballot boxes getting "lost", so those are real problems. Dead people voting, multiple votes, systematic exclusion of voters (not losing their ballots, but preventing them from voting), all of these things are problems.
This system doesn't solve all of those other problems, but it does solve the problem of votes getting lost, altered or counted incorrectly. And it does it in a mathematically-provable fashion.
See the paper.
And if they have access to the actual ballots, who you voted for. A non-transparent system with a way to match voters with their votes that has been "verified to be secure by the brightest minds at MIT". Every dictators wet dream.
There's nothing to connect the information displayed with the physical ballot. The linkage to vote selection cannot be made.
Read the paper.