Beyond ZK: Next Steps for Compliance and Constrained Encryption on Blockchains with Matthew D. Green

Transcript

all right welcome everyone to uh today's a16z crypto research seminar very happy to introduce Matt Greene uh professor at Johns Hopkins University is super well known um from the blockchain space is an applied cryptographer more generally very ambitious uh talk title for us today we dialed it down a little bit beyond ZK yeah thank you um good so I changed the title of this talk I was gonna add all sorts of exciting stuff to lure people in like compliance and constraint encryption I dialed it down a little I'm going to talk a little bit more about different ways of computing on encrypted data and some of them have something to do with blockchains and some of them are non-blockchain related and this whole thing kind of fits together um because I have this kind of obsession

with figuring out how do we do different modes of computation um you know like that I've always wanted to do since I was a grad student but we can't necessarily do with the tools that I had as a grad student and now we're starting to see all these new tools let's see what kind of things we can do with them and look a little bit uh farther in the future um mostly I work on applied crypto most of you know me but I should probably say like what do I do I do mostly I've worked on a lot of privacy preserving protocols I do a lot of stuff with like messaging and encryption so it's all very practical sometimes I look at reverse engineering things like we did a bunch of reverse engineering stuff during the Snowden time and looked at dual EC I spent a lot of time on Twitter

shouting at Apple and this actually is a talk that has something to do with apple I tried to get them excited about it and they said this is totally theoretical so that was not exciting but uh mostly it's all it's all fun and practical um the motivation for this talk is a little bit what I just said um we have learned over many years to do things that seemed impossible impossible is a strong word infeasible when I was a grad student so specifically I remember having like the biggest struggles when I was designing protocols as a PhD student like oh my God I have to Hash something like how could I possibly do a zero knowledge proof that I've done like a real hash function that was like the most impossible thing so we had to like engineer around all that stuff and now I

talk to people and they're like oh yeah you just throw shot three into a hash function right Stark or something and it's like the whole world has changed and it's good I'm happy the world has changed because it means that we can now do these great powerful things um but it sucks because in other ways it means that the problems aren't as interesting anymore um and one of the things that's made this possible is obviously the rise of succinct zero knowledge because it gives us this amazing ability to do things um you know we have all these different Technologies I'm going to kind of categorize them with uh succinct zero knowledge obviously the idea is we can reason about secret data which is something I care a lot about with the limitation that that data has to be owned by a single person right so I have

to know my witness I can't necessarily do joint computations over data but that's okay we can do some things with that and it's really good the next thing obviously the next Frontier that we haven't really tackled in the Practical world is really efficient Computing on encrypted or rather private data which we can do with things like fhe uh fully homomorphic encryption and NPC and that lets us do joint reasoning over secret data this is kind of the next thing hasn't really happened practically the even better next thing that we might be able to to get to someday is obfuscation or limited obfuscation that we can actually achieve which is the ability to reason jointly about secret data owned by more than one party without doing interaction so that's kind of a dream world like maybe someday we'll be able to do that and then the final step which

I think is the coolest possible thing is not only can we do obfuscation maybe someday we could do programs that actually have limited States so I can give you a program an entire program that you can run and that program will not let you just feed every possible input into it and get the output because that would be very bad we can actually somehow limit the number of times you can query that so it's kind of just all of the additional things with joint State and limiting the number of interactions and this actually unfortunately is even stronger than obfuscation and so like this is the hierarchy of all the Computing on encrypted data things maybe I don't know somebody could tell me if that's theoretically true the thing I want to say oh good it came up is like we're doing great it's a synced everything I

know Justin's here so like he's making improvements every day wonderful the fhe stuff pretty academic and all all this other stuff like yeah there's some theoretical results but like outside of using Hardware which I am going to talk about a lot we don't really know how to do these things in practice yet okay why do we care about this well ZK and I'm sorry it's not like quite enough to do a lot of things we care about I was going to spend a lot more time motivating that but I didn't really have time um to give that in this talk but I can give you just one you know we know it does scaling we know it does Private cryptocurrency things but once you start building other protocols it starts to kind of you run into these problems the big problem I just tell you like I have

a startup and the problem we ran into was somebody said hey it's a compliance startup how do you do suspicious activity reporting so the idea is I want to send a transaction on some kind of part of a blockchain and the bank has a policy that they're going to evaluate on that transaction and they're going to say look there's going to be a suspicious activity report generated if and only if you violate that policy which is great it's not great it's bad but like this is what banks actually want and the question you can the thing you can do is you can say Okay ZK is wonderful I will just you know check my own data on the non-secret policy they're going to hand me and then if I violate the policy see I will encrypt a message that says I'm in trouble and then I'll put a ZK proof that I did that

but of course no criminal is going to actually do that part they're not going to do that the policy if the policy is public they'll just circumvent the policy by not doing the transaction so you need some way to actually do a joint computation where two parties are putting input this is very simple we're not talking about like the world of NPC we're talking about essentially two-party computation but it needs to be like very low interaction non-interactive NPC which we can do but the point is like even achieving very simple kind of functionalities that you do every day when you go to the ATM machine really to do them privately is beyond ZK and you start having to tack in these other functionalities like nimpc which are harder so this is not totally easy you can't solve things like Mev as far as I know with just DK and

you can't do a whole bunch of other things like private smart contracts and exchanges and so on I would claim I don't know if it's true but I think it's true okay good so what we really want and I'm just going to jump through a lot of this is not a talk on like everything to do with MPC it's not a talk on uh uh definitely not a talk on like building obfuscation schemes but what we really want to build is we want to build something that kind of acts like a trusted box it's trusted execution environment where we can put all of our software arbitrary software preferably inside of this box along with any secrets we want we can ship this box out to the world so they can run it and they can use that box and they can execute programs and this is kind of the

dream of all all Computing on encrypted data people it's not something we've achieved but this is the goal if we want to build this thing we have kind of three options today one of them is we can build some kind of network where a bunch of nodes are doing MPC maybe we trust not everybody in this network but we trust some subset or large Quorum of them and so we can Outsource to them and there have been these works you know we wrote this thing called fluid MPC and there's this thing called yoso where people are trying to do this so it may happen um there are tees so there are networks like Oasis and secret where people are trusting the you know Hardware like Intel sgx built into their machine and claiming that that works and it may or

may not work and then there are these stronger cryptographic Technologies we're slowly iterating towards like one-time programs and obfuscation which hopefully 10 years from now when you're all like those grad students among you my age you'll be like I remember when you used to say obfuscation was not practical and like we were working around it but now it's like totally practical so I hope that happens we'll see I like to believe it'll happen Okay so let's let's kind of zoom out and talk about an abstract fractions I want to talk about some problems for now let's skip through and imagine we've got this object this perfect tee and this te might be a cryptographic it might be a piece of software that somehow works in the way I want it to it might include Hardware it doesn't matter for the moment it's just a box

