Please check out the README and edit/comment. Where do we want to go?? https://github.com/apache/steve/blob/trunk/v3/README.md
On Thu, May 26, 2022 at 8:11 AM <gst...@apache.org> wrote: > 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 <gst...@apache.org> > 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. > >
