Programmable vs. Decentralized Secrets Management | Arjun Hassard - Threshold

Awesome. Awesome speakers this afternoon. Uh we have a great lineup on the stage and it's going to keep on rolling. Um just as a quick reminder, uh hashtag for this year's ETHDenver is #ETHDenver Denver 2025. So, if you're on the socials, take photos, post, hash hashtag us.

Um and with that said, without further ado, I'd like to uh bring up onto the stage Arjun Hassard from Taco and he'll be talking to us about programmable and decentralized secrets management. Round of applause, please. Uh good afternoon. Uh my name's Arjun Hassard. As mentioned, I'm project lead at Taco.

Uh Taco is an end-to-end encryption plugin that is end-to-end decentralized. We have been live on mainnet since last year, so it is usable in production right now, uh generating revenue from a diverse set of use cases, including very high-stakes uh data sharing patterns like private key recovery, but also some new advanced areas where you need complex permission controls like in decentralized compute and decentralized AI. We're day one decentralized, so that means that the very first byte of data was encrypted under a decentralized cryptosystem, and today we have about 130 nodes who are collectively providing this access control and secret management service. Our vision, like long-term vision, admittedly, is to see Signal-esque protections embedded into the apps we use all the time so that health care portals, chat bot providers, social platforms, shared utilities like docs and spreadsheets, uh flight booking aggregators, etc. And all these like digital facilities could be built without a shadowy data harvester lurking in the background and extracting and monetizing your data.

Um so, with a programmable end-to-end encryption layer like Taco, the developer or commercial entity would see nothing but ciphertext. Before we get into like what's programmable and what's decentralizable, I think it's important to establish like a wider context here, which is that if we want these non-surveilling, non-exploiting, uh non-rent-seeking versions of the apps we use today, a really, really important segment of the stack is what you might call like selective decryption. Uh basically, how do we ensure that certain data is only seen by certain devices? Your options like as a developer right now are pretty rubbish. You can use basic PKI like local asymmetric encryption, and this is privacy-preserving, uh but it doesn't scale but beyond the prototype.

Like you have to know the recipient in advance, the data producer has to be online, it's basically just for proof of concepts. A worse option is to use a cloud key management service like AWS KMS or Azure KMS, whatever. You're fully trusting like the commercial entity Amazon, Microsoft, etc. And then probably like the worst option, arguably, is to use what we call a DINO, decentralized in name only. So, these are like infrastructure layers that have really nice marketing saying they're decentralized, but actually when you dig in, it's just like a single entity that has power over the decryption material, or maybe slightly better, a permissioned group.

And this means that they can move to unilaterally block uh data sharing. And that leaves you as a developer and your users vulnerable to rogue uh developer teams, uh opaque backroom deals. It's like a single point of failure. And there's also this like somewhat benign but very real possibility that these projects never work out how to decentralize, which means that you're locked into their encryption scheme. And anyone who knows anything will tell you that encryption schemes are very hard to like decentralize later.

And so it's really important to choose one that is decentralized from day one, like Taco. All right. So, if we take as a given that decentralization is like a very worthy objective, um then we can kind of look at how that fits with another objective, which is general-purpose cryptography, or like programmable cryptography. I'll start with like a caveat, which is that to my knowledge, the only uh there's only a few variants of SMPC and FHE and ZKPs that are programmable in this pure native sense. But I think we can like uh we can argue that these schemes can be programmable and and sort of perfect in isolation in a vacuum, but as soon as they are used, they will they you they need to be real-world machinery around it, or automation, or programs, basically layers that introduce trust buttons.

And so for the sake of this discussion, I think it's worth talking about cryptographic primitives with automation. So, with with basically layers that make it usable. Uh and that includes uh technologies like or schemes like threshold decryption, threshold signing. So, with that, we can look at some of the attributes or qualities that you might uh look at when you're evaluating how programmable a given cryptographic scheme is. So, on the programmability side, you can look at how tightly bound the program is to uh the cryptography.

So, in the case of Taco and conditional uh conditions-based decryption, uh this is basically how easy is it for an attacker to strip conditions away from a ciphertext, basically change the conditions for access such that they could unlawfully decrypt data. Then, you also have like the protocol that actually executes the uh the program, the execution layer. And the important thing there is like, what are the mechanisms and disincentives, etc., that force or compel a service provider to follow the protocol or to not diverge from the protocol. And it's really important to emphasize here that this matters regardless of whether the uh the scheme or the service is decentralized.

On the decentralization front, I think this is a little bit more familiar. Uh you can assess decentralizability, which is not a word, but we'll just bear with me on that. Based on things like how specialized and is and expensive is it to run a node? Or like, another way to think about it is, how light can the client be? This is really important for assessing like, how permissionless a network can be.

Then, you have like components of a primitive that literally just can't be decentralized. So, a great example of that is uh trusted setup for like, ZK-Snarks. And then finally, you have like the feasibility of correctness monitoring or like monitoring and attributing faults to nodes in a network. And all of these things impact both the permissionless-ness, the decentralize- decentralize-ability, and the programmability of a given scheme. So, another caveat, this is just an illustrative placement of schemes on a 2 by 2 sort of axes between programmability and decentralize-ability.

It in no way encompasses all the technologies that use these schemes. But we can make some interesting assertions and observe some interesting things here like if we take something like PKI which I just referenced, public key infrastructure, if you like on its own it's pretty neutral, but if you operationalize it into a key management system, then it becomes very centralization dependent to the left of the of the diagram. Conversely, if you modify it and manifest it as proxy re-encryption on the right hand side, then it actually is very decentralizable or very decentralized and we're pretty familiar with that having launched a PRE network in 2020 as NuCypher. However, as you can see, it's not particularly programmable. In particular, it's not easy to add access conditions to the cipher text.

Um with respect to like ZKPs, FHE, I'm definitely not an expert. So, take what I say with a grain of salt, but there are some interesting observations here, too. For example, ZKPs have a commonality with TLS in that there's often or broadly speaking, there's a root of trust. So, like with TLS that would be the certificate authority and with ZKPs it's the issuer of the proof. Now, whether that can be decentralized or it even needs to be decentralized is basically TBD.

Um looking at FHE, for example, um very programmable as uh I mentioned, but again, within like these sub-schemes, you could say, "Okay, TFHE for certain types of operations, like Boolean circuits, is actually um less computationally intensive, more like the circuit is more efficient, and therefore you could argue that it puts it more on the decentralizability decentralizability side uh because it's more uh straightforward to create a permissionless network if you don't have massive computational overheads and bandwidth constraints." Finally, like having a look at the top right quadrant, uh you have SMPC there, you have uh threshold signing scheme like T-ECDSA, and you have threshold decryption like Taco. And I think an important point here is like we've been able to make Taco decentralized partially because of the associated DKG scheme, which is distributed key generation, and I'm going to explain how that works uh in the next slide. Cool. So, let's talk about how Taco works, how it is scalable, how it is decentralized, um and how it's trust minimized from start to finish.

So, when you first uh engage with the Taco layer, the first thing you're going to do is initialize a uh DKG ritual. So, that starts with sampling a group of nodes from our network. So, let's say 50 nodes. Uh you can do this with a replicable random seed to prove that the nodes were not individually handpicked if you want to. Then that uh group of nodes, those 50 nodes, are going to kick off the DKG ritual.

They do this by generating transcripts, aggregating them, cross-verifying them, etc. This is basically like generating a shared secret where if you had one party doing that, then it would be trustful and it would undermine the entire the entire like end-to-end encryption. Uh another important attribute of our DKG protocol is that if any of the nodes uh screws up or like submits a malicious entry, then the whole ritual fails and goes back to the beginning. So, that implies that this is a minimum one honest party uh scheme. You get some public material and some private material.

And the public material is used to create a persistent public key, and the private material is held onto by each node to be used later. It's a fragment of decryption material. Looking at it from the data producer's side, um they're going to choose some conditions for accessing their data. So, let's say we're a decentralized Twitch and we're a streamer, and we want to say you can access my stream if you've it's behind a paywall, so you have to have paid for it. And also, to make it more interesting, you have to prove that you held an NFT from before.