the perfect tee has a handful of properties okay it's got an input output API it um you know has a program and some secrets in it correctly execute to this program nobody can tamper with the program execution um we can verify like we can know that what's coming out of it is valid it never leaks those internal Secrets except you know if the functionality inside the program leaks them maybe through some output and then there's this question mark we like it we'd really like it like we want to be able to put some data into it and then like later put some more data and know that what we're getting out is the the output of repeated calls so that would be very very useful the problem is and I want to just be clear that when I say like t-e-e here I may be including certain kinds of

hardware there are things that Tes in general can't always do very well even if we have them and one of them is they can't communicate with the world so Tes are kind of a prisoner they're a prisoner inside of another computer and that computer is the host machine and it doesn't matter if we're talking about software obfuscation or if we're talking about Hardware these can these little computers don't have direct network access and they don't even have access to peripherals of the computer they interact with the world through this possibly untrusted machine which we generally assume is kind of compromised and not very safe the second thing they can't always do is keep State reliably and I'm putting a kind of a asterisk on that right so the you know if you have a secure Enclave

inside of your phone or your computer it may have some like nvram that's trustworthy that's secure so it can keep State itself but let's say that you have two copies of that te so one on one phone one on another how do you make sure that they have the same state well maybe they can communicate what if you have a blockchain based system based on TES where every computer is replicating State across a contract now maybe they have to talk to each other in some way so things get harder when you just don't you can't necessarily rely on state keeping it can be hard and in software if we figured out how to do this in software we're totally dead because software can never keep State because you can always rewind everything and so just to show you um I'm gonna just sort of skip past the

communication I think that you know we all believe the part I hope about communication being hard if you don't trust your host machine um but let's just say that you know let let's get past that part that's not really what I want to focus on so we want to be able to communicate uh yeah there we go the state keeping part I think is a little bit more interesting so I'm going to spend a little more time on that state is challenging because increasingly the storage of data it can be located inside of a te if it's a hardware tee but a lot of your data needs to be put out on some untrusted host machine and that means you need to make sure that the host machine can't tamper with the data so you can encrypt that data under a key that you the tee

know and that the host machine doesn't and you can authenticate the data but no matter what you do you still have the possibility that that host machine is going to give you a rollback they're going to take some old data and the only way you can avoid rollback attacks is if you already have the ability to keep State internally which is to say maybe you can keep a hash or a version or whatever it is of the current data so without the ability to keep State you're always vulnerable to rollback attacks and these rollback attacks can be really really bad for example let me give the simplest possible example one of the most common te functionalities today that you've used probably at least once today is you log into your phone and that's done using a piece of Hardware

that piece of Hardware will accept up to 10 attempts at entering your PIN number and you know there are delays but that's all software that's window dressing over the real protection which is that when you hit attempt number 10 that's incorrect your phone will wipe its state it will keep a counter when that counter Hits 10 it will wipe the key or lock in some way and that fundamentally requires State and that state has to be kept inside of The Enclave if it's not kept inside The Enclave if it's kept out in the host which is untrustworthy the host can replay you know you get to nine and it just keeps replaying state number nine over and over again and you get an infinite number of attacks and apple used this back in like 2015 to break into that iPhone that the San Bernardino

attackers used and so this is actually how a lot of these attacks work is they find ways to replay States so they can bypass these limitations okay good but like generally speaking we also know cryptographic protocols behave badly in the face of rollbacks so we want to avoid them all right so how do we get around this in Practical hardware systems in Hardware Tes uh Intel sgx used to give you internal does anyone remember these monotonic Hardware counters that were in Intel the first version so Intel used to give you a limited number of monotonic Hardware counters which was cool the problem is once an enclave grabbed one it had it forever until it released it and there were a finite number of them and the

problem other problem is they're made out of flash memory so if you use them too much they would literally burn out so you had this problem if you're using a shared computer like an Amazon host or something like that it could basically destroy the machine just by grabbing all the hardware counters or overriding them a lot of times until the NV Ram stopped and so the result was that Intel looked at this and said crap we can't provide counters in server Hardware anymore and so they just removed the entire mechanism it's gone and the newer versions of sgx took all that stuff out so that's been gone for years and now you have to do your trusted State keeping in some other way um let's see what else so this is one possible way to avoid State keeping problems people have talked about

building consensus networks where you have a lot of different systems and assume some of them are honest you could do that there's this paper called wrote from a few years back you can do all these different things and obviously the problems get harder when you have like consensus networks with multiple enclaves in them that have to stay synchronized like smart contract networks now you have this problem that not only do you have this rollback attack potential but the state can be rolled back all over the place and it gets really messy so these problems are not super fun to deal with okay I just want to briefly mention that we've talked about I've been talking a lot about Intel sgx and Hardware but I'm really really trying to put my arms around this whole idea including software um the ideal te is pure software obfuscation we know there are some

impossibility results but we all ignore them and we move on and the the basic idea of these is that we do know that some functionalities can be obfuscated we can do this actually using real assumptions now like there are actual real assumptions in some of the papers are not efficient but like you can actually do this though you buy linear maps and weird lattice stuff so it's not crazy so you can do these things and if you build these obfuscation things in some way you can do a whole bunch of stuff I'll get back to the stuff okay what I want to talk about very briefly is how public ledgers can kind of help with using Tes and whether Tes is Hardware or or software obfuscation okay ledgers are very valuable it's not really surprising but ledgers are these

kind of public existing networks that solve two of the really basic problems that we have with Tes one is that we have to do state keeping so we can you know use these somehow to keep our state for us and the other is they you know these networks are censorship resistant so we can use them as a channel to communicate with people whoever people are and so the basic idea of these things is if you start with a very simple basic ingredient which is proofs of publication whatever that means a proof that I published something on a blockchain let's imagine we have a blockchain for which I can publish a transaction and get back something that I can use to convince any third party that this particular transaction was published on the blockchain now what

does that actually mean like in in practice if you're talking about Bitcoin or a proof of work blockchain how do you build that well one way to do it is you basically put the transaction there and you get a fragment of the blockchain seated let's say at some place that we we all trust let's start with some like basic block number we start from that hash and then I get a fragment to the blockchain doesn't have to be a very big fragment it can just be you know a few hundred blocks I take that fragment and I can take it to anybody and since Bitcoin Etc is a proof of work blockchain if the number if the hash rate in that blockchain is high enough I should be able to make an economic argument to someone that this is probably good it's not a cryptographic

argument I can't prove to you that this is actually a publication but if it would have cost me 37 million dollars to make this fragment of blockchain by myself you could probably trust that this is a piece of the Bitcoin blockchain so it's verifiable in proof of stake ledgers it's a little more complicated it's actually much less complicated but like when you think about the actual security it's more complicated so proof of stake ledgers of course we have signatures so we just check a signature it's great except the problem is the signatures are from validator committees who change all the time and once they're done with their job they could leave and we don't exactly know what happens to their signing keys after that so you could be given a false blockchain from a series of changing committees it's a little riskier but maybe we can make some

strong assumptions that like it's okay so let's assume that we have proof of stake ledgers and we can do this thing and then there are vdfs and Joe can tell me whether that helps here or not but not right now okay he shook his head hand a little bit all right so obviously we can do things with this once we have a proof of publication blockchain of some kind it's really simple to build functionalities even if we have a non-stateful functionality we can turn that functionality into a very simple stateful functionality using this really simple conceptually protocol that's a little gnarly to actually build all you have to do really is you post so the idea is we have this thing where we we post a string and we get a let's say a copy of the full Ledger just to make life simple conceptually simple that's our proof of

publication given the full Ledger we know and the string on that ledger we know that has been published we can run a protocol that's super simple so what I do sorry is the user doesn't communicate directly with the secure Computing device they don't talk to the tee instead they have some input that they want to provide to the functionality so what they do is they post that input to the publicly verifiable blockchain and they post it along with maybe the current state of a long-running computation they put that there it could just be a commitment they don't have to publish that to everybody and they get back from The Ledger The Ledger contents and whatever this proof is that proves that this thing was published so they have these two ingredients next they take their input as well as this Ledger stuff and the proof and they

basically send it into the secure Computing device the secure Computing device verifies The Ledger proof this was actually published to The Ledger and it outputs its initial output at least the first iteration of the run and it gives back an updated State and so you've got now this kind of the state thing and then you have to do some additional things we have to be a little bit careful here so there is always what what we're doing here is using The Ledger basically to bind a specific input and a specific previous state so that we can't place that state on The Ledger twice the we're assuming that the device can look for repeated uh invocations of itself so what we're doing basically is we're making sure that we've only called this

thing on this particular State once the secure Computing device will verify that and it will produce an output we have to be very careful that that output itself is not somehow doesn't contain Randomness that means we could get two different outputs on the same state and input so we have to do a little more work to make sure that output is deterministic so we'll assume there's some kind of key inside the secure Computing device and it will generate its random coins using the inputs and with the prf or something or prg and a prf and so we'll produce all the random coins for this but now we have a deterministic output and so we can basically make sure that like once you run this you can basically only run it on the next state and the next input and so this is a really kind of weak

explanation of it this is the full algorithm for what you actually do essentially this you have to basically run through this entire algorithm where we have the state coming from a blockchain the publication proof and you run through all these things and you verify you recompute the randomness and then finally somewhere down here you actually run a program so this is the extra work you have to do but the nice thing about this is we can basically build fully stateful programs that have deterministic pseudo randomness us and can't be rewound as long as we have any blockchain that has a proof of publication Ledger so this is kind of a nice result so it's blockchain's doing something for us rather than these tools doing something for blockchains we can also use this approach to publish things on the ledger so if the functionality

let's say I have a functionality where if I enter a password wrong too many times it wants to publish something to The Ledger to tell the whole world I'm trying to break in it can do that it can basically give me an output and say either you put this on The Ledger and come back to me with the proof you did so or you'll never be able to run me again so this gives you a sort of a limited way to push data out from this tee out onto the blockchain and to collect information back yes just consider having multiple blockchains like what if I you know I have state zero on like the Bitcoin blockchain but then and you know the output is State one but then I have like state zero on like ethereum and yes so the Assumption here is that this is tied

currently to a single blockchain so it knows which blockchain is expecting a ledger proof from you could probably come up with some way to extend it to multiple blockchains and then you'd have to be careful that everything was in sync you know if I get approved from blockchain one then I can go out and like do bad things on blockchain too so you'd have to be very careful about that but something like that you can make all of these proofs very succinct to using nizzix and using using snarks and so on as well so you could have 50 blockchain proofs and compress them into something very small but yes you have to be careful so you can use this for trusted IO and so on so this gives you a nice way to kind of and here we're talking about a practical system this gives you a nice way to use

trusted execution environments like real ones inside of computers to actually do things on blockchains where you have state and you don't have this rewinding capability and actually a bunch of people have written about this both kind of in the Practical setting in the theoretical setting if you move out to the theoretical setting which I think is kind of interesting you get this result which is not the only one but it's actually kind of one of my favorite weird Theory results and basically what it shows is the following it says that if you have witness encryption it's a strong assumption and you have blockchains and there's a lot of details in blockchains then you get one-time programs and one-time programs are the best thing in the world one-time programs are the strongest thing on that

list they're obfuscated programs you can only run once and you can make them so you can run end times and it turns out that we have all these known results that one-time programs are complete for all of cryptography so every other function you might ever want to realize you can realize from one-time programs so blockchains are the key ingredient we didn't really know that we needed and so we can build all sorts of stuff with them so question so like yeah a result like this admits multiple interpretations right so like one interpretation would be like oh we're closer to one-time programs than I thought the other one would be like oh I guess I'm more skeptical about this encryption or like blockchains of whatever the form that they need so how do you like to interpret it I like to interpret it as as you know blockchains

themselves there's a lot of detail in blockchain right we're making this assumption that we can really trust essentially this third party right like third parties if we have a trusted third-party one-time programs are not that hard and blockchains are this idea that we can take this group of people who are like collaborating to do something that is not build one-time programs they have lots of things they want to do other than build one-time programs but we can use them as a general tool because they're already doing all this computation we don't care about like defy and all that stuff let's take all that work they're doing and with no extra effort let's turn it into a cryptographic tool that builds everything else and so I like that it's not that they're doing something wild it's just that they're doing something they're they're treating this thing as a

piece of infrastructure for cryptography rather than like building some custom cryptographic protocol like wrote where like everyone has to deploy it and nobody ever will so I think that's what's interesting about this and so if blockchains become ubiquitous then they have the right properties then maybe we'll see them getting used for all this powerful stuff and this is really powerful because witness encryption is very and just to be clear for those who don't know what in description it's like the ability to encrypt something uh piece of data like that's all it is encryptions game and you can encrypt a piece of data so that if you have the right witness to some like NP relation you can open that up and it's very I mean it's very strong is a cryptographic notion but it's a very simple cryptographic notion so getting all this power like all of

cryptography and NPC out of it is kind of neat yeah could you maybe say what their definition of blockchain is there because oh no no you don't want to look it's not a good idea to look at that intuitively though like is it a depend only Ledger is it it's an append only Ledger that's a proof of stake append only Ledger that uses unique signatures for reasons having to do with the way witness encryption works most of that stuff is really kind of that that's the theory part like we could kind of not focus on too much and then do they do they need like smart contract functionality too yeah come on that one smart contract they didn't use the word smart contract they need a blockchain that lets you post things and get back a proof that you posted it yeah but not necessarily execute yeah no logic just

post and proof and you have to trust that proof a white proof of state that seems orthogonal to everything oh yeah it's not so much they care it's more they need a blockchain that uses signatures so if your blockchain is binance signing everything on one computer that would be great in fact they would be very happy as long as binance use their weird unique signature they would be very happy but like a proof of stake blockchain would do the job because it's protocol fundamentally use the signatures yeah sorry not to uh good good not to hover on the you know this maybe this isn't the phone no this is a really good thing to hover on so hover uh do they I mean do they fundamentally need like efficient sort of verification of each block do they need like a kind of compact certificate yeah okay we have

it right but so could I guess the question is like could it work for proof of work or other things if you had and do they need do they need guaranteed finality um they don't okay the the hard answer is uh do they just assume that without really naming it so their theoretical cryptographers so they're trying to build from actual witness encryption which is why they have these strong requirements now if you're building from something that probably doesn't exist like extractable or witness encryption then you could probably make it work with like approval work blockchain and it would be fine but your assumption would also be economic you're not getting a cryptographic guarantee that things secure you just get something weaker but I've seen these things go off the rails when the theoretical crypto

people don't understand like front running or a mempool or they don't understand that it doesn't blockchains don't really give you guaranteed finality right away yeah I think the idea here is you could put a state this differently like if your proof of publication Ledger gives you something you believe to be finality then you get something you believe to be a one-time program and I think there's a lot of belief in there but like it's you know the security level is going to be if you ignore the theoretical details the security level is going to be if the blockchain gives you finality you get a one-time program and if not it gets iffy and they don't need any kind of guarantees of synchronous publishing with no front running no they don't I mean their model is a little simple but they don't yeah

yeah seriously how do the how do these make sure they get the latest date do they keep it right yeah yeah so here's the deal um so in a simplified model you get the whole Ledger which is really simple but it's very big um if I were the obvious attack that I could run this is not a theoretical deck I could just chop off the most recent end block so I get an old copy of The Ledger the nature of the way these protocols work though is all that would let you do like the thing I described before is it would just let you rerun on a previous input that had already been run so you can always run the functionality many times it's just that you can't change the input so like to run it on a different input you would

need to put a second input onto The Ledger later and so re-running the functionality easy but getting it to run on two different inputs that's the hard part so truncation doesn't help you I see but say if your fat old state to the de and then based on that Old State maybe I don't know it reuses the non-cities ah so you have to be super careful that there's no Randomness in the functionality that like everything comes from that Old State and the input and the input can never be run twice or the Old State and now you're safe yeah it's very Affinity with that yeah yeah a little bit of Randomness blows all these things up so but fortunately like software obfuscation doesn't have Randomness but like a hardware a piece of Hardware would so okay all right I'm going to switch I'm

going to talk about something different uh so I'm you know uh the the through theme Here is that one-time programs are very interesting and it would be very exciting to me if we had something like this um there are different ways to build them so we know we can get to them through blockchains and witness encryption or obfuscation we know we can get to them through like Intel sgx the question is could we get to them through some other thing that is maybe stronger than uh you know these cryptographic assumptions like but more realistic and realizable and that we can actually deploy in practice and so for a bunch of years I've been looking around for that thing that we could like hijack so that we could get one-time programs arbitrary one-time programs on real hardware and there's this old result that is so

simple it's kind of like I don't want to say it's stupid it's so simple it's elegant but like super simple which is by uh goldwasser kalai and rothblum from 2008 and their idea is really simple so you want to build one-time programs you don't have Intel sgx or some other big process or you trust to run your arbitrary software so maybe you can use some other piece of Hardware that's much simpler and this result if you don't know it is great um all what they say is hey what if we use tokens and a token for them means a tiny little Computing device that has a very simple functionality on it so the idea is I want to make a one-time function a one-time program I am going to do some stuff in software I'm going to send you a piece of software but I'm also going

to send you this little token you plug it into your laptop and now that's going to help you run the one-time program once that's their idea and you know it's a really really simple idea like I'm sure if you haven't seen this before you could work out most of the high level intuition really quickly if you think about Yao's two-party gobbling protocol the way it works is you'll build the circuit you garble it and then ultimately what you do is if you have a second party they perform oblivious transfer with you to get a bunch of labels that let them execute the circuit and oblivious transfer is a one out of two functionality for each wire they get one label and then they can run the circuit um so this is the basic idea so that what they want to do now is the observation

is that this kind of Yao's gobbling particle is almost like a one-time program except for the interaction so maybe we can replace the OT with this piece of Hardware which is non-interactive which I can just send you that was their observation and what's the particular functionality they need to build well it looks like this it's really simple it's um you initialize it and you put two keys into it K was your own K1 when you evaluate the thing you have a read phase so I send it to you and you have a bit and you want to either get key 0 or key one based on your bit so you call the thing and you say give me that key give me bit B and it will hand you one of those keys and then of course what it's actually going to do is destroy the other key

permanently so you can never get that back so far so good questions good once you have that functionality it's really obvious to see how to build a one-time program you just garble a circuit you do all the stuff you have two labels for each input wire you feed those two labels into a token for each wire so you end up with actually a bunch of tokens which you could put on a single device and then you send those the hardware to the receiver along with the garbled circuit they pick their input they go to the tokens they ask for the right key for each wire or label for each wire they run and execute the garbled circuit and that's it and there's like some complexity in actually getting like security under a simulation definition but it's a very simple idea so the question you might ask is if it's

this simple to build one-time programs why don't we have one-time programs like why aren't we for simple functionalities like there's a lot of stuff like if I look inside my iPhone right there's trusted piece of Hardware it's called the secure Enclave processor and it would be really nice for me to be able to write programs that I can put on my phone that like will run once and are obfuscated that like nobody can hack that are on here and I can do anything I want and with Intel sgx in theory you can kind of do that but there's no Intel sgx on an iPhone but there is a secure Enclave processor do you know how you get arbitrary software running on the secure Enclave processor yeah you don't you never do only Apple can do that by signing it they've made an effort to make sure that nothing ever

runs on that processor so you can never run your own software on an Apple phone or most Android phones which also lock down they have this thing called trust Zone which is a virtualization system but they lock it down so nobody has built one-time programs anywhere it would be really useful if we had them the hardware we do have doesn't let us run arbitrary functionalities we can probably if we were on an Intel sgx machine we could do stuff we can't do it in most places and on top of that everybody who deploys these things are going out of their way to make you get approval from the manufacturer to run things um maybe if we had other functionalities you know maybe the problem is that um we don't have one-time memories maybe if we just shipped one-time memory functionality all over the place we

could build one-time programs everywhere but the problem is nobody makes one-time memories because why would you make a one-time memory like a weird thing to manufacture why would Apple say I'm going to make a bunch of one-time memories they're not going to do that but imagine a world or one-time memories existed where lots of one-time memories were out there and imagine that world was a world we live in where not only their one-time memories available to us right now in this room but on top of that there are Cloud providers with millions of one-time memories just sitting inside of them and those Cloud providers have built them in Hardware security modules so they can't like access the secrets I put into them I can just call up that cloud provider and say give me a thousand one-time memories and put my secrets into it

imagine that was the world we lived in that would be a world where I could basically make a one-time program and email it to you along with a URL for where those particular one-time memories were you could go to the cloud provider and get the keys and run that program but nobody else would ever be able to run it twice be really nice we do live in that world it turns out that we've lived in that world for like about a year and a half and we didn't know it so Apple actually deployed something new in 2020 so more than a year and a half uh it's called a counter lock box it's uh this is bearing somewhere deep inside of the Apple uh documentation it's not currently unfortunately to user space exposed but it exists and it will be someday I think the basic idea is they have this thing

inside of their Hardware it's a functionality they expose called a counter lock box each counter lock box stores a 128 bit salt a 128-bit passcode verifier don't worry about that's a hash of a password and an 8-bit counter as well as an 8-bit maximum attempt value and there are potentially hundreds or thousands of these that you can instantiate in an iPhone so all they are is little password things you can put stuff in so this exists and it doesn't just exist there it exists in iCloud right it turns out that iCloud has Hardware security modules full of these things that basically store keys under a password give you 10 attempts and we'll erase that key if you make all 10 attempts and it turns out it's not just in iCloud keychain it's everywhere else too it's in and by the

way Apple has destroyed their access to these hsms it's inside of Android and this thing called a hardware-backed keystore which is run by trust Zone not entirely as secure as we'd like it to be but it's pretty good Google deployed it WhatsApp has it in fact there are like hundreds of different services not hundreds let me rephrase there are seven different services that offer this and they offer these these capabilities maybe we could hijack those and use them to build obfuscated type functionalities let's talk about what this functionality looks like okay so a one-time memory is is a different thing this is a counter lock box the basic idea is really simple you go to this block box you say I want to set you up you give it a password as well as a maximum attempt counter a without loss of generality just assume it's 10 for

now but it could be anything you want and then the way we phrase this is it generates an encryption key for you let's assume that key is long enough and it hands it back to you that's the setup phase later on when you want to access it you say I think the password is X and you put that into it it checks to see if the password matches whatever it's stored it might be a hash doesn't matter and if the password is correct it hands you back the key that it's stored otherwise it hands you back bot and it increments a counter and then presumably when that counter gets large enough when the counter reaches a it deletes the key in its memory so this is the very simple functionality how do we get one-time programs from something like this okay well the idea here is we need to do

some stuff okay actually I'm not going to get into the maximum temp counter values doesn't matter so how do we do this I kind of showed you a model of why we might want to do this let me just show you very quickly and then I'll come to how we do it all right imagine I had a bunch of lock boxes on my phone I could create a one-time program I could store them on my phone anybody who comes along to my phone or who I send my phone to will be able to run that program exactly once because all the lock boxes are inside my phone just want to show another model I could put that program on the cloud and I could evaluate it somewhere else and I could also have some kind of mechanism where I can actually send the lock boxes

from one piece of trusted Hardware to another so these are the models we're in but sorry going forward how do we build these things all right let me give you a bad intuition for how you could build one-time program stuff using these lock boxes let's assume that our goal ultimately is to build uh one-time programs but we're going to start by figuring out can we build one-time memories okay so we want to build a one-time memory from a counter lock box our naive intuition is we are going to send the receiver to counter lock boxes which have let's say k0 and 1 and K1 and the other and they're encrypted under passwords P0 and P1 I'm not even sure what I wrote the slide

to do so I'm like actually going through it as we see let's see what stupid thing I did okay so what happens next I actually have no idea I send the receiver one of the two passwords like that's not a non-interactive functionality how does the receiver evaluate these lock boxes so it gets only one of the two keys but never the other it's actually not totally obvious to me like what the strategy is so this this whatever thing I was doing here does not work try a different idea what I'm actually going to do is I'm going to make two lock boxes and they're both going to have this maximum attempt counter set to one you get one guess at each lock box they have two different keys in them one's k0 and one's K1 put two k zeros in one K1 is in the

other they each you get one shot at opening them and each one has a password which you get one attempt to guess what passwords do I sign to these things everyone's like I have no idea what's going on here why are you talking about one-time memories okay yeah zero one that's it so I set up these things and I set them up so that they um basically have passwords that are equivalent to the bit that you'd guess okay zero and one now the receiver gets these two lock boxes all right so they have this thing uh let me there's actually one step I should probably hit the down button I'm not going to tell you which lock box is which I'm going to shuffle them you're gonna get these two black boxes and they both one of them is

set up with password zero but you don't know what it is the other one's set up with password one and they have the appropriate keys in them so what's your guessing strategy well look if you really are an honest person and you want to get k0 it's a very simple strategy you query both of the lock boxes on password zero one of them is going to barf and say error and one of them is going to open up and hand you k0 but all you wanted was one key you didn't need both keys so this is a great thing ditto one you could query both on one and you get K1 and a bot but you don't care about the bot so this is great and yet the problem here is and I see you smiling so you see the problem what is the problem with this approach

we've talked about the honest receiver strategy but obviously the malicious receiver has a different strategy and what is that try to get lucky guess zero one one and obviously if they get lucky on that one they know the other one's one and now they get both of those keys and didn't say this before but it should be known that if you get both wire Keys labels on a garbled circuit the thing unravels like a sweater in like you know a homemade sweater it's very bad it just completely collapses and you lose all security in some circumstances why don't you just try zero for one of them and then you're guaran like you're guaranteed to get at least one possibly two with the strategy yes you are but are you guaranteed to get two no you're

guaranteed to get at least one yes and you have a 50 50 chance of getting this I agree with you this is the right strategy I mean you definitely should do that so what's going to happen in that strategy well good so if I query on zero I pick one at random say maybe that's the zero one there's a 50 probability I'll be lucky and that will give me k0 and there's a 50 probability I will be unlucky and I'll get bought and if I get bot that key k0 is gone forever which as you point out is not a disaster I can still get K1 with probability one that's fine but I lost k0 so I've gone from the you know 50 chance I like completely destroy the security of this entire construction which is awesome for me as an adversary 50 probability I'm forced

