Merge remote-tracking branch 'upstream/main'

# Conflicts:
#	.github/workflows/ci.yml
#	go.mod
#	go.sum

.github/workflows/ci.yml

@@ -34,7 +34,7 @@ jobs:
     runs-on: ubuntu-latest
     strategy:
       matrix:
-        go: ["1.25.7", "1.24", "1.23", "1.22"]
+        go: ["1.25", "1.24"]
 
     steps:
       - uses: actions/checkout@v4

CHANGELOG.md

@@ -1,12 +1,33 @@
 # Changelog
 All notable changes to this library are documented in this file.
 
-## [Unreleased]
-- Thread-safety: methods of a given structure (e.g. an evaluator) can be called concurrently. `ShallowCopy` methods are not needed anymore and have been removed. 
-- Refactoring of the InnerSum methods: 
-  - `rlwe.Evaluator.InnerSum` has been replaced by `rlwe.Evaluator.PartialTracesSum`, which applies the automorphisms that correspond to rotations at the scheme level (and sum the results).
-  - Introduction of the `bgv.Evaluator.InnerSum` and `ckks.Evaluator.InnerSum` methods, which have the same behaviour as the old `InnerSum` method for parameters `n` and `batchSize` s.t. `0 < n*batchSize <= ctIn.Slots()` divides the number of slots. Parameters not satisfying these conditions are rejected.
-  - Introduction of the `bgv.Evaluator.RotateAndAdd` and `ckks.Evaluator.RotateAndAdd` methods, which have the same behaviour as the old `InnerSum` method for all parameters. 
+## [6.2.0]
+### Breaking Changes
+- `rlwe.Evaluator.InnerSum` does not exist anymore. It has been replaced by `rlwe.Evaluator.PartialTracesSum`, which applies the automorphisms that correspond to rotations at the scheme level (and sum the results).
+
+  **Migration**: At the scheme level, use the new `bgv.Evaluator.InnerSum`/`bgv.Evaluator.RotateAndAdd` or `ckks.Evaluator.InnerSum`/`ckks.Evaluator.RotateAndAdd` methods (see doc or below for more details). At the `rlwe` evaluator level, use `rlwe.Evaluator.PartialTracesSum`.
+- `ShallowCopy()` methods have been removed. 
+
+  **Migration**: These can safely be removed as the structures can be used concurrently. 
+- The minimum required Go version is now 1.24. 
+
+### Added 
+- Thread-safety: methods of a given structure (e.g. an evaluator) can be called concurrently. 
+- Introduction of the `bgv.Evaluator.InnerSum` and `ckks.Evaluator.InnerSum` methods, which have the same behaviour as the old `InnerSum` method for parameters `n` and `batchSize` s.t. `0 < n*batchSize <= ctIn.Slots()` divides the number of slots. Parameters not satisfying these conditions are rejected.
+- Introduction of the `bgv.Evaluator.RotateAndAdd` and `ckks.Evaluator.RotateAndAdd` methods, which have the same behaviour as the old `InnerSum` method for all parameters. 
+- Allowing to encode N values in BGV when using coefficient encoding
+
+### Improved
+- Documentation and interface of t-out-of-N MHE 
+- `SECURITY.MD` more complete and precise
+
+### Fixed 
+- Ciphertext packing before bootstrapping
+- CKKS encoding respects the `NTT` flag of the plaintext 
+- `DivRoundByLastModulus` does not overwrite the input
+- Homomorphic DFT when decomposition level has multiple matrices
+- `encryptor.encryptZeroSk` returns a ciphertext in the Montgomery domain when appropriate
+
 
 ## [6.1.1] - 17.03.2025
 - Security fix: the evaluation key for switching from dense to sparse key must be generated at the lowest level.

SECURITY.md

@@ -51,7 +51,15 @@ For exact schemes like BFV and BGV, implemented in Lattice, near-perfect correct
 
 ### Multiparty/Threshold Homomorphic Encryption
 
-Multiparty or Threshold Fully Homomorphic Encryption involves secret-sharing the encryption key among multiple users, requiring their collaboration to decrypt data. The scheme maintains security even if a defined threshold number of users are compromised by an attacker. However, when decrypting, a party has access to the raw decrypted value before rounding, even with exact schemes. Since the receiver(s) (i.e. the decrypting party) may be corrupted, the attacker can mount the same kind of attacks, as described by [Checri et al.](https://eprint.iacr.org/2024/116) Fortunately, proper noise flooding as described by [Mouchet et al.](https://eprint.iacr.org/2020/304) (Section IV.E) thwarts these attacks. However, such methods require exponential noise, which will affect the performance and/or the correctness of the protocol.
+Multiparty or Threshold Fully Homomorphic Encryption involves secret-sharing the encryption key among multiple users, requiring their collaboration to decrypt data. The scheme maintains security even if a defined threshold number of users are compromised by an attacker. However, when decrypting, a party has access to the raw decrypted value before rounding, even with exact schemes. Since the receiver(s) (i.e. the decrypting party) may be corrupted, the attacker can mount the same kind of attacks, as described by [Checri et al.](https://eprint.iacr.org/2024/116) Fortunately, proper noise flooding (as introduced by Asharov et al.) and also described by [Mouchet et al.'20](https://eprint.iacr.org/2020/304) (Section IV.E) thwarts these attacks. However, such methods require exponential noise, which will affect the performance and/or the correctness of the protocol.
+
+
+#### On the insecurity of retries
+
+The current implementation of both the $N$-out-of-$N$ and $T$-out-of-$N$-threshold schemes (from [Mouchet et al.'20](https://eprint.iacr.org/2020/304) and [Mouchet et al.'22](https://eprint.iacr.org/2022/780), respectively) assume that any party participating to a given MHE protocol will not generate and transmit its share more than once (see [Mouchet et al.'24](https://eprint.iacr.org/2024/194)). When a party participates in a protocol (public/evaluation key-generation, key-switching or partial decryption) multiple times, several shares for the same public polynomial and secret-key share are disclosed, and the accumulated information may enable efficient key-recovery attacks. 
+This vulnerability has been identified in several recent works ([Mouchet et al.'24](https://eprint.iacr.org/2024/194), [Okada et al.](https://eprint.iacr.org/2025/409), [Colin de Verdière et al.](https://eprint.iacr.org/2026/031)). In particular, [Okada et al.](https://eprint.iacr.org/2025/409) points out that, by adaptively choosing the active set and repeating the protocol, an adversary can manipulate the coefficients and extract linear relations revealing the lower bits of the secret shares via simple linear algebra. More recently, [Colin de Verdière et al.](https://eprint.iacr.org/2026/031) presented a concrete attack.
+
+**Countermeasures:** Both [Mouchet et al.'24](https://eprint.iacr.org/2024/194) and [Colin de Verdière et al.](https://eprint.iacr.org/2026/031) propose countermeasures enabling retries. Moreover, [Colin de Verdière et al.](https://eprint.iacr.org/2026/031) introduced a formal security model for MHE with synchronized decryptors (covering the case of retries), and show that the countermeasures proposed in [Mouchet et al.'24](https://eprint.iacr.org/2024/194) are insecure in the specific case of threshold decryption/key-switching (the countermeasures for the key-generation protocol are unaffected). However, none of these countermeasures is currently implemented in Lattigo, and retrying any MHE protocol must be considered insecure (even when executed by different sets of parties in the $t$-out-of-$N$ case).
 
 
 ### Limitations of the IND-CPA-D model