I implemented a Paillier encryption library in Clojure a few months back (which I am currently unable to open-source due to an NDA), and in researching it, I was astounded by the elegance of some of these schemes. I really hope that HE research continues and becomes the standard in the near-ish future.
Whenever I get a free couple weekends, I want to port IBM's HELib to Clojure, so that I can more easily use it for a Java project.
Is it easy to write timing-attack-resistant crypto code in Clojure? Sounds interesting, what company was this for? Thinking of implementing Damgard-Jurik myself sometime.
I think if anything's going to save us from a generalised AI takeover it's this. Even if encrypting the world doesn't stop them it'll make computation too slow for world domination.
If I had $$$$ to fund one scientific endeavor, it'd certainly be HE hands down.
There are a million different ways we're imminently hurtling down an empty abyss, and obviously if I was an inundated Texan or a general I might be more concerned about the environmental or nuclear apocalypse, but as a programmer the Cloud apocalypse is what concerns me the most.
Can you help a newcomer to this understand how HE could help prevent a generalised AI takeover? If it's generalized AI that is optimizing efficiency, wouldn't it quickly realize the large gain to be made by turning off HE? Or is that not possible?
this is the weirdest mishmash of hot buzzwords. what does generalized AI have to do with encryption? are you imagining that generalized AI would be magically able to crack RSA or whatever?
The paper at http://www.shoup.net/papers/helib.pdf should give you an idea of what goes in a HE scheme. They also report performance of multiplying two 1024x1024 matrices: 473 seconds.
Aren't there MASSIVE (read: showstopper) complications when you want to use FHE for "looping" computations?
I always thought FHE was only good if you can fully unroll your "fixed-length" computation, and even then you can only use each "program" once without compromising security.
Every time you want to run a computation on your FHE-enabled VPS you would need to upload data proportional to the maximum number of operations in the computation. Otherwise, re-running the same computation with a different input gives away information about both of your inputs and about the computation.
Under that assumption, general purpose differing-inputs obfuscation cannot exist.
The way I understand it, FHE being applicable to anything other than "unwrapping a path through a circuit" seems implausible. Any claims of arbitrary encrypted computation should be viewed with the highest dose of skepticism.
I worked with Hiyadet, Selcuk, and Abbas last year while I was doing undergraduate research in the Florida International University Cyber Physical Systems Security Lab.
Awesome to see their work getting attention! These guys all put in long hours and love what they do.
21 comments
[ 2.7 ms ] story [ 57.7 ms ] threadWhenever I get a free couple weekends, I want to port IBM's HELib to Clojure, so that I can more easily use it for a Java project.
The crypto code was quite fun to write in Clojure; literally yesterday I just got permission to open source it.
If you want to play with it, the code is available here: https://github.com/tombert/scudlib
Since I have the ability work on it in my free time, I'll probably add more schemes.
There are a million different ways we're imminently hurtling down an empty abyss, and obviously if I was an inundated Texan or a general I might be more concerned about the environmental or nuclear apocalypse, but as a programmer the Cloud apocalypse is what concerns me the most.
Do they actually do better than "factor the RSA key, then compute the output, then re-encrypt"?
I always thought FHE was only good if you can fully unroll your "fixed-length" computation, and even then you can only use each "program" once without compromising security.
Every time you want to run a computation on your FHE-enabled VPS you would need to upload data proportional to the maximum number of operations in the computation. Otherwise, re-running the same computation with a different input gives away information about both of your inputs and about the computation.
In particular the "Extractable Witness Encryption" conjecture is impossible under a reasonable falsifiable assumption: https://pdfs.semanticscholar.org/8587/dba4ff31e8118e9bd5914a...
Under that assumption, general purpose differing-inputs obfuscation cannot exist.
The way I understand it, FHE being applicable to anything other than "unwrapping a path through a circuit" seems implausible. Any claims of arbitrary encrypted computation should be viewed with the highest dose of skepticism.
Awesome to see their work getting attention! These guys all put in long hours and love what they do.