Leios design: Cryptography - Voting, Certificate #599
Conversation
curiecrypt
force-pushed
the
curiecrypt/leios-design-votes-certs
branch
from
606965b to
8bc1314
Compare
curiecrypt
force-pushed
the
curiecrypt/leios-design-votes-certs
branch
from
8bc1314 to
1d3b5c9
Compare
| > Note that keys are not rotated periodically, as forward security is not required for IBs, EBs, or votes. | ||
| #### Key Registration | ||
| - The registration process is responsible for storing public keys and verifying proof of possession. |
There was a problem hiding this comment.
@curiecrypt
Can I confirm the following points about Storage/Lookup:
- Public keys and PoPs are stored on-chain in the stake pool registry (same as VRF/KES metadata), right?
- Nodes have a cached map PoolId → (pk, PoP). PoP is verified at registration time and does not need to be rechecked during vote verification.
Is my understanding correct?
| - The certificate includes: | ||
| - The election ID and the message (the hash of the EB) | ||
| - The identities of participating voters | ||
| - Eligibility proofs for non-persistent voters |
There was a problem hiding this comment.
@curiecrypt
Just to double-confirm, Non-persistent eligibility proofs are not aggregatable.
| ``` | ||
| which derives a secret key from input keying material (IKM) and optional `info`. To use this safely in `cardano-base`, we need to clarify the security guarantees of this construction: what qualifies as a cryptographically secure IKM (length, entropy, generation source) and how `info` should be used (additional entropy vs. domain/context bytes). In parallel, we should examine how `cardano-base` currently sources seeds for other schemes in the `DSIGN` class, review the `blst` keygen C implementation to assess robustness and side-channel posture, align our requirements with the IETF BLS draft’s guidance on key generation (see the “KeyGen” section in the CFRG draft), and determine whether `info` is treated as entropy input or merely contextual/domain-separation data; documenting these findings will let us standardize secure IKM generation and `info` usage for BLS within `cardano-base`. | ||
| - **Proof-of-Possession** |
There was a problem hiding this comment.
@curiecrypt
Can I confirm the PoP functionality: PoP = Sign(sk, tag || pk_bytes) with a dedicated PoP-DST (distinct from vote-DST)?
| ``` | ||
| - **Signature** | ||
| - Implement signature generation and verification APIs that are variant-agnostic and support domain separation, with DST supplied by the caller. This functionality requires integrating with the `blst` library through FFI bindings, using the following functions: |
There was a problem hiding this comment.
@curiecrypt
It is great that you covered the DST!
I am wondering whether we need an Augmentation mode or the fact that we have PoP provides us rogue-key resistance.
| The following non-functional requirements ensure the implementation meets performance and quality standards: | ||
| #### Performance and quality | ||
| - **Performance benchmarks** | ||
| - Benchmark single-verify, aggregate-verify, and batch-verify; report the impact of batching vs individual verification. |
There was a problem hiding this comment.
@curiecrypt I totally agree with this direction. To provide comparability over time, it would be good to run these benchs on the same HW: we can have a machine that runs the benchmarks on any PR and reports results. I think it is good to have this benchmark suite for Haskell that measures perfs of Haskell bindings and a benchmark suite for Rust that measures perfs of Rust bindings, etc. We can lock in a vector manifest shared with the Rust repo; CI runs both sides.
| - **Aggregation** | ||
| This section derives requirements for adding BLS signatures to `cardano-base` and sketches changes to satisfy them. The scope is limited to cryptographic primitives and their integration into existing classes; vote construction/logic is out of scope. This work should align with [this IETF draft](https://www.ietf.org/archive/id/draft-irtf-cfrg-bls-signature-05.html). | ||
| The core cryptographic feature of Leios EB certificates is the ability to aggregate signatures from persistent voters. By combining multiple signatures into a single compact representation, we achieve significant space efficiency within EB blocks. This aggregation also enables more efficient verification, as a single pairing check can replace many individual ones—saving numerous expensive pairing operations while requiring only a few lightweight point additions in $G_1$ or $G_2$. |
There was a problem hiding this comment.
@curiecrypt
I thought that we aggregate all votes over the same (election_id, EB_hash)—from both persistent and non-persistent voters—into one aggregate signature.
A draft of the technical design for cryptographic primitives for the voting mechanism and certificate scheme.
This PR contributes to #542.