Hacker News new | ask | show | jobs
by dbcurtis 2689 days ago
The Nevada State Gaming Commission has pretty much solved that.

The thing I find ironic -- deploy a voting machine -- Maker: "Oh, no, we can't let you look at our code, it's waaaaay too complicated for you to understand. Trust us." But deploy a slot machine: "Nevada: Show us the code or go fish." Maker: "OK."

3 comments

And the penalties for lying are severe, most importantly.
I'm curious if there's any effort made to verify the code being reviewed is actually the code being run on the machines.
Yes.

"Provide, as a minimum, a two-stage mechanism for verifying all program components on demand via a communication port and protocol approved by the chairman. The mechanism must employ a hashing algorithm which produces a messages digest output of a least 128 bits and must be designed to accept a user selected authentication key or seed to be used as part of the mechanism (i.e. HMAC SHA-1). The first stage of this mechanism must allow for verification of all control components. The second stage must allow for the verification of all program components, including graphics and data components in a maximum of 20 minutes. The mechanism for extracting the verification information must be stored on a Conventional ROM Device."[1]

[1] https://gaming.nv.gov/modules/showdocument.aspx?documentid=2...

Do we have anything like this for voting machines, in any states? If we do, how does it stack up in terms of security and transparency requirements?
Is this really a solved problem? If so, then wouldn't the solution be applicable to the emissions control scandals recently?
What if the code says "return rand();" but the compiler changes rand() to 42?