You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was tracing back through the SEAL development history, and saw that SEAL implemented symmetric-key variants of the CKKS, BGV, BFV schemes. However, upon reviewing the source material for these schemes (such as https://eprint.iacr.org/2016/421.pdf), they only detail asymmetric variants in their algorithms. Are there implementation details for the symmetric variants? A change of this magnitude I would suspect warrant a reevaluation of the security proofs by cryptographers to ensure no holes were accidentally opened. I cannot seem to find any official papers for the symmetric variants.
Also, another question regarding the security policy. It is stated that "decryptions of Microsoft SEAL ciphertexts should be treated as private information only available to the secret key owner, as sharing decryptions of ciphertexts may in some cases lead to leaking the secret key". I assume this is in reference to the attack detailed in https://eprint.iacr.org/2020/1533.pdf, where a decryption of the CKKS scheme could lead to the secret key recovery. This leads me to 2 questions:
Is the mitigation to the CKKS attack (https://eprint.iacr.org/2020/1533.pdf) implemented in SEAL currently? I saw a previous issue from 2020 stating that it was not, but that was 3 years ago.
According to https://eprint.iacr.org/2020/1533.pdf, exact homomorphic encryption schemes, if they are originally IND-CPA secure (which I believe BGV/BFV already are), then are automatically IND-CPA^D secure (IND-CPA with decryption oracles). Practically, this looks as follows:
The adversary may choose an input m and homomorphic evaluation f
By IND-CPA, the adversary receives the ciphertext c of m, this is included in the IND-CPA definition
The adversary, using the public key for evaluation, can evaluate f(c) and f(m), and for exact schemes, observer that f(c) == f(m)
Since the attacker can already calculate the decrypted result on their own, they gain no advantage in deriving the secret key for exact schemes, and if the proven mitigations in https://eprint.iacr.org/2022/816.pdf are applied, then they also gain no advantage for approximate schemes.
Therefore, by these ideas, we should have full reign to share decrypted values of the schemes, with the understanding that our decrypted results may remove some of the privacy from the inputs, but that is for our own evaluation. Is this true for Microsoft SEAL, or are different variants of schemes implemented? As far as I am aware, these security considerations are for the asymmetric variants of the schemes, does the same hold true for the symmetric variants?
Also this is my first Github issue, so let me know if I posted this in the wrong place :), thanks!
The text was updated successfully, but these errors were encountered:
I was tracing back through the SEAL development history, and saw that SEAL implemented symmetric-key variants of the CKKS, BGV, BFV schemes. However, upon reviewing the source material for these schemes (such as https://eprint.iacr.org/2016/421.pdf), they only detail asymmetric variants in their algorithms. Are there implementation details for the symmetric variants? A change of this magnitude I would suspect warrant a reevaluation of the security proofs by cryptographers to ensure no holes were accidentally opened. I cannot seem to find any official papers for the symmetric variants.
Also, another question regarding the security policy. It is stated that "decryptions of Microsoft SEAL ciphertexts should be treated as private information only available to the secret key owner, as sharing decryptions of ciphertexts may in some cases lead to leaking the secret key". I assume this is in reference to the attack detailed in https://eprint.iacr.org/2020/1533.pdf, where a decryption of the CKKS scheme could lead to the secret key recovery. This leads me to 2 questions:
Therefore, by these ideas, we should have full reign to share decrypted values of the schemes, with the understanding that our decrypted results may remove some of the privacy from the inputs, but that is for our own evaluation. Is this true for Microsoft SEAL, or are different variants of schemes implemented? As far as I am aware, these security considerations are for the asymmetric variants of the schemes, does the same hold true for the symmetric variants?
Also this is my first Github issue, so let me know if I posted this in the wrong place :), thanks!
The text was updated successfully, but these errors were encountered: