The Post-Quantum Security Analysis of Dora Vota and Anonymous MACI

0. Overall Conclusions

Conclusion 1: As a Cosmos/CometBFT appchain, Dora Vota does not provide end-to-end post-quantum security.

Its chain-level security mainly inherits from the Cosmos SDK, CometBFT, IBC, and CosmWasm ecosystems. Dora Vota depends on cosmos-sdk v0.47.17, cometbft v0.37.5, ibc-go/v7, wasmd, and wasmvm, and enables application-layer modules such as auth, bank, staking, slashing, gov, group, ibc, and CosmWasm. In this architecture, transaction authentication, validator consensus signatures, and IBC light-client security still rely on traditional elliptic-curve signature systems. Therefore, against a quantum computer with cryptographically relevant capabilities, the chain-level authentication and consensus layers are not post-quantum secure (github.com).

For the same reason, all post-quantum analyses applicable to the Dora Vota appchain also apply to Cosmos SDK and all Cosmos SDK-based blockchains.

Conclusion 2: Under the classical cryptographic model, Anonymous MACI (aMACI) is a structurally complete and complex anonymous + collusion-resistant voting system, but it is not post-quantum secure.

The aMACI/MACI code contains components such as BabyJubJub, EdDSA-Poseidon, ECDH, ElGamal, Poseidon, Groth16/PLONK, and BN254. On the circuit side, it includes core circuits such as AddNewKey, ProcessDeactivate, ProcessMessages, and TallyVotes. These core components, including voting-command authentication, encrypted-message privacy, deactivation/new-key anonymity, rerandomization-based unlinkability, and zkSNARK proof soundness, all rely to varying degrees on the elliptic-curve discrete logarithm problem (ECDLP), pairing-friendly curves, or elliptic-curve group assumptions (github.com).

Conclusion 3: The most serious post-quantum issue in aMACI is not hashing, but the public-key cryptography layer and the proof system.

Hash-based components such as Poseidon, SHA-256, Merkle trees, and hash chains are affected by Grover-style square-root speedups in a quantum setting, but they are not the system's weakest points. The real high-risk points are BabyJubJub ECDH, BabyJubJub ElGamal, EdDSA-Poseidon, and BN254 Groth16. NIST's basic assessment for post-quantum migration is also that traditional public-key cryptography such as RSA, DSA, ECDSA, EdDSA, and ECDH is threatened by large-scale quantum computers, while hash/symmetric primitives mainly face generic attacks that effectively halve their security level (csrc.nist.gov).

1. Scope and Threat Model

This document performs only a post-quantum cryptographic analysis. The analyzed targets are:

1. Dora Vota: an appchain based on Cosmos SDK / CometBFT / CosmWasm.
2. aMACI: with emphasis on the anonymous voting protocol, circuits, contract verification, and cryptographic primitives.

Here, post-quantum (PQ) security means whether the system's key security properties still hold when the attacker has a CRQC, cryptographically relevant quantum computer. The core quantum attack model is as follows:

NIST released its main post-quantum cryptography standards in 2024, including FIPS 203, FIPS 204, and FIPS 205 for key encapsulation and signatures. This indicates that the replacement of traditional public-key cryptography under quantum threats is not an abstract academic issue, but one already being handled at the standardization level (csrc.nist.gov).

Part I: Post-Quantum Security Analysis of Dora Vota

2. Dora Vota Architecture and Cryptographic Exposure

Dora Vota is an appchain built by Dora Factory. It supports aMACI and is used for voting, encrypted polling, frontier tech governance, and public good funding. It is a Cosmos chain primarily written in Go. It depends on the Cosmos SDK, CometBFT, IBC-Go, CosmWasm/wasmd/wasmvm, and provides standard chain modules as well as a custom sponsor-contract transaction module. (github.com)

The chain-level cryptographic exposure can be divided into five layers:

The Cosmos SDK account system supports public-key types such as secp256k1, ed25519, and multisig. CometBFT generates Ed25519 consensus keys by default and supports several validator public-key types, including ed25519, secp256k1, secp256k1eth, and bls12381. Whether ECDSA / secp256k1, Ed25519, or BLS12-381, these are not post-quantum signatures. (docs.cosmos.network)

3. Quantum Impact on Dora Vota's Key Security Properties

3.1 User Account Authentication

As a Cosmos chain, Dora Vota relies on account private-key signatures for user transaction authorization. For secp256k1/ECDSA or Ed25519/EdDSA accounts, once the public key is exposed, an attacker with a CRQC could theoretically recover the private key via the elliptic-curve discrete logarithm problem and forge transaction signatures. The Cosmos SDK secp256k1 signature implementation is essentially an ECDSA-style signature, and Ed25519 and secp256k1 are standard supported types in CometBFT/Cosmos (pkg.go.dev).

Impact: High

The post-quantum risk at the account layer is not that "the signature length is insufficient"; rather, the mathematical assumption behind the signature is directly broken by Shor's algorithm. The attacker does not need to brute-force a mnemonic or compromise an HSM. If the attacker can recover the private key from the public key, account control fails.

3.2 Validator Consensus Security

The CometBFT validator consensus key is Ed25519 by default. Validator public keys are usually public because other nodes must verify consensus votes, block commits, and validator-set updates. If an attacker can recover validator private keys, they can forge prevotes / precommits, create double-signing events, break finality, or construct forged commits (docs.cometbft.com).

Impact: High

In BFT consensus, once an attacker controls or forges signatures for a sufficient portion of validators, the risk escalates from single-account theft to chain-level security failure. More than one-third can cause liveness / finality issues, while reaching the two-thirds threshold threatens safety and incorrect finalization. Quantum attacks on validator keys are especially serious because validator public keys are long-lived public information.

3.3 IBC and Cross-Chain Security

Dora Vota's code enables modules such as IBC core, transfer, fee, interchain accounts, and Tendermint light clients. IBC security depends on combined verification of counterparty-chain headers, validator sets, signatures, and Merkle proofs. Merkle proofs themselves mainly rely on hashes and are relatively robust in a quantum setting, but Tendermint/CometBFT-style validator signatures are not post-quantum secure (raw.githubusercontent.com).

Impact: High

Even if Dora Vota's own application logic is correct, as long as any critical chain in the cross-chain trust path still uses non-PQ validator signatures, IBC's final security is not post-quantum secure. IBC's quantum risk is compositional: it inherits the weakest point in the signature systems used by the two endpoint chains and the intermediate light clients.

3.4 CosmWasm and On-Chain Contracts

Dora Vota integrates CosmWasm / wasmd / wasmvm. CosmWasm itself is an execution environment and does not automatically provide post-quantum security. Whether a contract is post-quantum secure depends on the cryptographic primitives used inside the contract. The aMACI contracts use Groth16 proof verification, BN254-related verification logic, and BabyJubJub/Poseidon-related tools. Therefore, at the contract level, they also do not provide complete post-quantum security. (raw.githubusercontent.com)

3.5 Hashes, Merkle Proofs, and State Commitments

Compared with signatures and ECDH, components such as state commitments, Merkle proofs, and hash chains are more robust in a quantum setting. Grover's algorithm reduces the complexity of hash preimage search, but 256-bit-output hashes such as SHA-256 still retain roughly a 128-bit quantum security margin at the preimage level. NIST also treats hash/symmetric attacks differently from the failure of public-key assumptions when defining PQ security levels. (csrc.nist.gov)

Impact: Low.

Dora Vota's hashes and state commitments are not the primary PQ risk points. The true high-risk areas are account signatures, consensus signatures, IBC validator signatures, and elliptic-curve/pairing proof systems inside contracts.

4. Dora Vota Post-Quantum Risk Rating

Overall assessment of Dora Vota:

Dora Vota is a typical modern Cosmos appchain that relies on mature ecosystem components under the classical security model. From a post-quantum perspective, however, the base chain is not post-quantum secure. Its post-quantum bottleneck lies in signatures and consensus, not in application modules.

