This is an automated email from the ASF dual-hosted git repository.
gstein pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/steve.git
The following commit(s) were added to refs/heads/trunk by this push:
new d1ecef5 Dump more thoughts
d1ecef5 is described below
commit d1ecef535c2a243c738d45b70fa116f6ab20923a
Author: Greg Stein <[email protected]>
AuthorDate: Thu May 26 08:11:03 2022 -0400
Dump more thoughts
Two main items: vote monitors, and implementation notes.
---
v3/README.md | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 80 insertions(+)
diff --git a/v3/README.md b/v3/README.md
index d72cf84..2dea35e 100644
--- a/v3/README.md
+++ b/v3/README.md
@@ -25,6 +25,37 @@ set of **Vote Monitors** (single digit count) for the
Election.
This will produce a set of **Votes** (tens of thousands).
+### Vote Monitors (and Attacks?)
+
+This role is undefined.
+
+Once an election is opened, no changes to the ballot are allowed, so the
+Monitors cannot affect an election. With read-only status, what should they
+be looking for?
+
+* Alice voting as Bob (see below)
+* Alice stuffing ballots (eg. as a person not on Record; should be impossible)
+
+Each participant receives a **token** to represent themself during voting. The
+token is regarded as a **shared secret** between STeVe and the Participant.
+
+Note: this token could be used internally, and the **shared secret** would be
+the Participant's LDAP password. This *may* create undesired data in access
logs,
+which could be solved by custom config to **omit** the authenticated user from
+the logs. And/or, a Participant could sign in to retrieve a link that embeds
+their token, and that link requires no authentication (note: would need to
+ensure that **all** browsers obey path-based directives on when to send
+credentials; we'd only want creds for retrieving the token/link, but for them
+to be dropped during voting the ballot).
+
+Given the above, if Alice is able to discover Bob's token, then she can vote
+as if she were Bob. This may be discoverable by aberrant repeat voting by Bob.
+
+Since votes may only be performed by those on record, with voter tokens, it
+does not seem possible for Alice to stuff the ballot box.
+
+?? other attack vectors? can Monitors help with any?
+
## Hashes and Anonymity
The participants must be as anonymous as possible. The goal is that
Participants
@@ -42,3 +73,52 @@ When an Election is "opened for voting", all Participants,
Issues, and Monitors
will be used to construct a singular hash that identifies the precise state of
the Election. This hash is used to prevent any post-opening tampering of the
voters of record, the ballot, or those watching for such tampering.
+
+## Implementation
+
+Some notes on implementation, hashing, storage, at-rest encryption, etc.
+
+```
+ElectionID := 32 bits
+VoterID := availid from iclas.txt
+IssueID := [-a-zA-Z0-9]+
+
+Election-data := TBD
+Issue-data := TBD
+BLOCK := Election-data + sorted(Issue-Data)
+OpenedKey := Hash(BLOCK)
+
+Voters := Map<VoterID, Salt(each-voter)>
+VoterToken := Hash(OpenedKey + VoterID + Salt(each-voter))
+
+Issues := Map<IssueID, Salt(each-issue)>
+IssueToken := Hash(OpenedKey + IssueID + Salt(each-issue))
+
+VoteKey := Hash(VoterToken + IssueToken + Salt(each-vote))
+Vote := Tuple[ VoterToken, IssueToken, Salt(each-vote), Encrypt(VoteKey,
votestring) ]
+```
+
+When an **Election** is Opened for voting, the `OpenedKey` is calculated,
stored,
+and used for further work. The `OpenedKey` is primarily used to resist
tampering
+with the ballot definition.
+
+The size of **Salt(xx)** is TBD. The salt values should never be transmitted.
+
+The `Hash()` function is likely to be **Argon2**. Note that `Hash()` is
+computationally/memory intensive, in order to make "unmasking" of votes
+somewhat costly for **root**. Yet it needs to be reasonable to decrypt
+the votestrings for final tallying (eg. after ballot-close, **several hours**
+to decrypt all the votes and perform the tally).
+
+`Encrypt()` and `Decrypt()` are a **symmetric** encryption algorithm
+(eg. block-based XOR), so that votestrings can be recovered. TBD.
+
+**IMPORTANT**: the `IssueToken` and `VoteKey` should never be stored.
+In general, the expense of the `Hash()` function should not be short-circuited
+by storing the result. Any attacker must perform the work. During normal
+operation of the voting system, each call of the `Hash()` function should be
+within human-reasonable time limits (but unreasonable to perform in bulk).
+
+If `VoteToken` is not emailed, but (instead) LDAP authentication is used,
+then it is possible to omit storage of `VoteToken` and to simply compute it
+from the authenticated credentials.
