feat: add Octobear curve and multiset hash on koalabear

[yelhousni]

Description

This PR adds support for the Octobear curve over the degree-8 extension of KoalaBear field and introduces a native multiset hash built on top of it, including a post-quantum vector extension. The target use case is circuit-friendly multiset hashing for computations defined over the KoalaBear field, in particular zkVM memory arguments that will later be verified inside SNARK circuits.

Concretely, this PR:

• adds the new ecc.OCTOBEAR curve and the ecc/octobear package
• reuses field/koalabear for the base field and adds shared E8 support in field/koalabear/extensions
• adds the octobear curve arithmetic, scalar field, generator config, and tests
• adds ecc/octobear/multiset-hash, implementing three flavors of multiset hash on octobear:
  • classical one-point ECMSH via the deterministic y-increment map (uint16 messages)
  • vector ECMSH with a linear domain separator (N=23 coordinates, T=128, M=2^18, uint32 messages)
  • vector ECMSH with a Poseidon2-sponge domain separator (N=23 coordinates, T=256, width-16 sponge, uint64 messages)
• adds recursive cube-root support over the KoalaBear extension tower used by the Cardano solver
• updates the generator/templates needed to support octobear while keeping the rest of the repository green

The one-point construction maps uint16 messages by searching y = 256*m + k for k < 256, solving the resulting depressed cubic over Fp^8, and accumulating mapped points on octobear. The final implementation uses recursive Cardano with binary Lucas sequences at every extension level.

The vector construction keeps N=23 independently domain-separated ECMSH accumulators. After Shor's algorithm computes discrete logarithms, a collision in the vector digest reduces to a bounded modular linear relation, i.e. a SIS-shaped problem with modulus r ≈ 2^248 and dimension N=23 (23·248 = 5704 bits, matching the Linea KoalaBear LtHash baseline). The linear separator is cheap but leaves a "probably" structurally regular post-Shor matrix; the Poseidon2 separator pays a sponge cost but yields a less structured matrix and is the preferred concrete derivation. Both variants preserve inverse-freeness (y_i < p/2) by construction.

Type of change

• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How has this been tested?

The following checks pass locally:

• go test ./field/koalabear/extensions ./ecc/octobear/...

Additional validation performed during development:

• exhaustive Map(uint16) validation over all 65536 inputs of the one-point variant
• per-coordinate inverse-free invariant (y_i < p/2) checked on sampled messages for both vector variants
• homomorphic additivity (Hash(A ∪ B) == Hash(A) + Hash(B) componentwise) for both vector variants

How has this been benchmarked?

Benchmarks were run locally on a MacBook Pro class machine (darwin/arm64, Apple M5, 32GB RAM) with:

go test ./ecc/octobear/multiset-hash -bench . -run '^$'

Current results:

• BenchmarkMap-10: 25440 ns/op
• BenchmarkAccumulatorInsert-10: 6896592 ns/op (256 inserts of the one-point variant)
• BenchmarkHash256-10: 6802114 ns/op (one-point hash over 256 messages)
• BenchmarkMapLinear-10: 512971 ns/op (linear vector map for one message → 23 points)
• BenchmarkMapPoseidon2-10: 570382 ns/op (Poseidon2 vector map for one message → 23 points)
• BenchmarkHashLinear256-10: 157928583 ns/op (linear vector hash over 256 messages)
• BenchmarkHashPoseidon2_256-10: 160487518 ns/op (Poseidon2 vector hash over 256 messages)

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I did not modify files generated from templates
• golangci-lint does not output errors locally
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

---

Note

High Risk
Introduces a large body of new curve and scalar-field cryptography (including cube roots and multiset hashes) intended for security-sensitive zkVM arguments, with limited audit coverage called out in generated code.

Overview
This PR registers the Octobear curve (ecc.OCTOBEAR) and wires scalar/base field metadata in ecc/ecc_field.go, with misspell configured to ignore the name octobear.

It adds the ecc/octobear tree: fp is a thin alias over field/koalabear so imports match other curves; fr is a full generated ~248-bit scalar field (Montgomery arithmetic, amd64/arm64 asm, vectors, Tonelli–Shanks Sqrt and cubic-root Cbrt with dedicated exp chains and tests). The curve package targets 𝔽_p⁸ over KoalaBear for circuit-friendly use (per package docs), including multiset-hash variants described in the PR (classical ECMSH, vector ECMSH with linear or Poseidon2 domain separation).

Review focus: correctness of new field/curve parameters, Cbrt/extension math used by hashing, and performance/security assumptions of the multiset-hash constructions—not re-auditing every generated fr line unless behavior diverges from other curves.

^{Reviewed by Cursor Bugbot for commit f6b0b47. Bugbot is set up for automated code reviews on this repo. Configure here.}

[ivokub]

Sending first round of review. This is mostly about the code generation part.

I think for some implementation having hand-written files is fine, but in that case they should explicilty not have the "DO NOT EDIT" header, this breaks the automatic deletion logic. And I think we can still even now have more code-generation coverage and avoid switching in the generator function on concrete curves (and rather use attribute-base generation logic). Please see the inline comments.

I will do the curve implementation and multiset hash in another round. But it would be easier if we would have more code-generated parts (for the ECC even), so that I know everything matches the templates. What was the block change why files in ecc/kb8 had to be hand-written, not generated? Imo seems quite similar to other curves?

[ivokub]

I now extended the review to the Octobear curve as well. This looks good. I tried locally implementing code-generation for octobear curve and it seems to work. But it is a bit bigger change and imo we should do it in a separate PR after this PR is done.

I also started looking at the multi-set hash. There are a few quickly fixable issues. However, to estimate the security level, it would be better to have concrete references to the paper (right now we just referene as ECMSH_PQ without concrete link), right now I'm not sure about the claim :)

After the small fixes and paper references I think the PR is ready to merge (I'll run another round of review though to be sure)

[ivokub]

Checked now multiset-hash as well. Imo the implementation is clear, but I'm still a bit unsure about the soundness level.

Left a few more comments about potentially making the accumulator more parallelizable. See if it makes sense.

And I still think we should code-generate octobear. But perhaps when it is a bit more settled as a separate PR :) My local experiments show that its doable, the issue is mostly about serialization (due to E8 case handling we need to add) and some different formulas for EC imo.

[yelhousni]

Checked now multiset-hash as well. Imo the implementation is clear, but I'm still a bit unsure about the soundness level.

Left a few more comments about potentially making the accumulator more parallelizable. See if it makes sense.

And I still think we should code-generate octobear. But perhaps when it is a bit more settled as a separate PR :) My local experiments show that its doable, the issue is mostly about serialization (due to E8 case handling we need to add) and some different formulas for EC imo.

Created an issue for the code-generation #846.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit f6b0b47. Configure here.}