feat: BLS signatures

[Autoparallel]

Bounty Description

Implement Boneh-Lynn-Shacham (BLS) signatures for ronkathon. BLS signatures are a cryptographic signature scheme that enables signature aggregation and operates on pairing-friendly curves. This implementation will build upon ronkathon’s existing curve and pairing primitives to demonstrate signature generation and verification from first principles.

Implementation Requirements

• Implement core BLS signature components in the signatures/bls.rs module:
  • Key generation using ronkathon’s existing group operations on pairing-friendly curves
  • Signing function that maps messages to curve points using a hash-to-curve function
  • Verification function using the existing pairing implementation
  • Basic signature aggregation functionality for multiple signatures
• Utilize existing ronkathon primitives:
  • Build upon the curve/ module for elliptic curve operations
  • Use the existing pairing implementation from the curve/pairings.rs module
  • Leverage the hash functions from the hashes/ module for message preprocessing
• Implement proper error handling and input validation:
  • Verify curve points are in the correct subgroup
  • Handle invalid inputs and edge cases
  • Provide clear error messages
• Documentation and tests:
  • Create comprehensive test vectors including known test cases
  • Test signature aggregation with multiple signers
  • Test edge cases like empty messages and invalid points
  • Document security assumptions and usage guidelines
  • Include examples demonstrating proper usage

Bonus Features

• Implement batch verification for improved efficiency
• Add support for proof-of-possession to prevent rogue key attacks
• Create benchmarking suite comparing single vs aggregated verification
• Implement optimized hash-to-curve algorithms

Resources

• BLS Signatures Specification
• Boneh-Lynn-Shacham Short Signatures (Original Paper)
• Hash to Curve Specification (RFC 9380)
• BLS12-381 for the rest of us

Integration Guidelines

The implementation should:

• Follow ronkathon’s modular design pattern
• Use traits to define signature scheme interfaces
• Build upon existing field and curve arithmetic
• Minimize external dependencies
• Prioritize clarity and educational value over optimization

Criteria

Bounties will be rewarded based on the following criteria:

1. Correctness and security: A thorough review of the implementation should convince our team that they are correct and secure, with all requirements met.
2. Code clarity and quality: Succinct, easy-to-follow code with appropriate naming conventions. Utilize Rust’s type system for flexibility and security (e.g., compile-time checks where possible), and avoid external crates. Optimizations should be a lower priority than clarity, but can be included behind a feature flag as a bonus.
3. Documentation quality: Provide comprehensive README’s, Cargo docs, and inline comments where code itself is not self-explanatory. Prioritize clarity and readability.

[mahmudsudo]

Are there specific descriptions of the deliverables for this issue ?