expand the content

Author: curiecrypt

docs/leios-design/README.md

@@ -592,9 +592,24 @@ The requirements are organized into two main categories: **core functionality**,
     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:** The `blst` C library does not provide a direct interface for generating a proof of possession ($PoP$). Therefore, this functionality must be implemented manually in `cardano-base`, leveraging the existing `blst` bindings to construct a $PoP$ from the available primitives.
 - **Public key derivation:** Implement deterministic derivation of the public key ($pk$) from the corresponding secret key ($sk$) for the selected BLS variant. This requires adding a FFI binding to the `blst` library to enable secure and efficient key derivation within `cardano-base`.
-- **Signature:** Implement signature generation and verification APIs that are variant-agnostic and support domain separation, with DST provided by the caller. 
-- **Aggregation**
-- **Batch verification**
+  ```C
+  void blst_sk_to_pk_in_g1(blst_p1 *out_pk, const blst_scalar *SK);
+  void blst_sk_to_pk_in_g2(blst_p2 *out_pk, const blst_scalar *SK);
+  ```
+- **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:
+  ```C
+  void blst_sign_pk_in_g1(blst_p2 *out_sig, const blst_p2 *hash, const blst_scalar *SK);
+  void blst_sign_pk_in_g2(blst_p1 *out_sig, const blst_p1 *hash, const blst_scalar *SK);
+  ```
+  For single-signature verification, correctness can be established through a standard pairing check between the signature, message hash, and public key. See [this](https://www.ietf.org/archive/id/draft-irtf-cfrg-bls-signature-05.html#name-verify).
+- **Aggregation:** 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$.
+  To support this functionality, several helper functions should be implemented:
+  - A function to aggregate multiple public keys into a single aggregated key.  
+  - A function to aggregate multiple signatures into a single aggregated signature.  
+  - A function that, given a message and multiple $(pk, sig)$ pairs over that message, performs batch verification.
+
+  The first two functions are particularly useful for building an accumulator that locally tallies Leios votes and aggregates them in advance for block production. The third provides a one-shot approach for efficient verification. Since the optimal aggregation strategy depends on when and how votes are combined, all three functions should be implemented to support flexible and efficient use within Leios.
+- **Batch verification:** Implement a batch verification API to efficiently verify multiple $(pk, msg, sig)$ tuples. This requires adding FFI bindings to the `blst` library. The underlying C functions can be composed to load multiple $(pk, msg, sig)$ combinations into a single pairing context for verification. When many of the messages are identical, it becomes more efficient to merge them beforehand. Therefore, it is advisable to use a key-value data structure where each $msg$ serves as the key, and the corresponding values are the multiple $(pk, sig)$ pairs that can be aggregated using the existing aggregation functions.
 - **DSIGN integration**
 - **Serialization**
 - **Conformance vectors**