Refactor/blsag simplify api

[RyderFreeman4Logos]

Title: refactor(blsag): Comprehensive API and implementation overhaul

---

Hi @edwinhere ,

First and foremost, thank you for creating and maintaining this excellent library, nazgul!

While studying and using the library, I identified several opportunities for optimization based on modern Rust design philosophies. With the assistance Gemini 2.5 Pro, I've undertaken a series of in-depth refactors focused on the blsag module.

My core strategy was to first focus on polishing the blsag module to perfection, establishing a rock-solid test suite before considering applying these successful patterns to the other modules.

This Pull Request contains the following logical steps (corresponding to the branch/commit history):

1. test/blsag-suite:

   • Established a new, comprehensive test suite for blsag, covering happy paths, failure paths, and core security properties (unforgeability, anonymity, and linkability).

2. refactor/blsag-info-hiding:

   • Enforced information hiding for the BLSAG struct by making its fields private, enhancing the module's robustness.

3. refactor(blsag)!: Optimize API and improve idiomatic Rust (from refactor/blsag-simplify-api & refactor/blsag-dry-up-impl):

   • This is a major API overhaul aimed at improving performance and ergonomics, especially for large rings:
     • [BREAKING CHANGE] The sign function now returns a Result instead of panicking on failure (e.g., if the signer is not in the ring).
     • [BREAKING CHANGE] The BLSAG signature struct no longer stores the entire ring, making it significantly more lightweight.
     • The sign and verify functions now accept the ring via a slice reference (&[RistrettoPoint]), which completely eliminates the need for ring.clone() on the caller's side.
     • The secret_index parameter was removed from sign to pull complexity downwards.
     • verify and link now operate on references to signatures, avoiding unnecessary clones.
     • The core cryptographic logic duplicated in sign and verify has been extracted into a shared private helper function (DRY).

A Discussion on Next Steps

I would love to get your feedback on this direction for the blsag module first. As I'm not a cryptographer, your expert review of these API changes for cryptographic soundness would be invaluable.

If you approve of this direction, I'd be happy to discuss how we could best proceed with mlsag and clsag:

• Option A: I can continue with the same methodology to refactor and test mlsag and clsag.
• Option B: Alternatively, I could perform the initial implementation and testing, after which you could perform the final, crucial cryptographic review and sign-off.

Either way, I'm very happy to continue contributing to the project.

Thank you again for your time and effort! Looking forward to your feedback.

[RyderFreeman4Logos]

By the way, I’m currently working on performance testing and trying to optimize the performance of blsag through precomputation.

This is because in some scenarios, the size of the public key ring can be as large as a hundred thousand or even millions. On a typical smartphone, signing a ring of size 10_000 takes about 6 to 12 seconds, while for a ring of 1_000_000, the time increases linearly to 10-20 minutes (with slight variations depending on the phone’s CPU).

[edwinhere]

Thanks for this. Give me some time to merge it. I'm busy with work. I use this repository for my resume that's why I keep it updated