to be essentially honest so that's it once you have a 50 probability that someone is honest obviously we all know that the next thing you do is you just make them do it over and over again so the cost of that is you're going to have to give them lots of lock boxes so instead of just giving you let me just forward a little bit Yeah so this is basically saying what I just said which is we can query We Get Lucky with probability uh and get both keys with probability one half at most the obvious amplification strategy here is well we've now built this thing before I let me rephrase the thing we've built is this leaky one-time memory that kind of works but sometimes doesn't when you have an adversary who's able to get lucky so if you've got a leaky one-time memory

we can turn this into a better one-time memory basically just by amplifying and what we do is we you know basically just give you a lot of these leaky otms which means unfortunately like I have to give you something like to get 2 to the negative 40 I have to give you like 80 lock boxes or something like that like I have to give you a bunch of lock boxes and I have to make it so that the wire labels are a combination of the outputs from many different lock boxes so the actual construction you get oh yeah I'm sorry I want to say a thing which nobody cares about but I need to say it because it's really important to me does anyone here know about like all the results by krepo from like 1980 n about how you can like take a random like one

half OT and turn it into like anything you want in an OT World okay it's well known that if you have an OT that's crappy like one half the time it does the right thing you can use these interactive protocols to make it to like any OT you want OT you know four one ot21 like you can do all these things so the obvious intuition is do that stuff that was solved in the 1980s it doesn't work in this case because those Protocols are all fundamentally interactive we spend a bunch of time looking at that so that's not going to work the thing you do is the obvious thing which I just described which is what you do is you secret chair your two keys and so you break them into s shares you store one share in each of these leaky otm abstractions and then you hand them all to the

adversary the adversary goes in if they're adversarial they will you know get lucky sometimes they will get unlucky sometimes and the probability they get unlucky on at least one is as high as you want it to be and now they're not going to be able to get your secret and you're fine so far so good okay this is the obvious thing great this is good so what I want to kind of convey to you is that this is a lot of lock boxes all right we have to give you like 80 lock boxes or something to get one wire label to you which sort of sucks it's not great and if your program has let's say n input bits you're gonna have to like do this for every input wire and it adds up really fast so it's not super great so can we do better and I want to stress

that this paper was at TCC so if this gets a little weird it's going to get a little weird in a second what we want to do so we're currently spending let's say Lambda is our security parameter which was like I was saying 40 or 80. what we want to do is we want to not spend we want to get rid of like that Lambda term we want to get rid of a lot of stuff the intuition here and I'm just going to move through this very quickly is let's imagine we have a one-time program with a lot of input wires a lot of input bits so instead of basically getting some Lambda security parameter times n number of lock boxes which is where we're heading o of that maybe we can do something really clever where if we have a lot of input wires we can kind of like

shove that Lambda security parameter down into this thing so we don't have to pay for that multiplicative parameter and when we do that um you know what we really want to do is we want to get a constant number of lock boxes per input bit but that sucks so we want to get a constant number of lock boxes per program and I want to stress what I mean by that so I want to run a program that takes in a gigabyte of blockchain data and I want to do that with 80 lock boxes and it doesn't matter if it's 10 gigabytes I still want it to be 80 lock boxes that's the ultimate goal I want here so this is something that you know going from what I showed you before to that is the hard part and it's not totally clear that that's you know the

easiest thing to do we don't get to 80 but something like that okay there are two techniques we need to do that I'm going to run through them very quickly because I don't want to bore you all with too much of this stuff but the really cool idea here is there are a couple of techniques that we can use so the big problem I said before that if you ever get two input wires on the same garbled circuit on the same wire two input labels on the same wire of a garbled circuit the entire garbled circuit collapses around you is that statement true what actually happens like you're all PhD students you've thought about garbling recently well those of you who are cryptography students have thought about garbling recently what actually happens when you get two different input labels on the same input wire of a garbled circuit like everyone

told you not to do it right but did you ever do it just to see what would happen did you ever think about what would happen if you did that like does the circuit collapse it's not necessarily the case so it turns out that the way garbled circuits are constructed use these two labels to encrypt a gate and then that gate is basically a table of encrypted stuff but actually and I'm kind of hand waving here if you imagine a garbled circuit where let's say one wire doesn't matter getting two labels on that wire isn't going to hurt you is it I mean it's not really going to affect the output so it's eventually at some point getting all those labels you can unwrap some gates but you're going to hit some dead point in the circuit where it's not going to hurt you that much

more badly so basically if we can build some kind of circuit where the input wires getting two labels on some of the input wires does not hurt you maybe we can survive a limited number let's say it's a logarithmic number or some small fraction that the adversary is going to get two labels on those wires maybe we can somehow immunize our garbled circuit against this make it robust against some of these losses and that's basically the idea so there's this technique called robust gobbling and what robust gobbling does is it survives you can build a garbled circuit you can immunize it against getting two labels on a bunch of the input wires it could be a basically if you can bound the number of wires for what you're going to get two labels to some constant

fraction you can use this technique and I'm not going to spend a ton of time covering it but the rough idea is we need to do for very specific functions what we need to do is we take our arbitrary garbled circuit and we tack some extra functionality to the top of it this extra functionality is designed so that even if the bad guy is able to evaluate two different inputs on certain input wires like zero and one bits it won't matter once you get past that extra functionality and I see Brett nodding so what is that extra functionality I'm not sure I'm explaining this well I want to build a functionality so if you get two different you can only

evaluate this functionality you have some input but it some small fraction you can evaluate that functionality on two different zero and one at certain positions and you want to make sure that even when the adversary is allowed to flip a small number of bits on some fixed input it's not going to actually change what comes out of the bottom of the circuit so you've got this General circuit that does some general functionality and you want to bolt something to the top of it that can survive these different options what is that thing I'm afraid it's on this board no it is not on the board big in front of some signature verification oh that'd be good I don't know how to do that that would be good but we want to make sure that we can

like e-write so we could bar if we could just say no we can't do that we don't have a signer here so I'm not sure because remember the adversary provides the input so we can't you're probably right if we could sign it it wouldn't be a problem but then the signature verification functionality might be insecure so I'm not sure basically some kind of code so yeah error correction coding so we apply error correction coding to the input we have this functionality that's basically a decoder and what it means is if the adversary can flip some bits that those bits get wiped out in that decoding process and what gets to the general functionality is going to be the same either way and so you can build a system this is not really our contribution this is by a bunch of people ending in trummer um and they

