danwallach / electionguard-typescript Goto Github PK

Current on powRadixSpeedup branch. Possibly dependent on #8. If we had more vicious testing, we'd be more confident that the speedup was correct / bug-free.

The readme is currently a little verbose. Update to include usage instructions.

TypeScript has a rich type system. Can we use it and create code that's cleaner than the original Python code?

• Optional --> TypeScript union types?
• Numeric types --> Can we overload +, -, *, and so forth to make the code look more like math?

Currently test-vectors.test.ts compares our {de,re}serialization against the sample data. We want to also check that the numbers line up. Bonus points for making the hashes match.

Right now, if we're asked to encrypt an overvoted ballot, the resulting proofs will not correctly verify. Resolving this issue requires two things:

• interpreting an overvoted contest down to a blank input
• placing something meaningful into the extended data

The extended data is meant to hold write-in data, original (uninterpreted) votes, and other such things, all encrypted with hashed ElGamal but the spec doesn't provide detailed guidance on this.

Some fields have become optional and nullable, others are entirely new.

Need more details from EnhancedVoting team.

Potentially significant speedups.

Using one of the TypeScript property-based testing libraries build tests equivalent to the tests that we have in other ElectionGuard implementations.

So this is a thing: https://github.com/decidim-archive/decidim-electionguard

It's sort of kind of an online voting system. They've got an ElectionGuard module. Maybe we should talk to them. Maybe they'd be a good client for ElectionGuard-TypeScript?

We're currently supporting EG 0.95. We need to:

• enumerate the changes from EG 0.95 to EG 1.0
• support write-ins (hashed ElGamal stream cipher?)

Just add the various command-line things to make the code build and self-test.

Test data & related materials shouldn't be in src but instead in test somewhere.

EnhancedVoting team provides manifests and contexts for encryption, and typescript team generates ballots with non-random patterns.
Then typescript team returns encrypted ballots and the expected tally result to EnhancedVoting team to complete the tests.

Crazy thought: what are we supposed to do if we've been given a malformed PlaintextBallot? Or, with the asynchronous API, what are we supposed to do if we're given a PlaintextContest that isn't present in the claimed ballot style?

In the synchronous case, most likely, we should throw an error.

In the asynchronous case, where we have a function that returns void, I suppose we could do the same checks and throw an error eagerly, even though the encryption is delayed.

Whatever the case, it should be the case that whenever we produce a CiphertextContest, it has exactly all the contests specified in the ballot style. No more, no less.

Not anything specific, but we need to work through every single docstring and make sure they're consistent with the code behavior. In particular:

• In any possible case where an error might be thrown, this needs to be described in detail.
• Any time we're naming another class, method, or field, we should use the @link notation so we get working hyperlinks.
• For the most part, the API we're providing deals with serialization and deserialization, but we might have a separate SERIALIZATION.md file that explains how we're using io-ts, how it works, and how to deal with its error handling.
• When all the docstrings are converted to HTML, I think we get README.md as well, but we need to make sure other Markdown files we might write also get converted.

At some point, we want to distribute a package via npm. Set everything up so it's easy to do.

Default: code should be quiet on the console, but we still want to be able to enable verbose logging.

• Deserialization --> what if a required field is missing? (@Transform annotations, e.g., in chaum-pedersen code)
• Compatibility with the latest schema from Microsoft

Would be nice to have automated tests that check that stuff is properly exported in each of our builds.

Write a top-level utility function that does everything EnhancedVoting
needs (they initialize us with JS objects that correspond to the manifest,
etc.). Where everything else is functional, this one would hide all the
state inside and would have an API similar to the encrypt-async code, where
you feed it individual bits of data and you eventually ask for the output.

Right now, when you run npm run test, it proceeds to start running the packaging process. Dunno why that's happening, but something's not right.

There are also warnings about circular dependencies and about this being rewritten to undefined, so I'm assuming that we've still got some effort to get this all buttoned up.

We currently output a mod.js for deno and an index.d.ts for node. index.d.ts doesn't work with deno because (a) it doesn't have the types for our dependencies bundled, and (b) index.d.ts isn't referenced in mod.js, so deno wouldn't know where to find the types anyway.

Once we figure out the bundling of types for deno, we should also:

• add a section about deno to the readme
• add a deno example
• potentially publish to deno.land/x

Also, mod.js currently includes, bundled-in, all our dependencies. Ideally it would import them.

A digital signature for detecting tempering ballots after spoiled or casted.
The signature needs to include the hash and the spoiled/casted state.
This is a required feature for a remote scenario, where it is needed to protect the spoiled/casted state.

Reduce the set of exports in index.ts to a minimal subset.

src/electionguard/index.ts → dist/electionguard.js, dist/electionguard.umd.js...
(!) Circular dependencies
node_modules/readable-stream/lib/_stream_readable.js -> node_modules/readable-stream/lib/_stream_duplex.js -> node_modules/readable-stream/lib/_stream_readable.js
node_modules/readable-stream/lib/_stream_duplex.js -> node_modules/readable-stream/lib/_stream_writable.js -> node_modules/readable-stream/lib/_stream_duplex.js
polyfill-node._stream_duplex.js -> polyfill-node._stream_readable.js -> polyfill-node._stream_duplex.js
polyfill-node._stream_duplex.js -> polyfill-node._stream_writable.js -> polyfill-node._stream_duplex.js

See discussion in #32.

New feature from GitHub Actions:
https://github.blog/changelog/2022-07-27-github-pages-custom-github-actions-workflows-beta/

Hypothetically, we could set this up where every commit updates a static GitHub Pages site.

Higher degree of difficulty: only do this if the unit tests pass. (And, presumably, only on the main branch.)

Definitely not for the short-term, but Zod is a fancy alternative to what we're doing with io-ts.
https://github.com/colinhacks/zod

Some demos here starting around minute 12:
https://www.youtube.com/watch?v=RmGHnYUqQ4k

Looks like it might be more concise than io-ts, but then we've already got io-ts working so there's no hurry to remove / replace it.

Create a new section at the bottom with a list of all authors & email addresses.

Manually transferred.

Dependent issue: microsoft/electionguard-python#646

Depending on what they do or don't fix, we might need to:

• Ensure that we're always serializing integers to 32-bits
• Remove the 0x00 from the KDF computation
• Encode HMAC keys in hex bytes (hopefully not!)

We should also double-check that they are correctly handling inputs that aren't multiples of 32 bytes long.

Our current implementation hardcoded P, Q, and public key constants.
They need to be inputs read from context.json and constant.json defined by v1.0 ElectionGuard standard. (https://www.electionguard.vote/develop/Data_Schema/)

We need a function that tests whether or not the platform supports ElectionGuard-TypeScript. We need to (somehow) figure out all the different features we're using and test for each of them. The function should return some kind of structure with string keys (names of the relevant features) and boolean values (supported or unsupported).

If everything is good, then it just returns true or whatever, so it's at least easy to check that there isn't a problem.

Related: understanding what "polyfill" libraries are available and whether they're good enough. I'm pretty sure we're going to require native bigint, but other stuff? We can get away with a lot before performance becomes an issue.

Fill directory with output from the Python code, commit changes so this repo can test itself without needing the Python code.

Also, add line(s) to package.json to automatically run the serialization test.

Will it work?