Part II: Post-Quantum Security Analysis of the aMACI Protocol

5. aMACI Architecture and Core Security Goals

aMACI circuits include:

These circuits also share components such as ECDH, ElGamal encryption / decryption, Poseidon hashing, signature verification, Merkle / quinary trees, and message parsing (github.com).

6. Classical Security Logic of aMACI

The core goal of aMACI is to solve the issue in the original MACI where the operator / coordinator can observe identity correlations. In the original MACI, on-chain messages are hidden externally, but because the operator must decrypt and process messages, the operator may see relationships between user behavior and identity. aMACI uses mechanisms such as deactivation, new keys, ElGamal rerandomization, and nullifiers so that, under classical assumptions, it is hard for the operator to prove or identify the relationship between an old key and a new key (ethresear.ch).

From the code and circuits, aMACI's classical security structure is roughly as follows:

1. The user has a BabyJubJub private/public key pair.
2. Voting or state-change messages derive a shared key through ECDH and then use a Poseidon cipher to decrypt the command.
3. The command is verified with an EdDSA-Poseidon signature.
4. The deactivation and add-new-key flows use ElGamal rerandomization to hide the relationship between the old key and the new key.
5. The nullifier uses Poseidon(oldPrivateKey, pollId) to prevent the same old key from being activated or added repeatedly.
6. Groth16 proofs demonstrate that state transitions, deactivation, tallying, and other steps were executed correctly.
7. The on-chain CosmWasm contracts verify the proof and the public input hash.

These mechanisms are quite rigorous under the classical security model: the circuits verify conditions such as pollId, nonce, signature, balance, vote option, Merkle path, state root, deactivation root, and tally commitment (raw.githubusercontent.com).

7. Post-Quantum Analysis of aMACI Core Primitives

7.1 BabyJubJub Private Keys, Public Keys, and ECDH

The Ecdh component in the aMACI circuits uses BabyJubJub elliptic-curve scalar multiplication to derive a shared key from the coordinator public key and voter private key. PrivToPubKey also obtains the public key from the private key via BabyJubJub base-point scalar multiplication and checks that the private key is smaller than the subgroup order (raw.githubusercontent.com).

Post-quantum assessment: Not post-quantum secure.

BabyJubJub is an elliptic-curve group. Its security is based on the hardness of the elliptic-curve discrete logarithm problem. Once Shor's algorithm can run against a group of the relevant size, an attacker can recover private keys from public keys and thereby break ECDH shared secrets. This directly affects aMACI's encrypted commands, deactivation status, and anonymous key-change mechanism.

Specific impact:

This means aMACI has a clear harvest-now-decrypt-later risk: encrypted messages, encrypted deactivation data, public keys, and nullifiers recorded on-chain or publicly may be reinterpreted and decrypted once future quantum capabilities become available.

7.2 EdDSA-Poseidon Signature Verification

The VerifySignature circuit uses EdDSA-Poseidon logic: it applies a Poseidon hash to the command preimage, new public key, and other fields, then verifies the signature on BabyJubJub. MessageValidator combines signature verification with checks for state index, vote option index, nonce, pollId, voice credit, and other fields, finally deciding whether the command is valid (raw.githubusercontent.com).

Post-quantum assessment: Not post-quantum secure.

The hash component of EdDSA-Poseidon is Poseidon, but the signature security still comes from the BabyJubJub discrete logarithm problem. If a quantum attacker can recover the private key from the public key, the attacker can forge valid command signatures. Poseidon hashing does not turn an elliptic-curve signature into a post-quantum signature.

Specific impact:

Therefore, aMACI's property that "the voting command comes from a legitimate user" does not hold in the CRQC model.

7.3 ElGamal Rerandomization and Deactivation Anonymity

