feat: make sure keygen generates homPRF key

[kc1212]

Description of changes

Integrate homomorphic prf keygen on the service level.

There is a subtle issue around resharing. Namely when we rehare a sk between two different sets, set2 does not know whether set1 has a hom. prf key or not, so it does not know whether to run the protocol. The workaround is to have set2 detect from the public keys whether resharing should be run on the hom. prf keys. This means set1 and set2 is setting the flag oprf_key_present from different sources, the former sets it using its own secret key share, the latter sets it using what it finds in the public key.

Issue ticket number and link

Closes zama-ai/kms-internal#2980

PR Checklist

I attest that all checked items are satisfied. Any deviation is clearly justified above.

• Title follows conventional commits (e.g. chore: ...).
• Tests added for every new pub item and test coverage has not decreased.
• Public APIs and non-obvious logic documented; unfinished work marked as TODO(#issue).
• unwrap/expect/panic only in tests or for invariant bugs (documented if present).
• No dependency version changes OR (if changed) only minimal required fixes.
• No architectural protocol changes OR linked spec PR/issue provided.
• No breaking deployment config changes OR devops label + infra notified + infra-team reviewer assigned.
• No breaking gRPC / serialized data changes OR commit marked with ! and affected teams notified.
• No modifications to existing versionized structs OR backward compatibility tests updated.
• No critical business logic / crypto changes OR ≥2 reviewers assigned.
• No new sensitive data fields added OR Zeroize + ZeroizeOnDrop implemented.
• No new public storage data OR data is verifiable (signature / digest).
• No unsafe; if unavoidable: minimal, justified, documented, and test/fuzz covered.
• Strongly typed boundaries: typed inputs validated at the edge; no untyped values or errors cross modules.
• Self-review completed.

Dependency Update Questionnaire (only if deps changed or added)

Answer in the Cargo.toml next to the dependency (or here if updating):

1. Ownership changes or suspicious concentration?
2. Low popularity?
3. Unusual version jump?
4. Lacking documentation?
5. Missing CI?
6. No security / disclosure policy?
7. Significant size increase?

More details and explanations for the checklist and dependency updates can be found in CONTRIBUTING.md

[github-actions]

Consolidated Tests Results 2026-05-04 - 13:41:07

Test Results

9 passed

Details

9 tests
not captured
junit-to-ctrf
build-and-test test-reporter #1867
feat: make sure keygen generates homPRF key #560

test-reporter: Run #1867

Tests 📝	Passed ✅	Failed ❌	Skipped ⏭️	Pending ⏳	Other ❓	Flaky 🍂	Duration ⏱️
9	9	0	0	0	0	0	not captured

🎉 All tests passed!

Tests

View All Tests

Test Name	Status	Flaky	Duration
k8s_test_crs_uniqueness	✅		32.8s
k8s_test_insecure_keygen_encrypt_and_public_decrypt	✅		2m 6s
k8s_test_insecure_keygen_encrypt_multiple_types	✅		2m 17s
k8s_test_keygen_and_crs	✅		2m 1s
k8s_test_keygen_uniqueness	✅		5m 15s
k8s_test_centralized_insecure	✅		54.4s
nightly_full_gen_tests_default_k8s_centralized_sequential_crs	✅		1.8s
k8s_test_centralized_insecure	✅		54.2s
nightly_full_gen_tests_default_k8s_centralized_sequential_crs	✅		1.8s

_{🍂 No flaky tests in this run.}

Github Test Reporter by CTRF 💚

🔄 This comment has been updated

[titouantanguy]

LGTM ! I think it's fine to deduce whether there is a dedicated oprf from the public key during resahring as it's trusted too (cause we check a majority of the resharer give us the same)

[titouantanguy]

Probably would need to ask tfhe-rs.
(more genrally, could be nice to have something that gives a ref to the inner keys instead of having to take onwership)

[kc1212]

improved slightly in 37b620a also asked tfhe-rs

[titouantanguy]

part of this fn is duplicated with check_oprf_correctness from service/src/client/key_gen.rs I believe ?
Should we try and factor the duplicated part somewhere accessible to both here and there ?

[kc1212]

refactored in 37b620a

[titouantanguy]

What about modifying the line above with

num_triples_needed +=
// Raw triples necessary for the regular BK, the OPRF BK and the SnS BK
self.lwe_dimension().0 * (2*self.glwe_sk_num_bits() + self.glwe_sk_num_bits_sns());

[kc1212]

refactored in 37b620a