cknoll / git-voting

Verifiable Anonymous Voting System Based on Git, Email, GPG and Tor (Proposal)

About cknoll

• 🔭 I’m currently working on:
  • so called explainable artificial intelligence (XAI)
  • Knowledge representation and applications of it
  • (especially in the domains (partly overlapping) of engineering and sustainability)
• 👯 I’m looking to collaborate on: Semantic-related Python projects, interesting domain ontologies, and – of course – all of my (forked) repos.
• 🤔 I’m looking for help with: Understanding (and improving) some intricate details of ontology engineering and knowledge representation
• 💬 Ask me about:
  • Python (I co-authored a book on Python for engineering)
  • eXplainable Artificial Intelligence (XAI)
  • Knowledge Representation (RDF, OWL, SPARQL)
  • Control Theory
• 📫 How to reach me: via email (see also commit messages)
• ⚡ Fun fact: I believe there is a non-empty intersection of realistic and optimistic predictions of future developments.

git-voting's Issues

Separate Assumptions and Requirements

The Assumptions are the environment in which the system operates. Example: "$N < 100"

The Requirements are the things the system must enforce/provide. Example: "No user shall vote more than once."

By grouping both, you make it sound as if "No user shall vote more than once." is an Assumption and is not a property (supposed to be) protected by the scheme.

You may even go further and split Assumptions in Environmental Assumptions and Entities, where Entities describes the participants of the system (S1-S3, the Users) and their properties (Keys etc.).

clearify the randomness of $RANDOMNAME

@horazont wrote in a comment to the original gist:

Is $RANDOMNAME always the same name for a given vote? If so, the association between votes/$RANDOMNAME and the signed confirmations/$RANDOMNAME breaks the anonymity completely. That should be clarified in the text.

Be more specific in the "claims"-section

Feedback from a matrix channel:

[Section] "what can be achieved" parts (trust, anonymity, etc.) need to be a bit more focused and explained. Most systems will not be able to fulfill all requirements (availability?), so it's likely you'll need to make some concessions.

Nice to have

Feedback from a matrix channel:

From my point of view, things that would be nice to have are:

• scripts/things that "do everything": like ./vote
• a mathematical proof (tamarin?) that the defined protocol exhibits the claimed properties

What could also be interesting:

• blind signatures
  • however this goes beyond "usual" encrypting and signing, and thus might raise the understandability hurdle even higher.