aMACI's anonymity focus is the deactivation/new-key flow. In the AddNewKey circuit, the nullifier is set to Poseidon(oldPrivateKey, pollId); the deactivation leaf binds c1, c2, and the ECDH shared-key hash; then the old ciphertext is transformed into new d1 and d2 values through ElGamal rerandomization while proving that the transformation is correct (raw.githubusercontent.com).

aMACI heavily relies on ElGamal re-randomizability to make it difficult for the operator to directly link the deactivation key and the new key. ElGamal has the form c1 = g^y, c2 = m * pk^y, while rerandomization computes d1 = g^z * c1 and d2 = pk^z * c2 (ethresear.ch).

Post-quantum assessment: Not post-quantum secure.

ElGamal hiding and rerandomization unlinkability rely on the hardness of discrete logarithms. After discrete logarithms are broken by a quantum attacker, the attacker can recover randomness, decrypt ciphertexts, and analyze ciphertext relationships. More importantly, aMACI's public nullifier is Poseidon(oldPrivateKey, pollId): once the private key corresponding to an old public key can be recovered by a quantum attack, an attacker can compute the nullifier for every old key and match it against the on-chain public nullifier, directly breaking the anonymous relationship between old key and new key.

This is one of the most critical post-quantum anonymity failure points in aMACI.

7.4 Poseidon Hash / Poseidon Cipher

aMACI uses Poseidon extensively: message hashes, state commitments, nullifiers, input-hash helpers, Merkle trees, Poseidon encryption/decryption, and more. The circuit utilities include multiple Poseidon hashers, Poseidon decrypt, message hash, hash-left-right, and related components (github.com).

Post-quantum assessment: Relatively robust, but not a system-level post-quantum guarantee.

As a hash and permutation primitive, Poseidon mainly faces Grover-style generic speedups in a quantum setting, not Shor-style direct collapse. If the output space is roughly a 254-bit field element, its preimage security can be roughly interpreted as having an approximately 127-bit quantum security margin. However, this is only a generic assessment. Poseidon is not a NIST post-quantum standard for signatures or KEMs, and it cannot compensate for the non-post-quantum components in ECDH, ElGamal, EdDSA, or Groth16.

It is especially important to note that when the key for the Poseidon cipher comes from BabyJubJub ECDH, the real risk is not that Poseidon is directly broken by a quantum attack. The real risk is that the ECDH shared key is recovered by a quantum attack, causing the Poseidon-encrypted content to be decrypted normally.

7.5 Groth16 / BN254 zkSNARK

The aMACI contracts use Groth16 proof verification and import components such as pairing_ce::bn256::Bn256 and bellman_ce_verifier. run_groth16_verify parses the verifying key and proof, then performs Groth16 verification using the public input hash as input. maci-crypto also explicitly depends on ark-bn254 and states that BN254/BN128 is the main curve used by MACI (raw.githubusercontent.com).

Post-quantum assessment: Not post-quantum secure.

Groth16 soundness and knowledge soundness depend on computational assumptions over pairing-friendly elliptic-curve groups. These assumptions fall within the threat range of Shor's algorithm. BN254/BN128 itself is a pairing-friendly curve and is not a foundation for post-quantum proof systems.

Specific impact:

This must be stated precisely: it does not mean that real-world attackers today can already forge Groth16 proofs. It means that Groth16/BN254 security assumptions are not post-quantum assumptions. In the CRQC model, an on-chain verifier accepting a proof is no longer equivalent to saying that "this state transition is trustworthy in a post-quantum sense."

8. Circuit-Level Post-Quantum Analysis of aMACI

8.1 AddNewKey Circuit

The key logic of AddNewKey includes:

• Inputting the old private key, new public key, coordinator public key, deactivation root, ElGamal ciphertext, and other values.
• Computing nullifier = Poseidon(oldPrivateKey, pollId).
• Performing ECDH with the old private key and coordinator public key.
• Verifying that the deactivation leaf is in the deactivation root.
• Rerandomizing the ElGamal ciphertext.
• Compressing public inputs into inputHash. (raw.githubusercontent.com)

Post-quantum assessment: High risk.

