feat(transciphering): add OPRF generation

[nsarlin-zama]

closes: please link all relevant issues

PR content/description

small fixes made to the transciphering layer needed for the integer and hl api:

• orpf generation with dedicated/newtype keys
• serialization
• decrypt method on the fhe encrypted key

I created a dedicated TranscipheringParameters enum. For the moment there is only one variant: SameAsCompute. This means that the transciphering key will be created using the compute parameters. This prepares the APIs to future optimizations where we might have dedicated parameters for the transciphering.

---

This change is 

[github-actions]

ℹ️ Backward-compat snapshot: neutral changes

Only neutral changes were detected. This is expected when introducing new versioned types.

---

➕ Neutral

• New enum shortint::backward_compatibility::parameters::transciphering::TranscipheringParametersVersions (1 variants)
• New enum transciphering::backward_compatibility::AesIvVersions (1 variants)
• New enum transciphering::backward_compatibility::CompressedTranscipheringServerKeyVersions (1 variants)
• New enum transciphering::backward_compatibility::KreyviumIVVersions (1 variants)
• New enum transciphering::backward_compatibility::OneTimePadFheSecretMaskVersions (1 variants)
• New enum transciphering::backward_compatibility::OneTimePadPlainSecretMaskVersions (1 variants)
• New enum transciphering::backward_compatibility::SerializableAesFheKeyVersions (1 variants)
• New enum transciphering::backward_compatibility::SerializableKreyviumFheKeyVersions (1 variants)
• New enum transciphering::backward_compatibility::TranscipheringPrivateKeyVersions (1 variants)
• New enum transciphering::backward_compatibility::TranscipheringServerKeyVersions (1 variants)

---

If you encounter any errors or have doubts, you can verify locally by running:

make backward_correctness BASE_REF=<base_branch_or_commit>

Where BASE_REF is the reference branch or commit to check against.

[github-actions]

✅ Forward compatibility matrix unchanged: it still matches the committed baseline.

Matrix

Which released versions can load data produced by this branch. A ❌ is not a failure by itself: it only means forward compatibility is not (or no longer) provided for that type. What matters is whether it was reviewed.

TYPE	1.5.5	1.6.3	1.7.0
CompactPublicKey	❌	✅	✅
CompactPkeCrs	✅	✅	✅
ProvenCompactCiphertextList	❌	✅	✅

[mayeul-zama]

@mayeul-zama reviewed 15 files and all commit messages, and made 4 comments.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on nsarlin-zama and SouchonTheo).

---

tfhe/src/shortint/oprf.rs line 700 at r1 (raw file):

                seed,
                &[num_blocks],
                1, // Each ciphertext is a boolean

Could be stored as let max_random_bits_per_block = 1;
Would make easier to understand what this 1 means here without having to look at function definition

---

tfhe/src/transciphering/ciphers/aes/mod.rs line 102 at r1 (raw file):

            .oprf_key()
            .generate_random_boolean_sequence(seed, 128, sks);
        // Unwrap should not happen because the vec has 128 elements

should not panic
Applies to other places

---

tfhe/src/transciphering/ciphers/aes/mod.rs line 124 at r1 (raw file):

#[versionize(SerializableAesFheKeyVersions)]
pub struct SerializableAesFheKey {
    key: Vec<Ciphertext>,

I guess a [[Ciphertext; 32]; 4] would work here and simplify length management
Applies to other places

---

tfhe/src/transciphering/ciphers/aes/mod.rs line 94 at r1 (raw file):

    }

    pub fn random(

Could be called new_random
Applies to other places

[nsarlin-zama]

@nsarlin-zama made 4 comments.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on mayeul-zama, SouchonTheo, and tmontaigu).

---

tfhe/src/shortint/oprf.rs line 700 at r1 (raw file):

Previously, mayeul-zama wrote…

Could be stored as let max_random_bits_per_block = 1;
Would make easier to understand what this 1 means here without having to look at function definition

done

---

tfhe/src/transciphering/ciphers/aes/mod.rs line 94 at r1 (raw file):

Previously, mayeul-zama wrote…

Could be called new_random
Applies to other places

done

---

tfhe/src/transciphering/ciphers/aes/mod.rs line 102 at r1 (raw file):

Previously, mayeul-zama wrote…

should not panic
Applies to other places

done

---

tfhe/src/transciphering/ciphers/aes/mod.rs line 124 at r1 (raw file):

Previously, mayeul-zama wrote…

I guess a [[Ciphertext; 32]; 4] would work here and simplify length management
Applies to other places

I tried but I'm not sure it simplifies a lot, converting from [T; 128] to [[T; 32]; 4] is more clunky than it should be (unless you have a recipe I'm missing).

And since it's a serialized object anyway, length will always be runtime checked one way or another

[mayeul-zama]

Thanks!

@mayeul-zama reviewed 4 files and all commit messages, made 2 comments, and resolved 3 discussions.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on mayeul-zama, nsarlin-zama, SouchonTheo, and tmontaigu).

---

tfhe/src/transciphering/ciphers/aes/mod.rs line 124 at r1 (raw file):

Previously, nsarlin-zama (Nicolas Sarlin) wrote…

I tried but I'm not sure it simplifies a lot, converting from [T; 128] to [[T; 32]; 4] is more clunky than it should be (unless you have a recipe I'm missing).

And since it's a serialized object anyway, length will always be runtime checked one way or another

Ok