This should be the last big re-write , but really proud of this work.
I finally got keymeld (MuSig2 in AWS enclaves) to survive restarts.
The core problem: every time an enclave restarts, it loses its master keypair. That keypair is what decrypts participant private keys during keygen—so losing it means all your encrypted session data in SQLite becomes useless. Participants would have to re-register and regenerate aggregate keys from scratch. Not acceptable for production.
The solution is AWS KMS envelope encryption. On first boot, KMS generates a Data Encryption Key (DEK). The enclave encrypts its master private key with that DEK using AES-256-GCM, then stores both the KMS-encrypted DEK and the DEK-encrypted master key in SQLite. On restart, the enclave sends the encrypted DEK back to KMS, gets the plaintext DEK, decrypts the master key, and replays completed keygen sessions from the database to restore state.
What I didn’t expect: stress testing this with 100+ parallel sessions completely broke things. VSock connections under heavy load turned out to be unreliable—connections dropping, timeouts everywhere. Ended up building a proper connection pool with health checks and auto-reconnection.
But the bigger rewrite was the concurrency model. The original architecture had too much shared state and locking. Ripped that out, reduced shared state, and converted many commands to batched versions. Much higher throughput now.
The result: 1000 parallel adaptor signature sessions with 3 signers each, completing in ~4 minutes. Worth the pain.
Also added proper testing infrastructure “just test-kms-e2e”restarts enclaves and verifies the keys survived, “just stress adaptor 100” hammers it with parallel sessions. Local dev uses Moto to mock KMS.
Single signing support is next. 👀
The goods:
https://github.com/tee8z/keymeld/pull/11#issue-3770532164