Under the classical model, this circuit can prove that "a user who knows the old private key can anonymously add a new key." Under an effective quantum compute regime, the old private key can be recovered from the old public key, the nullifier can be externally enumerated and matched, the ECDH shared key can be recomputed, and ElGamal rerandomization hiding fails. Therefore, the anonymity and authorization of AddNewKey are not post-quantum secure.

8.2 ProcessDeactivate Circuit

ProcessDeactivate does the following:

• Verifies the message hash chain.
• Derives the coordinator public key from the coordinator private key and checks consistency.
• Uses ECDH/Poseidon to decrypt deactivate messages.
• Verifies signatures, pollId, state leaf, and active state.
• Updates the deactivation tree and active state root (raw.githubusercontent.com).

Post-quantum assessment: High risk.

This circuit depends on the coordinator private key, ECDH decryption, BabyJubJub signature verification, Merkle proofs, and Groth16 proofs. Merkle proofs themselves are relatively robust in a quantum setting, but the coordinator key, voter key, signatures, and Groth16 are all not post-quantum secure. A quantum attacker could recover the coordinator private key to decrypt messages, or recover voter private keys to forge deactivate commands.

8.3 ProcessMessages and StateLeafTransformer

ProcessMessages verifies the message hash chain, pollId, state commitment, deactivation commitment, and active state root, then decrypts commands through ECDH and passes them to the state transformer. StateLeafTransformer calls MessageValidator, decrypts the active flag, checks whether the message is valid, and then updates the state leaf, nonce, and vote weights. (raw.githubusercontent.com)

Post-quantum assessment: Critical risk.

This flow carries the voting system's most important logic: who voted for what, how states change, and how voting power is deducted. Its classical security heavily depends on signature unforgeability, ECDH confidentiality, and Groth16 proof soundness. Under the quantum model, all three fail simultaneously, so this cannot be called post-quantum secure vote processing.

8.4 MessageValidator

MessageValidator verifies:

• whether the state index is valid;
• whether the vote option index is valid;
• whether the nonce equals the old nonce plus 1;
• whether the command pollId equals the expected pollId;
• whether the EdDSA-Poseidon signature is valid;
• whether the voice credit is sufficient;
• whether the vote weight is within a safe range;
• finally, whether isValid holds based on the combination of these checks. (github.com)

Post-quantum assessment: Logically complete, but the authentication foundation is not post-quantum secure.

The nonce, pollId, balance, and vote-option checks are good protocol constraints. However, these constraints cannot resist a quantum attack in which the attacker has recovered the legitimate private key. Under the quantum model, the attacker can generate new signatures, new nonces, and new commands instead of replaying old commands.

8.5 TallyVotes

TallyVotes verifies the state commitment, state root, vote-option tree roots, tally commitments, batch index, and public input hash, and updates the tally result tree (raw.githubusercontent.com).

Post-quantum assessment: The hash-commitment layer is relatively robust, but proof-system soundness is not post-quantum secure.

The tally commitment, Merkle root, and salt/hash structure are not the main quantum weaknesses. The real issue is the Groth16 proof. If the proof system's soundness does not hold when the Q-day comes, then the on-chain verifier's guarantee of tally correctness also lacks post-quantum significance.

9. aMACI Attack Scenarios

Scenario A: External Attacker Records On-Chain Data and Decrypts It with Future Quantum Capability

aMACI's encrypted messages, public keys, proofs, commitments, nullifiers, and other data may be retained long-term on-chain or in archival systems. If a future attacker gains quantum capability against BabyJubJub, the attacker can:

1. Recover the coordinator private key from the coordinator public key;
2. Recompute ECDH shared keys;
3. Decrypt historical encrypted commands;
4. Recover voter private keys from voter public keys;
5. Compute Poseidon(oldPrivateKey, pollId) and match it against public nullifiers;
6. Reconstruct the relationship between old keys and new keys.

Result: Historical vote privacy and anonymity do not have long-term post-quantum confidentiality.

