Summary
The js README documents encryptVote as returning
iv:authTag:ciphertext in base64. The core README documents the
vote encryption as using AES-256-GCM with hex output. The
src/crypto.ts implementation needs to be checked — whichever format
it actually produces, one of the two READMEs is wrong. A consumer
importing @anonvote/crypto in core who follows the core README
will attempt to parse hex but receive base64 (or vice versa), causing
a silent decryption failure during the tally that produces no error
until the result is wrong.
The format must be standardised to one canonical representation across
the implementation, both READMEs, and the EncryptedPayload type.
Scope
- Read
src/crypto.ts and determine the actual output format of
encryptVote — base64 or hex
- Choose hex as the canonical format — it is more consistent with
hashIdentifier and hashToken which both output hex, and it is
what the core README documents
- If
encryptVote currently outputs base64, update it to output hex
for all three fields in EncryptedPayload — ciphertext, iv,
authTag
- Update
decryptVote to parse hex input if it currently expects base64
- Update the
js README Usage section to show hex output
- Update the Security notes section in the
js README to remove any
reference to base64
- Add a unit test that calls
encryptVote and asserts all three
fields in the returned EncryptedPayload are valid hex strings —
not base64
Relevant Files
src/crypto.tsREADME.mdtests/crypto.test.ts
Acceptance Criteria
Out of Scope
- Changing the encryption algorithm
- Changes to
core service files — update core README only
Note for Contributors
If the existing implementation already outputs hex and the README is
wrong, the fix is documentation only. Confirm the actual output format
first before touching any code. Do not change the format if it is
already hex — only fix the README.
Summary
The
jsREADME documentsencryptVoteas returningiv:authTag:ciphertextin base64. ThecoreREADME documents thevote encryption as using AES-256-GCM with hex output. The
src/crypto.tsimplementation needs to be checked — whichever formatit actually produces, one of the two READMEs is wrong. A consumer
importing
@anonvote/cryptoincorewho follows thecoreREADMEwill attempt to parse hex but receive base64 (or vice versa), causing
a silent decryption failure during the tally that produces no error
until the result is wrong.
The format must be standardised to one canonical representation across
the implementation, both READMEs, and the
EncryptedPayloadtype.Scope
src/crypto.tsand determine the actual output format ofencryptVote— base64 or hexhashIdentifierandhashTokenwhich both output hex, and it iswhat the
coreREADME documentsencryptVotecurrently outputs base64, update it to output hexfor all three fields in
EncryptedPayload—ciphertext,iv,authTagdecryptVoteto parse hex input if it currently expects base64jsREADME Usage section to show hex outputjsREADME to remove anyreference to base64
encryptVoteand asserts all threefields in the returned
EncryptedPayloadare valid hex strings —not base64
Relevant Files
src/crypto.tsREADME.mdtests/crypto.test.tsAcceptance Criteria
encryptVoteoutputs hex forciphertext,iv, andauthTagdecryptVotecorrectly parses hex inputjsREADME andcoreREADME document the same formatEncryptedPayloadfieldsOut of Scope
coreservice files — updatecoreREADME onlyNote for Contributors
If the existing implementation already outputs hex and the README is
wrong, the fix is documentation only. Confirm the actual output format
first before touching any code. Do not change the format if it is
already hex — only fix the README.