And also, this access only lasts a week. So, you can compose all those conditions together into a condition set, and then embed it with the ciphertext. That's then sent or stored somewhere. Like, these are some of our partners' storage layers and transport layers, and it's pretty agnostic to where the ciphertext or the payload is stored. Looking at it now from the data consumer side, they're going to retrieve that payload, present it to the network along with a proof of their identity.

Um and then if the the nodes once they've authenticated the requester or the data consumer, they will then they will then check if the access conditions are fulfilled. And if they are, they will provision decryption material individually to the data consumer who can then assemble those that encryption material locally in order to create a private key that can then decrypt the payload which is usually in itself a SIM key or like a conduit to the actual sensitive data. I I'll I mentioned before that we have some like revenue generating customers which is pretty cool. So I'll talk through some of them. So uh Marlin is a TEE co-processor for decentralized compute decentralized AI.

And one of the issues that all TEE based um like services face is that if the TEE goes down then you can lose the data and if you lose the encryption keys then you could lose access to let's say the weights of a model uh you know Marlin does a lot of agent stuff or the unfulfilled orders um in an order book. And so you need like a backup that's also decentralized and so Taco is that is that backup layer for the root keys of the TEEs. Uh and this is sort of like a first of its kind layering of these different trust minimizing technologies so you have uh enclaves you have uh remote attestation and you have Taco this like cryptoeconomically uh secured uh network um enforcing access control. Another uh OG customer of ours bequeath solving an issue that affects every single person here. What happens to your holdings if you were to tragically pass away?

So this is basically key recovery but like 40 years from now or maybe longer if you eat your vegetables. So this is this stack combines verifiable delay functions um and and Taco and obviously the Taco part is really really uh critical because not only does it need to be trust minimized when it's handling a sensitive payload like a seed phrase or mnemonic, but also it needs to be available many decades into the future. Um so, the kind of cohort longevity, the group of nodes that's managing access is really important. All right, I have a few minutes to hop over to a demo. So, just give me a sec.

Uh you're welcome to follow along. Go to taco.build and then click playground right here. So, this is like a workspace for creating conditions for access. Um so, you can see here there's like condition types that you can drag in and also like operators if you want to combine them logically.

I'm going to start with a uh I'm going to start by seeking to prove that I received the NFT for attendance at ETHDenver. I'm actually going to say initially that I have two of those NFTs, which is not true. So, let's try that. We'll start with a very pretentious sentence like Actually, before I do that, I've got to clear my cache. Give me a second.

Okay, so that starts from the scratch. Okay, so we're encrypting the message. Um So, as the encryptor, I'm going to I'm going to sign. You can see that actually the JSON output, this is like the condition language. And we also have a uh ciphertext here, which is the outcome of that encryption function.

Now, as I said earlier, we've embedded into the condition that this is checking whether um my wallet address has two of these NFTs and this is the NFT contract. So, this should fail. Again, this is checking like the real NFT contract like on Polygon. Okay, so now I'm now I'm signing as the data request like the decrypter. Okay, perfect.

It failed. So, let's start again. And this time I'm just going to put I'm just going to put one. And hopefully this will work because otherwise I'll be outing myself as not having a ticket to ETH Denver and I'll have to call security. It's taking a bit of time cuz it's actually contacting the network.

Oh, amazing. You can see that the message decrypted which means that it checked my wallet and I do actually have the NFT proving that I should be here. I'm going to I think I've got time to do just one more. This is a new feature we just added which is pretty cool. It's basically a RPC call.

You can put any public API here. This is actually calling a Bitcoin API. And what we're going to do here is take the time right now. And what we're going to check is whether this block is basically did this block happen before now cuz this is this is calling like the block parameter. So, again we'll just do some silly sentence encrypt it confirm that.

And then try and decrypt that and it should decrypt successfully because the block is in the past. Uh I might have got the operator the wrong way around, but anyway, this is a somewhat experimental feature, but the cool thing is is that you can uh use this with, as I said, uh any source of truth, uh any web state, uh in order to condition access to stuff. Okay. Uh I'll wrap up by saying Taco, you can use it today uh as it's decentralized from the very first byte. We've got a big network of nodes, uh lots of um proof points with real use cases, and off-the-shelf compatible with a variety of storage layers, transport layers, databases, etc.

Thank you so much.