Scenario B: Attacker Forges User Voting or Key-Change Messages

If a voter public key is known, a quantum attacker can recover the voter private key and then generate a new command that satisfies MessageValidator, including a correct signature, correct pollId, incremented nonce, valid vote option, and other required fields. Nonces and pollId can only prevent replay; they cannot prevent new-message forgery after the private key has been recovered (github.com).

Result: Vote authorization is not post-quantum secure.

Scenario C: Malicious Operator/Coordinator Gains Quantum Capability

In ordinary MACI, the operator can already decrypt voting messages to complete tallying. The value of aMACI is that it reduces the operator's ability to learn identity correlations. Quantum capability allows the operator to recover old private keys from old public keys and compute public nullifiers, thereby linking old identities/keys with the new-key/deactivation flow.

Result: The anonymity enhancement that aMACI provides over MACI is severely weakened in the post-quantum model.

Scenario D: Forging zkSNARK Proofs or Breaking Tally Soundness

The aMACI contracts use a BN254 Groth16 verifier. Under the classical computing, Groth16 can efficiently prove that circuit constraints are satisfied. Under the quantum model, not for quantum computers. If an attacker can attack the group assumptions relied on by the proof system, the attacker may be able to construct a proof accepted by the verifier even though the witness/statement is not true (raw.githubusercontent.com).

Result: On-chain proof acceptance no longer provides a post-quantum tally-correctness guarantee.

Scenario E: Combined Risk from Dora Vota Base Chain and aMACI

Even if aMACI adopts a post-quantum proof system, when deployed on Dora Vota it still inherits the non-PQ security of Dora Vota's base chain: transaction signatures, validator signatures, IBC security, governance, and contract-call entry points are all not post-quantum secure (raw.githubusercontent.com).

Result: aMACI's post-quantum security cannot be discussed independently of the underlying chain.

10. Component-Level Risks in aMACI

11. Which Parts of aMACI Are Relatively Robust in a Quantum Setting

Quite obviously, the current aMACI implementation cannot be called post-quantum secure. However, to distinguish risk priorities, the following components can be described as not high-priority quantum weak points:

1. SHA-256 input-hash compression
2. Poseidon Merkle trees / message hash chains
3. pollId, nonce, balance, and vote-option validation

12. Final Assessment

Dora Vota Blockchain

Dora Vota (aka CosmosSDK) base-chain post-quantum security rating is: Low.

The reason is straightforward: it is a Cosmos/CometBFT architecture, and chain-level security depends on traditional public-key signatures. User transactions, validator consensus, IBC finality, governance operations, and contract-call entry points all require non-PQ signature systems. Hashes and Merkle state commitments are relatively robust, but they cannot compensate for the quantum vulnerability of the account and consensus layers.

One-sentence summary:

Dora Vota is a standard Cosmos appchain under the classical security model; under the post-quantum model, its base authentication and consensus layers are not post-quantum secure.

aMACI

aMACI's protocol/circuit post-quantum security rating is: Low.

Its classical design is quite complete: encrypted commands, EdDSA-Poseidon authentication, ECDH shared keys, ElGamal rerandomization, nullifiers, deactivation roots, active state, message hash chains, state/tally commitments, and Groth16 proofs. However, most of these key security properties are built on non-PQ primitives such as BabyJubJub and BN254.

The three most serious categories of issues are:

1. Long-term privacy failure: Historical encrypted messages can be subject to harvest-now-decrypt-later attacks, creating coercion and vote-buying risks.
2. Anonymity failure: After old private keys are recovered from old public keys, public nullifiers can be matched, breaking old/new key unlinkability.
3. Proof soundness failure: Groth16/BN254 is not a post-quantum proof system, and the on-chain verifier's acceptance result does not provide PQ-level correctness guarantees.

One-sentence summary:

aMACI is a strong classical-security design, but it is not a post-quantum anonymous voting protocol; in the CRQC model, its privacy, anonymity, authentication, and proof correctness are all fundamentally affected.

13. Summary Rating Table