 Hi, my name is Mark Schultz. This is a preview of my talk securing approximate homomorphic encryption using difficult privacy based on joint work with Bayou Li, Demi Ali-Machancho, and Jessica Sorrell. The talk concerns polyhomomorphic encryption. The cryptosystem is said to be polyhomomorphic if it admits to privacy homomorphisms or ways of combining encryptions of m and m prime into encryptions of their sum and their product. This suffices to compute arbitrary boolean functions. It's often formalized as an evaluation algorithm such that on input a circuit d and an encryption of a message m, one obtains a cyber-tech c prime that decrypts to dm. Sometimes it only decrypts to a nearby value, though. The difference from the correct value is known as the error. There are many constructions of FHG in the literature. CKKS in particular is not correct. Instead, it has a small error. This scheme will be of central importance to our work. Li and Machancho have suggested mCPA security is the wrong notion for the passive security of incorrect cryptosystems. The correct cryptosystems, decryptions of honest and generate cyber-techs are simulatable and therefore give no information to an adversary. The incorrect cryptosystems, these decryptions can leak information even if the user is only honestly interacting with their oracles. This occurs for CKKS and leads to a distinguishing attack and key recovery attack. Li and Machancho propose a new security definition, which they call NCPAD security or NCPA with decryption oracles. This is different from NCCA security as you can only decrypt honestly generated cyber-techs. In the setting of correct encryption, it's identical to NCPA security, but as CKKS shows, for incorrect encryption, there's a separation between the two notions. Li and Machancho left it as an open problem to achieve NCPAD security for CKKS. After they published their attacks, many libraries implemented countermeasures. These all roughly post-processed decryption by inducing large enough noise in some way, where large enough is controlled by some user, controlled parameter. Our work is to characterize what large enough means concretely. In the full version of our words, we used a variant of differential primacy and considered two separate notions of correctness. In this preview, I will simplify to Gaussian noise funding and static correctness. By static correctness, I mean that the norm of error can be publicly bounded by some function of both the circuit to evaluate and some bound of the norm of the input. The concrete security notion we use is that of C-bit security of Machancho-Waltzner. The particles that have C-bits of security in some cryptographic game, if for every adversary, there is a concrete trade-off between the running time of the adversary, TFA, and the advantage that adversary achieves in the game. We relax this notion to something we call CS-bits of security, where now for every adversary, either this inequality bounding the trade-off between the T of A, the running time, and the advantage is satisfied or a separate inequality bounding solely the advantage of the adversary achieves the satisfied. This is a concrete weakening of the notion of C-bit security. That's easiest to see graphically. This is a graph of the logarithm of the running time of the adversary to the logarithm of the inverse of the advantage. In terms of this graph, a protocol has 128 bits of security if the parameters that any adversary achieves attacking this protocol falls into this blue region. In particular, there are no adversaries that achieve the parameters that are contained in the white region. The notion of CS-bit security enlarges this set of allowed adversaries slightly. For the particular example of S equals 96 bits of security, it enlarges it to this cyan region. This set of additionally allowed adversaries is a non-trivial set. There are new adversaries allowed by this attack, but all of these adversaries have explicitly low advantage. In the example at hand, all of them have advantage less than two to the minus 96, independent of the running time. And if one wants to achieve higher advantage, one has to go back to the old adversaries, the ones that previously existed from the 128-bit security optimization. So while this does concretely introduce new adversaries and is therefore a weakening of the security notion, it's in a controlled way that we view as likely acceptable in many situations. Using this novel notion of concrete security, we're able to get significant gains. Our main theorem can be raised as follows. This CTKSNC bits of NCPA security, post-processing by adding S over two plus the logarithm of the bound of the size of the error contained in this hypertext, bits of IID gaussian noise achieves CS bits of NCPAD security. This is S over two additional bits of noise if one thinks about it. It's nearly tight for S bits of NCPAD security. In particular, we have an attack that shows that S over four additional bits is insecure. By using this weaker notion, this CS bits of hearing notion, we can obtain substantial gains for even a moderately large S. Concretely, using S equals 96, we can attain a countermeasure that has 15 bits of smaller parameters, which is 20% of the total noise that we do an app. And for S equals 64, this becomes 30 bits smaller, which is roughly 35% of the total noise. While we apply this to the setting of FHE, we expect this to be broadly applicable whenever one is competing, combining a computational primitive in our case FHE with some statistical primitive in our case differential privacy. In summary, we find that post-processing with between 25 and 82 bits of additional Gaussian noise is suffices to achieve 128 S bits of NCPAD security for a wide range of S between 32 and 128 in particular. The precise S which one chooses should be application dependent in a way that will be elaborated on in the full version of the talk. CKKS limitations that support 128 bits of plaintext precision can easily fit a countermeasure. Implementation with only 64 bits of plaintext precision may be more difficult to secure with our countermeasure. While one can secure them likely by choosing small enough S or by exposing less plaintext precision to users of the library, this may make CKKS in these small precision settings less competitive with other FHE schemes. While our countermeasure uses large amounts of noise, we have a lower bound on this noise, at least in setting of C bit security with Gaussian noise. So this large amount of noise does seem interesting.