Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Machine Learning on Encrypted Data Without Decrypting It

juliacomputing.com

Post reply on HN
Print view View original

41–50 of 122 posts

Re: Machine Learning on Encrypted Data Without Decrypting It

#41

Post by orbifold »

ChrisRackauckas wrote: post #20

This 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 create a single 2d plot (literally freezes my laptop for seconds). It also installs gigabytes worth of libraries into global directories by default. The compiler itself is also of questionable quality compared to clang, Swift or Ocaml.

Re: Machine Learning on Encrypted Data Without Decrypting It

#42

Post by nslocum »

orbifold wrote: post #41
ChrisRackauckas wrote: post #20

This 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…

Julia is compiled using LLVM.

Re: Machine Learning on Encrypted Data Without Decrypting It

#43

Post by eigenspace »

yowlingcat wrote: post #24
ChrisRackauckas wrote: post #20

This 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…

Thanks for this provocative comment -- if you don't mind me asking, what do you think the tradeoffs are between using Julia and Python for ML in production? I get the idea of right tool for the right job and all, and I know that Python has a fantastic ecosystem. But, how close is Julia? How developed is the ecosystem right now, and how fast is it developing?

Julia has a smaller ecosystem than Python for sure, however julia has a couple of key ecosystem advantages that make it punch well above its weight class.

It really just boils down to the fact that julia's core value proposition is primarily enticing to domain experts trying to implement new algorithms without wanting to worry about switching languages for performance hotspots or having to reimplement existing functionality from other packages. Julia packages tend to be small, focused and astonishingly composable.

Hence, the proportion of the community that are actively developing and maintaining state of the art pacakges in julia is way higher than that in other languages like Python.

Furthermore, even if you're not some super researcher developer, Julia substantially lowers the bar for mere mortals such as myself to do package development. The composability I mentioned above means that I can stand on the shoulders of giants as I implement my own stuff, plus the fact that the majority of libraries are written in pure julia means that I can easily "peek under the hood" to figure out how they work and learn from them.

It's hard to make broad statements about how much ecosystem support one can expect from julia without first specifying the field. Some fields have fantastic julia support and others haven't received enough attention. It really just depends on if someone from your field has started making good packages yet.

Re: Machine Learning on Encrypted Data Without Decrypting It

#44

Post by mcguire »

osaariki wrote: post #37
falcolas wrote: post #2

Before reading: "I bet they're using homomorphic encryption to expose patterns in the encrypted data" After reading: Yup. It makes sense, so long as your resulting model is run against similarly encrypted data, the same patterns will be there for the ML to identify. Which is, of course, one of the issues with homomorphic encryption.

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?

Re: Machine Learning on Encrypted Data Without Decrypting It

#45

Post by eigenspace »

orbifold wrote: post #41
ChrisRackauckas wrote: post #20

This 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…

Compiler latency is being actively worked on and a PR was just pushed to Plots.jl which halved the time to first plot for many users.

Note that even before this though, it's just the compilation phase for the first plot that's expensive. Plotting itself is quite fast in julia, and if you start up julia with the command line argument `--compile=min` you'll see very very fast first plots. Obviously, this will come with a runtime performance cost though.

Re: Machine Learning on Encrypted Data Without Decrypting It

#46

Post by Dylan16807 »

mcguire wrote: post #44
osaariki wrote: post #37

Earlier 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?

The software can only do arithmetic in a fixed pattern, no "if" statements or while loops or anything. Any conditionals have to be faked with arithmetic.

So, since the arithmetic is secure (otherwise it wouldn't be HE), and the entire runtime pattern is fixed up front and made of nothing but arithmetic, there's no way to leak anything.

Re: Machine Learning on Encrypted Data Without Decrypting It

#48

Post by KenoFischer »

mcguire wrote: post #44
osaariki wrote: post #37

Earlier 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?

In a properly functioning HE scheme, the party doing the evaluation cannot obtain information about the encrypted data, even if they do the operation incorrectly. Without further measures, they can of course compute an incorrect value, which depending on the larger protocol can sometimes be an issue (e.g. consider the scenario where after decryption the client shares the prediction with the server for some reason - in that case, if the server sends the original image ciphertexts, instead of predictions, they can trick the client into decrypting the original image). There is also always the risk that whoever is choosing the instantiation of the cryptoscheme knows something you don't and picks weak parameters, but that's just all the usual attack modes on cryptographic schemes.

Re: Machine Learning on Encrypted Data Without Decrypting It

#49

Post by Analog24 »

KenoFischer wrote: post #25
Stasis5001 wrote: post #22

As somebody with some ML background but no expertise in crypto, is the following ELI~20 summary correct? We take an ML model trained on unencrypted data, use a 'homomorphic evaluation' technique (let's just leave that as magic here) to convert the model operation-by-operation to a model that runs on encrypted data, do a little more crypto magic, and we've solved the business problem described at the beginning of the…

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?

Re: Machine Learning on Encrypted Data Without Decrypting It

#50

Post by garganzol »

falcolas wrote: post #2

Before reading: "I bet they're using homomorphic encryption to expose patterns in the encrypted data" After reading: Yup. It makes sense, so long as your resulting model is run against similarly encrypted data, the same patterns will be there for the ML to identify. Which is, of course, one of the issues with homomorphic encryption.

The encryption done right mixes a random noise to the encrypted data exactly to avoid pattern recognition. Homomorphic encryption does it too.

Otherwise it would be trivial to analyze and eventually crack the scheme. This is especially true for homomorphic encryption where an attacker can employ math operations to solve equations in order to reveal as much data as he/she humanly can.

Post reply on HN