mirrors/lattigo
1
0
Fork 0
mirror of https://github.com/tuneinsight/lattigo.git synced 2025-09-13 03:27:14 +00:00
Code Issues Packages Projects Releases Wiki Activity

issues template

Browse Source
This commit is contained in:
Jean-Philippe
2023-10-18 16:43:46 +02:00
parent 16cd55b259
commit 2f7e47aef0
4 changed files with 28 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
.github/ISSUE_TEMPLATE/bug-report.md vendored
View File

@@ -1,7 +1,7 @@
--- ---
name: Bug Report name: Bug/Regression
about: Report a reproducible bug about: Report a reproducible bug or regression
title: 'affected/package:' title: 'Bug/Regression [<package>]:'
labels: bug labels: bug
assignees: '' assignees: ''
@@ -22,6 +22,7 @@ Please make sure you have answered all the following questions before submitting
### What actually happened? ### What actually happened?
### Reproducibility ### Reproducibility
<!-- <!--
Please provide a short self-contained main.go that reproduces the issue, along with the go.mod and go.sum if necessary. Please provide a short self-contained main.go that reproduces the issue, along with the go.mod and go.sum if necessary.
--> -->

8
.github/ISSUE_TEMPLATE/config.yml vendored
View File

@@ -1,6 +1,8 @@
blank_issues_enabled: true blank_issues_enabled: true
contact_links: contact_links:
- name: Report a Vulnerability
about: To report a vulnerability please contact us directly using the following email: lattigo@tuneinsight.com.
- name: Feature Proposal/Request - name: Feature Proposal/Request
about: We do not use GitHub Issues for features proposals or requests. If you have a proposal or would like to make a request for a feature, please contact us directly using the following email: lattigo@tuneinsight.com. url: https://tuneinsight.com/lattigo/contact
about: We do not use GitHub Issues for features proposals or requests. If you have a proposal or would like to make a request for a feature, please contact us directly.
- name: General Question
url: https://github.com/tuneinsight/lattigo/discussions
about: Ask a question that is not necessiraly related to the use or implementation of the library.

10
.github/ISSUE_TEMPLATE/question.md vendored
View File

