Skip to content

Crypto impact analysis #557

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Oct 1, 2025
Merged

Crypto impact analysis #557

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
0511b68
add initial req for crypto to impact analysis
perturbing Sep 26, 2025
eed9d3f
add links to zcash standard and the rust benchmarks, as per @ch1bo su…
perturbing Sep 26, 2025
9fafe16
add little intro section for context and talk about peras
perturbing Sep 26, 2025
b44d8f4
add feedback from @curiecrypt
perturbing Oct 1, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 49 additions & 2 deletions docs/ImpactAnalysis.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -417,8 +417,55 @@ The following experiments each pertain to several of the risks above.

# Cryptography

> [!WARNING]
> TODO: Describe requirements and changes to the **Cryptography / Cardano base components**
The security of the votes cast and the certificates that Leios uses to accept EB blocks depends on the usage of the pairing-based BLS12-381 signature scheme (BLS). This scheme is useful, as it allows for aggregation of public keys and signatures, allowing a big group to signal their approval with one compact artifact. Besides Leios, it is also likely that [Peras](https://github.com/tweag/cardano-peras/issues/128) will use this scheme.

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](https://www.ietf.org/archive/id/draft-irtf-cfrg-bls-signature-05.html) IETF draft.

> Note that with the implementation of [CIP-0381](https://cips.cardano.org/cip/CIP-0381) `cardano-base` already contains basic utility functions needed to create these bindings; the work below is thus expanding on that. The impact of the below requirements thus only extends to [this](https://github.com/IntersectMBO/cardano-base/blob/82e09945726a7650540e0656f01331d09018ac97/cardano-crypto-class/src/Cardano/Crypto/EllipticCurve/BLS12_381/Internal.hs) module and probably [this](https://github.com/IntersectMBO/cardano-base/blob/82e09945726a7650540e0656f01331d09018ac97/cardano-crypto-class/src/Cardano/Crypto/DSIGN/Class.hs) outward facing class.

## Requirements

### Functional

- *REQ-BlsTypes*.
Introduce opaque types for `SecretKey`, `PublicKey`, `Signature`, and `AggSignature` (if needed by consensus).
- *REQ-BlsKeyGenSecure*.
Provide secure key generation with strong randomness requirements, resistance to side-channel leakage.
- *REQ-BlsVariantAbstraction*.
Support both BLS variants—small public key and small signature—behind a single abstraction. Public APIs are variant-agnostic.
- *REQ-BlsPoP*.
Proof-of-Possession creation and verification to mitigate rogue-key attacks.
- *REQ-BlsSkToPk*.
Deterministic sk → pk derivation for the chosen variant.
- *REQ-BlsSignVerify*.
Signature generation and verification APIs, variant-agnostic and domain-separated (DST supplied by caller). Besides the DST, the interface should also implement a per message augmentation (as the hash to curve function also has in the IETF draft)
- *REQ-BlsAggregateSignatures*.
Aggregate a list of public keys and signatures into one
- *REQ-BlsBatchVerify*.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@perturbing do you think this will be used for generating an aggregate signature for a batch of persistent and non-persistent votes?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the node will have two contexts/actions in which it will perform aggregation/batching:

  1. If the node is creating the certificates, it is aggregating the signatures of the set of persistent signers.
  2. If the node is verifying the certificate, it is aggregating the public keys and signatures of the persistent voters in the bitmap (see this question) and the non-persistent voters. Note that they sign over the same message, so the fastest verification is just by curve addition rather than repeated pairing calls.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we discussed today, we may need a tag to distinguish between signatures generated by persistent and non-persistent voters. For example:

  • Persistent voters: "PV || MSG"
  • Non-persistent voters: "NV || MSG"

Even so, if we consider the fields of Leios certificate given in here we will aggregate the signatures generated by these parties separately. In this case, we should consider having the batch verification, which I think is not the highest priority at this time.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the reason for such separation?

Batch verification API for efficient verification of many `(pk, msg, sig)` messages.
- *REQ-BlsDSIGNIntegration*.
Provide a `DSIGN` instance so consensus can use BLS via the existing `DSIGN` class, including aggregation-capable helpers where appropriate.
- *REQ-BlsSerialisation*.
Deterministic serialisation: `ToCBOR`/`FromCBOR` and raw-bytes for keys/signatures; strict length/subgroup/infinity checks; canonical compressed encodings as per the [Zcash](https://github.com/zcash/librustzcash/blob/6e0364cd42a2b3d2b958a54771ef51a8db79dd29/pairing/src/bls12_381/README.md#serialization) standard for BLS points.
- *REQ-BlsConformanceVectors*.
Add conformance tests using test vectors from the [intial](https://github.com/input-output-hk/ouroboros-leios/tree/main/crypto-benchmarks.rs) Rust implementation to ensure cross-impl compatibility.

### Non-functional

- *REQ-BlsPerfBenchmarks*.
Benchmark single-verify, aggregate-verify, and batch-verify; report the impact of batching vs individual verification.
- *REQ-BlsRustParity*.
Compare performance against the Rust implementation; document gaps and ensure functional parity on vectors.
- *REQ-BlsDeterminismPortability*.
Deterministic results across platforms/architectures; outputs independent of CPU feature detection.
- *REQ-BlsDocumentation*.
Document the outward facing API in cardano-base and provide example usages. Additionally add a section do's and don'ts with regards to security of this scheme outside the context of Leios (so in general what to look out for).

### Remarks

- Note that the PoP checks probably are done at the certificate level, and that the above-described API should not be responsible for this.
- The current code on BLS12-381 already abstracts over both curves `G1`/`G2`, we should maintain this.
- The `BLST` package also exposes fast verification over many messages and signatures + public keys by doing a combined pairing check. This might be helpful, though it's currently unclear if we can use this speedup. It might be the case, since we have *linear Leios, that this is never needed.

# Performance & Tracing (P&T)

Expand Down