Flexible traits

[leonbotros]

This PR aims to solve #6 . When some schemes require a public key in the key generation or decryption/decapsulation, an operation may panic. Instead, the code now won't compile. This change is breaking, so we should consider carefully.

This approach has several drawbacks:

• when the concrete type of IBKEM is unknown, you have to have both the parameters to perform extraction and decryption.
• it is a breaking change of our public API,
• it bumps the MSRV to 1.65 (since we use GATs in the solution).

Another approach is to put the pk in the sk and usk, respectively. But imo, this does not make sense from a practical point of view:

• In the case of extraction, you would expect the PKG to have both the mpk and msk.
• In the decryption, a client that decrypts is also often a client that also encrypts, so you would expect the client to have the public key in its cache.

[dobby-coder]

Dobby has started work on this for @rubenhensen.

This pull request has merge conflicts against main. Resolve them, or say why they cannot be resolved.

This note is informational — it starts nothing by itself.

[dobby-coder]

Thanks for the flag, @rubenhensen — I'm on it. I'll try merging main into this PR to clear the conflicts, or explain here if that's not possible.

[dobby-coder]

I tried a local git merge origin/main to check what resolving this would actually take, and did not push anything.

The underlying problem (#6 — IBKEM::decaps taking Option<&Self::Pk> and panicking instead of failing to compile) is still present on main, so this PR is not a no-op or superseded.

But the branch is from November 2022 and main has moved 48 commits since it diverged, so the merge conflicts in 10 of the ~15 source files this PR touches, including the core trait/type definitions in src/lib.rs, every scheme in src/ibe/* and src/kem/*, plus a modify/delete conflict on src/test_macros.rs (deleted on this branch, changed on main) and a conflict in .github/workflows/ci.yml.

This is a breaking API redesign (the PR body says as much), so resolving it means re-deriving the trait-flexibility design against four years of changes to the crypto core, not mechanically picking sides — that's a judgment call only the author or a maintainer can make safely. Separately, the workflow-file conflict means even a resolved merge commit couldn't be pushed by this bot (no workflows permission).

Recommend: the author rebases this by hand onto current main (or the design is re-implemented fresh against today's trait layout), or it's closed if the approach described is no longer wanted.

[dobby-coder]

I tried a local test-merge of main into this branch (not pushed) to see exactly what resolving it would take.

The conflicts are extensive: core trait definitions in src/lib.rs, every scheme under src/ibe/* and src/kem/*, a modify/delete conflict on src/test_macros.rs (deleted here, changed on main), and .github/workflows/ci.yml. Since main has moved 48 commits since this PR was opened back in November 2022, and this PR is itself a breaking trait redesign, resolving it means re-deriving that design against four years of core changes — a judgment call only the author can make, not a mechanical rebase. The workflow-file conflict also means I can't push a resolved merge myself (no workflows permission).

I left a comment on the PR recommending the author either rebase this by hand onto current main or reimplement the design fresh, or close it if it's no longer wanted: #9 (comment)