78f0140342
## Issue Even after storing keys as base64, the API was returning plain "p:g:h" format for existing elections that had keys stored as plain UTF-8 bytes, causing: - Client receives: "23:5:13" (plain text) - Client tries to decode as base64 (btoa call) - Results in: "Invalid base64: 23:5:13... - String contains an invalid character" ## Root Cause 1. Old elections have public_key stored as plain UTF-8: b'23:5:13' 2. New elections store as base64: b'MjM6NToxMw==' 3. Both were decoded to string before return, exposing wrong format 4. Also fixed ElGamal class name typo: ElGamal() → ElGamalEncryption() ## Fix 1. Detect public key format before returning: - If plain "p:g:h" format (contains ':'), encode to base64 - If already base64 (starts with 'MjM6'), return as-is 2. Always return base64-encoded string to client 3. Updated both /setup and /public-keys endpoints in votes.py 4. Updated /init-keys endpoint in admin.py 5. Fixed class name in setup_election function ## Files Changed - backend/routes/votes.py: Lines 502, 509-518, 560-569 - backend/routes/admin.py: Lines 179-197 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>