Security status — independent audit evidence pending.
This page summarizes the current documented security and audit posture for HushVoting. It is not a completed external security audit, formal cryptographic proof, certification, or public-election readiness claim.
The current documented baseline says protected non-dev Admin-Only and Trustee-threshold elections have demonstrated encrypted ballot persistence, separation between vote-grant/eligibility/participation evidence and ballot choice, aggregate-only result release, correct circuit/profile truth in reports, and no observed persisted leakage of tally keys or trustee shares in inspected fresh-election runs.
HushVoting's audit model is designed around replayable evidence rather than trust in a private backend log. Auditors should be able to inspect election setup, trustee configuration, threshold policy, ballot transaction history, close-election records, trustee finalization approvals, decryption-share evidence, release integrity, and verifier output.
For serious voting, no single actor should hold a full recoverable decryption key. The trustee model uses key shares, threshold participation, final-aggregate-only release, and public verification of finalization evidence. The design avoids workflows for arbitrary per-ballot decryption or frequent intermediate plaintext tally release.
The documented baseline does not claim that HushVoting is certified secure, formally proven secure, public-election ready, impossible to compromise, anonymous against all observers, or protected against compromised voter, trustee, owner, or operator devices. It also does not close every timing, network, metadata, collusion, process-memory, or deployment-custody risk.
The remaining hardening roadmap includes independent cryptographic review, independent application and infrastructure security assessment, production HSM/KMS custody for sensitive election material, IAM rotation, stricter process-memory review, retention/log-correlation proof, deployment proof binding, public verifier corpus expansion, and controlled pilot evidence packages.
Security findings should be documented, classified by whether they affect guarantees or implementation, covered by tests when testable, and patched immediately when they affect active guarantees. A final vulnerability disclosure process should be published before broader production use, without exposing harvestable contact addresses on this page.