Future of Data Privacy Will explain 1) Def 2) Why important 3) Real world 4) Related work Also: CS research is light into the future, not just ivory tower abstract.
do business TLS gives you 1) Some assurance you’re connecting to the right server (unless you own a Lenovo), 2) some protection from MITM Good enough for shopping?
• Password reuse • Metadata • Social engineering • Side channels • Implementation errors • GPG too hard to use We tried. But strong crypto didn’t fix all our problems. Better than nothing, but can we do better?
invest? Ask for income, SSNs of your children, what you spend on health care, bank account passwords, etc., give you (click) pretty charts. Or what if I want to prepare your taxes. I’ll need all your info, and I can ask for real money from state government on your behalf. Good idea?
to Steal Frequent Site Visits Look at what customer wants, you want. Note symmetry. Customer desires may be a bit contradictory, but line up nicely with service provider desires. Symmetry in software = Opportunity!
Cyphertext Computation Data Plaintext Result Plaintext Define plaintext, cyphertext, computation. Cyphertext should be indistinguishable from random bits(hand waving) Secure! No key exchange (hard)! Keys stay on client. Can anyone spot the problem with this solution? Considered maybe impossible for a long time. Changed in 2009. How? Stop me now if terms don’t make sense.
can do a homomorphic concatenation on cyphertext! Homomorphic operations don’t have to be the same as corresponding non-homomorphic operation, but in this case it is. We’ll look at stronger choices later, but first…
privacy preserving concatenation of strings. Get the VC $$$$, foosball table… But there’s a problem with this idea. (Not because it’s insecure. Nobody cares about that, or they wouldn’t use SnapChat.) Why won’t this work? You’ll never guess…
enough, it’s patented (by SAP). Cryptographers have been working on HE for a long time. Goldwasser and Micali won Turing award, but for semantic security, not HE. Chose concat example as simple/joke, found the patent later. Security industry may or may not have noticed HE, but patent lawyers have!
NB: Unpadded RSA is insecure! Simple, but insecure. Cryptosystem security is an end to end pipeline, not a single algorithm. Feel free to ignore the algebra, point is
• Doesn’t have to be (quite) Turing complete • Conditional branching and loops, but… • Cannot perform conditional jumps based on (encrypted) user input What are the operations I really need? Must be able to write any program, but not necessarily execute arbitrary programs. Customer and service provider agree on service in advance. Can do taxes, but not your homework. What operations give me all of the above? (Cannot perform conditional…) => Branch prediction won’t work!
AND and NOT • XOR and AND Need a new kind of computer. Want to compute anything, not just *! Let’s start from the basics. Logic gates! If we have homomorphic logic gates we can do what we need. Homomorphic * insufficient. What gates do I need to perform any computation? Homomorphic NAND would be OK. Define NOR. NOR via NANDS. De Morgan’s Laws. What does any of this mean?
1 1 0 * 0 1 0 0 0 1 0 1 Adding + multiplying a bit very simple. So are computers. Need building blocks which can work homomorphically but be built into anything we need. Start with bits. + looks like XOR. * looks like AND. All I need! Can grow from there.
else second .. > choose(True, False, True) => True > choose(True, False, False) => False ﬁrst choose_ﬁrst second Branching hard, but: Here’s a program I wrote. Normal computers eval condition, execute selected path. …so if I have a homomorphic and, or, and not… or just nand, now I can write logic. Branching becomes a truth table. click. As a circuit. Circuits easy.
> 1: .. result *= n .. n -= 1 .. return result > def my_factorial_less_than_20(n): .. result = 1; .. for i in range(2, 20): .. result *= 1 if i > n else i .. return result > my_factorial_less_than_20(4) => 24 > my_factorial_less_than_20(100) => 121645100408832000L > my_factorial_less_than_20(1000) => 121645100408832000L Here’s another program I wrote. Explain factorial. Click. Here’s a really strange version. Why? Note n Program has interesting properties. Bounded loops are decidable! Security vs. efficiency.
Cyphertext Multiply (Lossy) Found strong encryption scheme. Not perfect; has homomorphic + and lossy homomorphic *. Too many *s and can’t decrypt. We will look at bootstrapping in more detail on next slide Explain lossy multiplication here.
Bootstrappable Encryption Every time you decrypt, you “reset” errors. Only a student with a thesis deadline could have thought of this. Works, but inefficient in time and space. Maybe work around? PKE is slow, but combine with SE for performance.
want to talk about 2 party secure computation, but… It’s often the case you want to talk about f(alice_value, bob_value) without revealing either arg. ZKPs do exist, but can be tricky.
Computes and sends c’ = E(f(x,y)), ZKP of c’ correctness to Alice Decrypt c’, compute ZKP of valid decryption, and return both to Bob HELLO My Name Is Alice HELLO My Name Is Bob Want to compute f(aliceData, bobData). How does Alice know Bob used correct input? How does Bob know Alice didn’t lie about result?
to third parties ! All “new” cryptosystems are relatively untested and security not proven. ! Space issues ! Often computationally expensive ! Client complexity and deployment ! Not always clear when to choose fully homomorphic algorithms. ! Not a cure-all. Metadata and side-channels still a problem ! Moving target! ! Patent encumbered “New” -> (Both in terms of algorithms and implementation.)
concede that making this scheme practical remains an open problem.” • “There exist well known solutions for secure computation of any function… It seems hard to apply these methods to complete continuous functions or represent Real numbers, since the methods inherently work over finite fields.” • “An encryption scheme with these two properties is called a homomorphic encryption scheme. The Paillier system is one homomorphic encryption scheme, but more ones [sic] exist.” Hand-waving which wouldn’t be allowed in a freshman term paper
Gentry. Communications of the ACM, Vol. 53, No.3 • Building the Swiss Army Knife, by Boaz Barak and Zvika Brakerski • HElib (source code) • CryptDB: Processing Queries on an Encrypted Database, by Raluca Ada Popa, Catherine M.S. Redfield, Nickolai Zeldovich, and Hari Balakrishnan