figure out how to do this and it's really clever so I'm not going to go through the details of this because it's long and it's incredibly boring and it required us to like Implement a bunch of painful stuff using like certain codes and it was one of these papers where they're like use a code and it will work but they didn't say which code and then when you actually implement it with a code you get totally different results and it was painful so I'm going to skip past this but this is the general intuition attach a decoder to the top of your circuit and then you can survive a little bit of leakiness okay I want to get to the last part which I think is sort of interesting so I wanted to show you where we're at now leaky one-time memory currently requires two lock boxes per input wire plus we

were able to get some small extra constant fraction from this we were able to use leaky one-time memories just one leaky one-time memory per input wire plus this extra encoding stuff that we had to do so we could survive some bad results on the inputs and the original function had n input wires and so now because we've added this little bit of extra resilience thanks to the code we now have n plus you know Gamma or something total leaky one-time memories you have to multiply that by two to get the total number of lock boxes so we still have this dependency on N which is the number of input bits to the program how do we get rid of that

the answer is actually really simple and it's this beautiful tool and the last thing I'm going to talk about here this beautiful tool that is called um laconic OT which all of these smart cryptographers have been inventing and designing for no reason at all because like nobody seems to have an application for it but it's actually like the most amazing thing in the world the basic idea of this is you can take let's say that I have a huge database like I want to do OT for like a million different things a million times OT and I have a whole bunch of bits like I want to get bit 0 on this one and bit one on this one I get this huge database of bits I want to ask for an OT protocol but like normally I'd have to send you like a whole bunch of stuff and you'd

have to send me a whole bunch of stuff back with laconic OT I can take that whole database and crush it down something that's basically a hash and then I send you the hash and then you send me back something that is you know o of n where n is the number of secrets that you're actually wanting to send me but the point is my move in the protocol is really tiny it's just a hash my entire database in billion bits down into a single hash and then you can do the rest of the OT with me and so the way this works is we have this function that basically takes in the database spits out a digest and like this tiny little digest is there and then the encrypter the person who's the other side of the OT can basically take in that digest and run through all of the

values they want to send you and they can do all this stuff how does that help us in this one-time memory one-time program setting well it means that basically we can write a single one-time program that takes in a let's say 256-bit hash input and that basically internally inside the one-time program it will basically then like decrypt a whole bunch of stuff so we can basically get all of our instead of if our program input is like a gigabyte we can hash that gigabyte of bits down into a small hash and now we can just do one essentially one-time programs evaluate that and then feed it to the Circuit which means we get down from something like a gigabyte of bits down to like 256

bits of actual input wires into the circuit does any of that making sense does that sound reasonable to you Justin made a face but I don't know if it's because he's having like I was sleeping because the baby or not yes so if you use this uh do you need to use this in a non black coffee or Black Box way inside the program yeah you know you you cruel good question it's actually a really good question um no you can use it it's not you don't have to use in a black box way no uh you don't there's some gnarly stuff with adaptivity that comes up which you can solve using random oracles and things like that but you can get around most of those problems seriously are you using it in a non-black box oh do you mean like are we using it like the code of

the electronic OT inside the yeah yeah yeah yeah yeah oh so if you mean like do are we just using like the algorithm is written yes we are it's very simple we're just putting that in and then we're decrypting a series of bits I guess that's uh I I think here using something like a ddh based uh yes there's one that's there's this crazy one that's built on ddh and it seems really good except it involves garbled circuits and that's not great because now you have garbled circuits you can actually pull the garbled circuits out and put them on the side but it's really inefficient because each garbled circuit in that scheme has to do a scalar multiplication and scalar multiplication is like the easiest thing we do in cryptography but it turns out that it's like hundreds of megabytes in a garbled

circuit for reasons I don't totally like and that's the problem with it so it is totally doable you can make it work you don't have to garble double garble anything you can do it outside but it's not good and there are these newer practical pairing based which I haven't really looked at for how practical are they they're newer constructions that are better similar to registration based encryption these things are all related so like some of them are better and so it's possible this might be like sort of efficient we're not sure we did not go and actually implement the conical t okay good so I'm gonna I'm nearly there I will stop boring you with a gonna goatee but I'm mostly just going to point out that you know our our

resulting protocol is just now reduced we did the calculation we did an implementation of everything but the laconago T and we showed that for a arbitrary input size program we were able to get the thing down to about a thousand and 24 total lock boxes which is not 80. I wanted to be 80. but 1024 is like a good number and that's the reason this paper is at TCC and not using security like someday when it's 80 and we can actually like I can send you a program on the iPhone it will be a different thing but we're not quite there like it's almost efficient and and it also requires these more efficient constructions of a Conoco tea so it's

really close yeah why is 80 so much better than 1024 they both seem like they would add up pretty quick if you were doing this regularly well the way you get lock boxes and I sent my students to do it and they said no for reasons the way you get lock box is on the cloud is you sign up for Google accounts right and Google gives you a lock box for free and so does apple right anytime you sign up with an iCloud account you get a lock box for free and now you need another 1023 of them so you sign up for another thousand twenty three iCloud accounts for free and if you can do this now you have 1024 lock boxes but also Apple has booted you out of their systems and you know if you

actually own an iPhone you're in big trouble because you can never use it again because if they link that back to you like it's abuse and it's bad but I mean use the word use the number 80 in that whole story is still true the reason is because I think we can probably steal 80 lock boxes out of apple but 1024 was like too much like my students wouldn't do it now the serious answer is 1024 is not bad a thousand I mean here's the rough result 1024 the ability to store 1024 encrypted passwords means you can basically build a one-time program over any functionality of arbitrary complexity I think that's pretty cool like that's an actual number it's not an O of it's a real number and it's not a huge number and I think that's kind of neat and maybe it'll go down a lot of

this stuff has to do with like specific choices around codes and some other decisions that I think maybe crankable down so I I I'm a practical person I wanted to see it as something that we could really really really do um I thought 1024 was too high so that's it okay good what's the summary of all this well we're kind of all over the map um my parting thoughts here are these kind of Ideal objects are the thing we're trying to build I don't mind if we build them with Hardware I don't mind how we build them but we have to build them in some way that actually makes sense and I've seen a lot of people building weird things that I don't know that are Totally Secure and they may be much more common in different you know forms like we can certainly build arbitrary functionality

another thing I think is really interesting about this is like these sgx things keep getting broken constantly right like nobody trusts sgx because Daniel genkin keeps breaking it but what if we could I mean I don't know really I'm not like a I'm not a hardware person but like yeah you hear garbled circuits you know like that's terrible why would you do garbled circuits but like these functionalities Apple clearly believes that running arbitrary software on their phones is bad and they've made a big effort to make sure nobody does that because they think it will make their phones less secure but maybe Apple isn't scared of giving you 1024 lock boxes or a few thousand lock boxes and that means that at the cost of a little bit of garbling now you have like really powerful functionalities on your phone so maybe this is good like just as a way

