Re: [steve] branch trunk updated: Dump more thoughts

[Greg Stein <gs...@gmail.com>]

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 <gs...@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 <gs...@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.
>
>