There’s a PyTorch-style library for that: https://github.com/facebookresearch/CrypTen
Machine Learning on Encrypted Data Without Decrypting It
51–60 of 122 posts
Re: Machine Learning on Encrypted Data Without Decrypting It
#52Earlier quoted context omitted.
This is not how this works. Homomorphic encryption (HE) is best thought of as a software CPU that gives you ways to mutate data (but not read it without the secret key of course). Any computation you run has to be using the instruction set offered by HE: addition, multiplication or rotation. When you do an operation on two ciphertexts, you get a new ciphertext back, but no information on its contents. Now the way you…
Quick question: If you have control of the computation instructions (the software for your HE CPU), can arrange for a leak of information from the encrypted data?
As other posters already mentioned, there's no control flow in the HE instruction set. This is actually one of the reasons neural networks are a great fit for HE, as they often have fixed data access patterns and no control flow.
Re: Machine Learning on Encrypted Data Without Decrypting It
#53Earlier quoted context omitted.
Yep, that's correct. With the minor caveat that we choose an ML model that's "easy" to evaluate using homomorphic encryption.
As someone who is not a cryptography expert, is there any hope of using similar logic to train on encrypted data? Naively it seems like you could perform the same operations on the back propagation steps (or any other update algorithm you're using for non NN models) to arrive at the encrypted version of the parameter updates, which you could then decrypt to get the updated model. Am I missing something here?
Training is a lot tougher. Just doing one gradient update step isn't all that bad (although you may have to play with the loss function a bit, e.g. logit cross entropy is probably tough to evaluate). However, then you need to go and actually do all the steps and gradient updates, so you probably need some form of bootstrapping to be able to evaluate computations of that depth. Also, the use case is slightly less compelling. For training, you can probably get all the parties who have data to coordinate and evaluate an MPC more cheaply than you could with HE alone. I think it'll require a very compelling use case for somebody to go and think through what the best way to do it is and it'll probably depend on the specifics of the application (who has what data, and what are we willing to leak as we go along - e.g. it's a lot easier if you don't care about keeping the weights secret).
Re: Machine Learning on Encrypted Data Without Decrypting It
#54Earlier quoted context omitted.
Just to clarify, homomorphic encryption does not expose patterns. At every point in the computation the ciphertexts are computationally indistinguishable from random. The result of evaluating the ML model will be an encrypted prediction that you then need to send back to whoever encrypted the data (or more precisely whoever has the key - doesn't need to be the same person) so they can decrypt and use the prediction.
Do you have a reference somewhere that backs up your assertions, where I can read more on this topic? I'm super curious about it.
You can get a sense of it just by looking at the classic:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation...
Look for penguin image in ECB mode. Encryption without randomness reveals the patterns! That image is highly educational and makes you think.
Re: Machine Learning on Encrypted Data Without Decrypting It
#55Earlier quoted context omitted.
Yep, that's correct. With the minor caveat that we choose an ML model that's "easy" to evaluate using homomorphic encryption.
As someone who is not a cryptography expert, is there any hope of using similar logic to train on encrypted data? Naively it seems like you could perform the same operations on the back propagation steps (or any other update algorithm you're using for non NN models) to arrive at the encrypted version of the parameter updates, which you could then decrypt to get the updated model. Am I missing something here?
You're quite correct that evaluating the back propagation could be done exactly the same as the forward pass. However, if you want to train for more than a handful of steps you'll have to use an operation called bootstrapping to periodically "refresh" the ciphertexts that encode the model. Bootstrapping is essentially evaluating the decryption circuit of HE using HE itself (with an homomorphically encrypted version of the secret key). The problem is that bootstrapping is much more expensive than the other operations in HE.
People have done very effective training on encrypted data using simpler models, like linear or logistic regression. See for example this work [1] from my colleagues at Microsoft Research.
[1]: https://bmcmedgenomics.biomedcentral.com/articles/10.1186/s1...
Re: Machine Learning on Encrypted Data Without Decrypting It
#56This blog post reminds me of the "Machine Learning Systems are Stuck in a Rut" paper [1], where they mentioned: > It is hard to experiment with front end features like named dimensions, because it is painful to match them to back ends that expect calls to monolithic kernels with fixed layout. On the other hand, there is little incentive to build high quality back ends that support other features, because all the fron…
Julia always seemed great on paper and definitely is a strong candidate for replacing Matlab. But whenever I tried using it, the user experience seemed much more broken than python or c++. It just seems way easier to structure and work on a python + c++ project than it is to structure and work on a Julia project. A moderately sized sane c++ code base compiles and runs faster than whatever gymnastics Julia performs to…
> literally freezes my laptop for seconds
Yep. This has been commented on again and again, but many refuse to show willingness to fix or even acknowledge the problem:
https://github.com/JuliaLang/julia/issues/28092
https://github.com/JuliaLang/julia/issues/17285
https://github.com/JuliaLang/julia/issues/4452
Re: Machine Learning on Encrypted Data Without Decrypting It
#57Earlier quoted context omitted.
Maybe i misunderstood something, but they are not really inferring information. The model is still encrypted, the outsider doesn't know what's going on. Wouldn't salt destroy the homomorphic property?
Homomorphic encryption is malleable[1] in that it can, with enough information, be decrypted without knowing the private keys in some cases. For example, if you can correlate with other data it may be possible to effectively undo the encryption. This is more like anonymization (effectively a one-way hash) than encryption. If you encrypt 2 different values with the same algorithm and key, you will get the same ciphert…
Homomorphic encryption is malleable. But once noise is added, there is no way to exploit malleability.
The big challenge in creation of a fully homomorphic encryption scheme was to make it able to cope with added randomness. This problem remained unsolved starting from 1978 when Rivest, Shamir and Adleman noted probable possibility of such scheme up until 2008 when Craig Gentry came up with solution in his PhD thesis. Gentry's work is a fascinating read by they way.
In other words, homomorphic encryption has the same security guarantees as a conventional crypto.
Re: Machine Learning on Encrypted Data Without Decrypting It
#58If you can infer information from encrypted data then it's not properly encrypted. Generally you would use a salt that would render this type of analyses useless.
Maybe i misunderstood something, but they are not really inferring information. The model is still encrypted, the outsider doesn't know what's going on. Wouldn't salt destroy the homomorphic property?
>Wouldn't salt destroy the homomorphic property?
It depends on how salt is applied. If it is concatenated, the homomorphic property persists. To really destroy it, you would need to mix it up. But then you would lose the malleability, and all that would remain is an equivalence operation from the ring, but not + or *. This still can be useful for some tasks, but not for encrypted calculations or ML.
Re: Machine Learning on Encrypted Data Without Decrypting It
#59Earlier quoted context omitted.
Do you have a reference somewhere that backs up your assertions, where I can read more on this topic? I'm super curious about it.
Read Craig Gentry's PhD thesis, which was the first working fully homomorphic encryption scheme. It's no longer state of the art, but it contains a lot of accessible background on the core problem (which was then open) and why it's important. The person you're responding to is correct. It's an explicit design goal that a fully homomorphic encryption system would not expose any distinguishable oracle about the underly…
What about side effects? Does eg timing of the computations leak data?
Re: Machine Learning on Encrypted Data Without Decrypting It
#60Earlier quoted context omitted.
Julia always seemed great on paper and definitely is a strong candidate for replacing Matlab. But whenever I tried using it, the user experience seemed much more broken than python or c++. It just seems way easier to structure and work on a python + c++ project than it is to structure and work on a Julia project. A moderately sized sane c++ code base compiles and runs faster than whatever gymnastics Julia performs to…
> literally freezes my laptop for seconds Yep. This has been commented on again and again, but many refuse to show willingness to fix or even acknowledge the problem: https://github.com/JuliaLang/julia/issues/28092 https://github.com/JuliaLang/julia/issues/17285 https://github.com/JuliaLang/julia/issues/4452 https://github.com/JuliaLang/julia/issues/1064 https://github.com/JuliaLang/julia/issues/260
What do you mean by "refuse to show willingness to fix or even acknowledge the problem"? Do you realize that two of those issues were started by core contributors?