@@ -1,8 +1,14 @@
--- ---
name: Question name: Library Question
about: Make sure that your question is directly related to the use or the implementation of the library before submitting it as we do not use GitHub Issues for general discussion. Please use the dedicated https://github.com/tuneinsight/lattigo/discussions instead. If you want to keep your question private, you can contact us directly using the following email: lattigo@tuneinsight.com. about: Ask a question related to the use or implementation of the library.
title: 'Question:' title: 'Question:'
labels: question labels: question
assignees: '' assignees: ''
--- ---
<!--
Make sure that your question is directly related to the use or the implementation of the library before submitting it as we do not use GitHub Issues for general discussion. If your question is general (e.g. "How can I do <xxx> in FHE?"" or "Why don't I get the correct result?"), please use the dedicated https://github.com/tuneinsight/lattigo/discussions instead.
If you want to keep your question private, you can contact us directly using the following email: lattigo@tuneinsight.com.
-->

19
SECURITY.md
View File

@@ -1,19 +1,22 @@
# Report a Vulnerability
To report a vulnerability please contact us directly using the following email: lattigo@tuneinsight.com.
# Code Review # Code Review
Lattigo 2.0.0 has been code-reviewed by ELCA in November 2020 and, within the allocated time for the code review, no critical or high-risk issues were found. Lattigo 2.0.0 has been code-reviewed by ELCA in November 2020 and, within the allocated time for the code review, no critical or high-risk issues were found.
# Security of Approximate-Numbers Homomorphic Encryption # Security of Approximate Homomorphic Encryption
Homomorphic encryption schemes are by definition malleable, and are therefore not secure against chosen ciphertext attacks (CCA security). They can be though secure against chosen plaintext attacks (CPA security). Homomorphic encryption schemes are by definition malleable, and are therefore not secure against chosen ciphertext attacks (CCA security). They can be though secure against chosen plaintext attacks (CPA security).
Classified as an _approximate decryption_ scheme, the CKKS scheme is secure as long as the plaintext result of a decryption is only revealed to entities with knowledge of the secret-key. This is because, given a ciphertext (_-as + m + e_, _a_), the decryption outputs a plaintext _m+e_. [Li and Micciancio](https://eprint.iacr.org/2020/1533) show that using this plaintext, it is possible to recover the secret-key with ((_-as + m + e_) - (_m + e_)) * _a^-1 = asa^-1 = s_ (the probability of _a_ being invertible is overwhelming, and if _a_ is not invertible, only a few more samples are required). Classified as an _approximate decryption_ scheme, the CKKS scheme is secure as long as the plaintext result of a decryption is only revealed to entities with knowledge of the secret-key. This is because, given a ciphertext $(-as + m + e, a)$, the decryption outputs a plaintext $m+e$. [Li and Micciancio](https://eprint.iacr.org/2020/1533) show that using this plaintext, it is possible to recover the secret-key with $((-as + m + e) - (m + e)) \cdot a^{-1} = asa^{-1} = s$ (the probability of $a$ being invertible is overwhelming, and if $a$ is not invertible, only a few more samples are required).
This attack demonstrates that, when using an approximate homomorphic encryption scheme, the usual CPA security may not sufficient depending on the application setting. Many applications do not require to share the result with external parties and are not affected by this attack, but the ones that do must take the appropriate steps to ensure that no key-dependent information is leaked. A homomorphic encryption scheme that provides such functionality and that can be secure when releasing decrypted plaintext to external parties is defined to be CPA<sup>D</sup> secure. The corresponding indistinguishability notion (IND-CPA<sup>D</sup>) is defined as "indistinguishability under chosen plaintext attacks with decryption oracles." This attack demonstrates that, when using an approximate homomorphic encryption scheme, the usual CPA security may not sufficient depending on the application setting. Many applications do not require to share the result with external parties and are not affected by this attack, but the ones that do must take the appropriate steps to ensure that no key-dependent information is leaked. A homomorphic encryption scheme that provides such functionality and that can be secure when releasing decrypted plaintext to external parties is defined to be CPA<sup>D</sup> secure. The corresponding indistinguishability notion (IND-CPA<sup>D</sup>) is defined as "indistinguishability under chosen plaintext attacks with decryption oracles."
# CPA<sup>D</sup> Security for CKKS # CPA<sup>D</sup> Security for CKKS
Lattigo implements tools to mitigate _Li and Micciancio_'s attack. In particular, the decoding step of CKKS (and its real-number variant R-CKKS) allows the user to add a key-independent error **_e_** of standard deviation **_σ_** to the decrypted plaintext before decoding. Lattigo implements tools to mitigate _Li and Micciancio_'s attack. In particular, the decoding step of CKKS (and its real-number variant R-CKKS) allows the user to add a key-independent error $e$ of standard deviation $\sigma$ to the decrypted plaintext before decoding.
If at any point of an application, decrypted values have to be shared with external parties, then the user must ensure that each shared plaintext is first _sanitized_ before being shared. To do so, the user must use the **DecodePublic** method instead of the usual **Decode**. **DecodePublic** takes as additional input **_σ_**, and samples a key-independent error **_e_** with standard deviation **_σ_**, that is added to the plaintext before decoding. If at any point of an application, decrypted values have to be shared with external parties, then the user must ensure that each shared plaintext is first _sanitized_ before being shared. To do so, the user must use the $\textsf{DecodePublic}$ method instead of the usual $\textsf{Decode}$. $\textsf{DecodePublic}$ takes as additional input $\sigma$, and samples a key-independent error $e$ with standard deviation $\sigma$, that is added to the plaintext before decoding.
Estimating **_σ_** must be done carefully and we suggest the following iterative process to do so: Estimating $\sigma$ must be done carefully and we suggest the following iterative process to do so:
1. Given a security parameter **_λ_** and a circuit **_C_** that takes as inputs length-**_n_** vectors **_ω_** following a distribution **_χ_**, select the appropriate parameters enabling the homomorphic evaluation of **_C(ω)_**, denoted by **_H(C(ω))_**, which includes the encoding, encryption, evaluation, decryption and decoding. 1. Given a security parameter $\lambda$ and a circuit $C$ that takes as inputs length-_n_ vectors $\omega$ following a distribution $\chi$, select the appropriate parameters enabling the homomorphic evaluation of $C(\omega)$, denoted by $H(C(\omega))$, which includes the encoding, encryption, evaluation, decryption and decoding.
2. Sample input vectors **_ω_** from the distribution **_χ_** and compute the standard deviation **_σ_** in the time domain (coefficient domain) of **_e = C(ω) - H(C(ω))_**. This can be done using the encoder method **GetErrSTDTimeDom(_C(ω)_, _H(C(ω))_, _Δ_)**, where **_Δ_** is the scale of the plaintext after the decryption. The user should make sure that the underlying circuit computed by **H(C())** is identical to **C()**; i.e., if the homomorphic implementation **H(C())** uses polynomial approximations, then **C()** should use them too, instead of using the original exact function. This will ensure that **_e_**, and therefore **_σ_**, are as close as possible to the actual underlying scheme error, and not influenced by function-approximation errors. 2. Sample input vectors $\omega$ from the distribution $\chi$ and compute the standard deviation $\sigma$ in the time domain (coefficient domain) of $e=C(\omega) - H(C(\omega))$. This can be done using the encoder method $\textsf{GetErrSTDTimeDom}(C(\omega), H(C(\omega)), \Delta)$, where $\Delta$ is the scale of the plaintext after the decryption. The user should make sure that the underlying circuit computed by $H(C(\cdot))$ is identical to $C(\cdot)$; i.e., if the homomorphic implementation $H(C(\cdot))$ uses polynomial approximations, then $C(\cdot)$ should use them too, instead of using the original exact function. This will ensure that $e$, and therefore $\sigma$, are as close as possible to the actual underlying scheme error, and not influenced by function-approximation errors.
3. Use the encoder method **DecodePublic** with the parameter **_σ_** to decode plaintexts that will be published. **DecodePublic** adds an error **_e_** with standard deviation **_σ_** bounded by **B = _σ • (2π)<sup>0.5</sup>_**. The precision loss, compared to a private decoding, should be less than half a bit on average. 3. Use the encoder method $\textsf{DecodePublic}$ with the parameter $\sigma$ to decode plaintexts that will be published. $\textsf{DecodePublic}$ adds an error $e$ with standard deviation $\sigma$ bounded by $B = \sigma\sqrt{2\pi}$. The precision loss, compared to a private decoding, should be less than half a bit on average.