to like use processors in a much much lighter weight way to do things that um you know like we wouldn't necessarily be able to do maybe like given that all we're doing in blockchains is like stuff like making signatures and things like that maybe like having a garbled circuit do that isn't a ridiculous thing to ask and then you know we could reduce it to these simpler functionalities so we'd have much less Hardware exposure I hope um yeah so these things exist and uh you know maybe we can sort of hack around with these tools until we have actual software obfuscation and tools that actually work and that's it thank you any questions so you're saying at the end right one possible way forward is Apple could give you a thousand twenty four lock boxes

for email address and that would then make it so you could kind of deploy this what if they change the lockbox functionality they gave you the OT that you wanted right then you don't have to do the simplification but it actually doesn't is am I right thinking that that wouldn't actually help you as much you'd rather have them give you a thousand if you'd rather have 1024 lock boxes than one OT what I like about lock boxes is like they're useful for other things and like I think if Apple just exposed the world to a lot of them most people would use them for encrypting things because I think that's a great idea and then you could like hack on but if you go the other way right if you have OT you could also use you could generate lock boxes from OT right like OT is complete for

everything so yeah if you had otms low like it'd be a little big and a little ugly yeah you could do that um but obviously that you'd still have to do the stuff with the Conoco T and you'd have to do a lot of things to make it efficient so yeah but I guess just the the question is that by going through these robust garbled circuits you actually don't end up losing anything from the lock box but like the fact that you have a lock box and you want OT means that you're you're generating sort of leakyots from the lock boxes but but the robust garbling kind of saves you there so in the end of parameters you're not going to get something like if Apple today said we gave you OTS instead of lock boxes you'd still have about 1024 now yeah actually would

be smaller a little smaller but not much well 256 maybe yeah because you could go directly to the laconico tea yeah you wouldn't you could skip a lot of the robust but I thought that I don't know how much that loses but I thought it wouldn't lose them you think it's lose like a factor of four or something we lose two a factor of two just by using uh these leaky OT uh otms and then we use lose an additional factor it's like an additive factor and I don't remember what it is but it's very dependent on the code we use which might not be the right code the best code and that's how you get to 1024 but like already that's the difference between 512 and 1024.

yeah and it's very specific to the block size of the code and all sorts of messy stuff because it has to work over bits and things like that yeah so I mean to be clear you're talking about Apple giving you lock boxes that are in the cloud as opposed to on your device is there any verification that they're actually is a lock box in the cloud and Apple's not just simulating the whole thing when you query it so at that point why don't you just have apple like do the why don't you just happen to be a trusted third party sort of obfuscater I mean I love that like absolutely the answer is if apple is willing to be a trusted third-party obfuscater and run hsms for us we should do that like let's just have them do that the the hack idea

here is that they're not doing that they're revealing these functionalities and more and more people are revealing these functionalities so let's use those functionalities let's misappropriate those functionalities for the purpose we really want which is obfuscation it's a little hard right now and the other is that like this functionality happens to be useful for lots of things so they it's much more likely that people are going to deploy that in a Cloud Server than they are to give arbitrary people sgx there's a flip side to this which is if you don't believe we should be hacking um lock boxes to do bad things let's imagine you happen to be on a computer that has lock boxes people don't want you running arbitrary programs in this form what bad things could you do to a computer that exposes a handful of lock boxes if you happen to be on that

machine and one answer is you can build really terrible malware and so the point is even if you turn off Intel sgx even if you don't let people run arbitrary computations if you just accidentally expose 1024 lock box instances they can infect your computer with malware that like the malware itself lives only on your computer never has to talk to command and control and like does terrible things so like the fact that we can get computation from simple functionalities is good is a hack but also bad because bad people can use it as a hack to do stuff and and that's the other reason we should care about this I would argue yeah um does the slander phone expose any like extra functionality the Apple or

Google might not sorry it does the what does the Solana film expose any like extra functionality I don't know if you know so a Solana phone this is like yeah Salon released like a new phone I was really hoping I heard you wrong um okay uh I just I like literally my brain is just that's just like Bonk like I don't know um I don't know the answer is I don't know yeah this maybe this is like getting way out of the game but do you worry about some kind of environmental pushback with all this one-time Hardware if people are really using it on a large scale and the blockchain people get a hold of it and all of a sudden they're

using billions of lock boxes a day and Apple has to uh you know we just make it reusable it doesn't have to destroy itself it just has to destroy the key destroying Keys is easy and so that's okay like all right like destroying I hope destroying Keys is easy right it just has to turn off the power or like cycle to zeroize the thing a little bit so that maybe isn't as bad I mean there is a risk that like if you use a used piece of Hardware someone's hacked it and then it's like reusing someone's Bitcoin wallet maybe not the best idea from a hygiene perspective but they should be reusable sorry good so you mentioned this challenge where you need to make the one-time program deterministic and like use part of the input as the randomness first are there any cases where you need

the one-time program to be like truly randomized where you can't use the input as the randomness and then second is their hope for constructing these truly random one-time programs yeah okay so the first question is if let's assume we have a piece of Hardware just to make life easy we can put a key into it and so that means that we can derive pseudorandom coins from any input and as long as we never allow repeats obviously repeats would mean repeated coins which would be terrible but the whole protocol stops you from repeating inputs so you get pseudo random coins and they're not truly random though I'm trying to find an application where they would be bad I mean if you're prf or your prg is good enough theoretically nobody should know it should be fine so I feel good about that

but there is the possibility that key leaks out and that's the scary part now somebody could possibly get the key and like regenerate those past coins because it's all deterministic maybe I haven't thought about this maybe you could make it Forward secure somehow so you could like guard against that attack a little bit but like those are the things that I would worry about the quality of the coins would be fine but the attacks on the system would mean like really bad outcomes that wouldn't be the case with Randomness like imagine doing TLS with board security right like hey I'm doing diffie-hellman and it's totally secure because I use an ephemeral key but it wasn't an ephemeral key or like every past Bitcoin key I generated is actually I mean I guess Bitcoin keys are deterministic now but like if you wanted them to be random they wouldn't really

be random because anyone who hacked it would get those keys so yes they're bad things as far as how you'd realize it with Randomness it would be bad because it would totally kill the construction I think but maybe you could find a way to allow some limited parts to be random okay for specific functionalities you could say something like I will allow you to use Randomness here because I'm it's okay with me to have multiple outputs at the same if you knew that it was safe to Output multiple different outputs to the same input at the same state you could make it use Randomness it's just that you'd have to think very hard about whether that was safe for every functionality

the you don't see a wage to avoid like allowing the adversary to see multiple outputs because of the randomness yeah I I don't if you can think of a way I'm not right here I can't but yeah I'd be interested okay [Applause]