[Podcast #5] Vivek on Cursive and making cryptography accessible

On the Hylé podcast, we talk about cool applications that leverage cryptography in general and zero-knowledge technology in particular, with a new guest for every episode.

Vivek is a co-founder at Cursive, a team at the forefront of crypto education and design. If you prefer the written format, you can read the highlights below!

Vivek’s journey and Cursive

My first work in cryptography was actually around 2016. I was lucky enough to be part of a research program at MIT for computer science students. I was randomly slotted into cryptography because one of the professors in the program focused on that area.

And yeah, we started out doing some alternative consensus protocols, such as proof of space, in contrast to proof of work, which was the primary thing at the time and was very cryptographic. It consisted of sizing different graphs and stuff using some really old research to figure out how we could build a consensus protocol around that.

In 2017 and 2018, I was doing work on a topic closer to ZK: using polynomial commitments to build authenticated dictionaries. So, basically, databases where you can make proofs about membership and non-membership and prove that it hasn't been maliciously messed with, and then I was like, «Wow, this stuff is so cool. » I wanted to keep doing this…

I didn't want to be an academic. I figured that out quickly. At the time, it seemed like the cryptography industry was only cryptocurrency. It seemed like a bunch of financial scams and gambling, basically. So I thought, there isn't really a space for me. That's sad, but you know, I'll do other things and take a break for a few years. And then, in 2023, I got reintroduced to cryptography through my friend Aayush, who's also the head of zkEmail now.

He told me about his friend Brian, the founder of 0xPARC, and how they were spinning up a lab to work on zero-knowledge cryptography, which I'd never heard of. I looked into it more, and I realized this was the same cryptography that I was working on in 2018 or 2019, in a very different context.

I started getting grants from 0xPARC to work on various ZK apps. Then we founded Cursive… I would say in Zuzalu 2023. I met one of the co-founders, Rachel, at this event, and we discovered that we had really similar interests in making cryptography more tangible and easier for people to understand, especially those outside of our industry. We collaborated on some initial physical cryptography and NFC experiments there.

So, that wasn't called Cursive then, but those were the first few Cursive-related experiments. Then we met Andrew around August 2023, and as a group, we've been working on projects ever since.

Physical cards with NFC

With our NFC cards at events, there are two main elements.

First, you have the NFC card itself, which is a way for you to build an in-person social graph. It also allows you to collect some ZK-friendly data.

For each person you meet, you receive a unique Baby Jubjub signature from them, and, you know, as you meet more and more people, you collect more of these. Now you have this set of signatures to make proofs about, and the main proof you could make here is like, «Oh, I have X number of taps » or something.

The other side of it was that with this in-person social graph, you can also start to experiment with features that involve multiple people.

In this case, we were experimenting with two-party computation. After you meet somebody, one thing you can do on the app is attest to a variety of hot takes on cryptography. We came up with a list of about 10 things.

When you meet somebody, you can discover whether you think the same about a specific topic. Do you both think it's underrated or overrated? It’s a way to meet somebody and quickly gain a lot of shared context.

The general mission of using this stuff to help people connect more easily with NFC is also very important. The ZK part of it allows you to own your social graph and make it portable. But this was much closer to, « Oh, I learned a bunch of things about you. »

Answering the lack of data

The NFC card approach was a technology-first approach. We like ZK, but one thing we need for it is data that can be used to prove things. By giving people NFC cards, you could digitize the people they're meeting and the places they're going to.

The MPC part of it was less tech-first. Now we have interesting data about two people who have met or things you're attesting to: how can we use this to allow people to be more expressive, more vulnerable, and more honest with each other?

That came from our vision that we should be able to connect more easily, and then cryptography was used as a tool for that. But overall, the ethos has definitely been more technology-first and more R&D-focused in 2024.

We have this technology. We want to find ways to use it and identify deployment bottlenecks. Then, we can solve those problems through research or design.

Trustlessness

Other solutions we've explored include using email to import various things. We've played around with zkTLS and used OAuth, for example, to log in with Spotify and export data. It's not verified data, which is fine in many cases.

The use cases we're considering around connections have two sides. One is that we want to import meaningful, honest data so we can get more interesting data, like matches, connections, or synergies.

The other side of it is that you can lie and say that you're interested in everything, and then you can match with everybody.

It's a balance for whichever situation you're in. If you think people will be more adversarial, then you really need more verifiability, which ZK and signatures are perfect for. But if not, it's usually much easier and has a better UX to import some data and use it.

It's also very related to trust infrastructure. For example, there is a set of essays from Arnaud Schenck. And I agree: trustlessness is not always a desirable quality.

Building infrastructure that enables more trust and safety between people is a lot more valuable to me because trust is super valuable. There are some situations in which we should not need to trust a specific third party, but in situations where you're, yeah, like with friends or playing games, we can lean on each other more.

Fixing the MPC bottleneck

The main bottleneck outside of the sheer lack of attested data is computation.

With a lot of these protocols, there are many messages sent back and forth between the two or more parties. It also generally scales quadratically with the number of parties you add.

FHE is fully homomorphic encryption, which means I can take some data, encrypt it in a structured way, and send it to a server that can run some operations on it. The entire time, it remains encrypted, so the server doesn't learn anything. Then, when they send the final result of that computation back to me, I decrypt it.

It's as if they did that same operation on the plaintext data. The canonical example here is usually related to medical stuff, like encrypting my DNA. I don't want a server to know my entire DNA sequence, and so I do that. They run some operations on it to see if I'm at risk for any specific diseases or if I also have some benefits or other things.

This remains encrypted, and then when they send that back to me at the end, when I decrypt it, I can see all these results. I can learn about the output of this without them learning things about me that I don't want them to.

Multi-party FHE

As I described it here, it's a very single-party application. But you can turn this encryption step into a multi-party FHE.

Let's say you and I want to discover commonalities. We engage in an initial multiparty computation to generate a shared public key. Neither of us knows the corresponding private key, but we both have generated a shared public key.

We each know half the public key and the private key, too. Once we have this, we can both fully homomorphically encrypt our data to this public key. We can do some computation over it, or a server can do some computation for us over our data, and then once the server is done, it can send the result back to us. Then, we engage in a final MPC to decrypt.

The main benefit of doing all these steps is that the users are only responsible for encrypting and decrypting the data, which generally tend to be very light operations. You can also offload the actual computation entirely to the server.

The user doesn't have to do much work, and the number of back-and-forth rounds is generally much lower than in traditional MPC schemes because the server is handling a lot of the work itself in a privacy-preserving way.

In general, FHE is very expensive: you incur lots of costs to do this. But one really nice thing is that you can throw this problem at a server, and so you can make the overall UX really good.

Janmajaya of Gauss Labs was the research mind behind this, and we collaborated closely to get it across the finish line. It was very tricky and weird, and it involved a bunch of new code that a lot of people haven't messed around with, but his support was invaluable in getting it across the line.

Trinity

Trinity is another solution to several problems we identified. We're using it instead of multi-party moving forward.

With multi-party FHE, the number of rounds of interaction is significantly reduced, but there are still about four because you need to interact with the server and wait for the server to finish the computation.

This makes for really weird user experiences, especially with consumer apps: people put away their phones, which means that their phones can no longer receive messages and send messages as easily.

Minimizing the number of rounds simplifies the user and developer experience: you don't need to think about tracking all these rounds and building UXs and screens to explain this to users.

The other drawback of multiparty computation is that proving the authenticity of the data involved in the computations is a fairly expensive process with FHE.

There's some amazing work out of PSE called Greco, which was built by one of their developers, Enrico, and it actually answers this. It creates a way to have verifiable data inputs into an FHE computation, but it is expensive. It's a lot of extra work you incur.

Trinity is a way of solving both of these with a one-round protocol.

If we are engaging in a 2PC, I need to send you one message, and then you can do some computation on your end. Whatever result you get, you can act on it, send it back to me, or take some other action based on that. There isn't any other kind of back-and-forth.

The other nice thing is that it pairs really nicely with existing zero-knowledge schemes, especially KZG-based ones like Plonk, to have really efficient data verifiability without incurring a lot of extra costs.

From some conversations with MPC researchers, it's a fairly unique set of trade-offs, especially around data verifiability, which is not as much of a focus in much of the existing literature. If anyone's reading this and knows of work in this area, please let me know!

On educating people about cryptography

Why educate people about something they don’t need to understand?

If people don't appreciate or at least understand what technology is being used, it's easy to equate making a ZK proof to trusting Google to do the right thing with your data. Both boil down to trusting smart people to do the right thing.

Like, even with ZK proofs, some people are writing the circuits, and other people are auditing them. Some people are deploying them. All of these are places for errors to happen. And ultimately, you are trusting people at the end of the day; people like saying, « Oh, it's all math », which is true to some extent, but it involves people. The math is meaningless, so you trust some smart people to do the right thing.

If there isn't some awareness of this technology and how it's different, then you might as well do the other version because it doesn't meaningfully change the user experience.

At the same time, it's worth also taking into account the fact that the most successful deployments of cryptography have been very under the hood, like TLS, which is the best example. You have that little lock icon on your browser, and you know you're safe underneath the hood.

There is a lot of really great cryptography going on, but consumers don't necessarily know or appreciate this. The goal is to make good interfaces, explanations, and protections for people, even if they don't get the stuff below them.

Cryptographic Connections

The overall concept we did here was a Cryptographic Connections museum with a booth right at the entrance of DevCon. We're going to have some video documentation of Cryptographic Connections coming out soon, so you'll get to experience parts of it.

The goal was to explore cryptography for connection. It’s a big part of our team's thesis. The museum's goal was to try to figure out if we can demonstrate the power of cryptography to connect people both in terms of historical examples and recent initiatives. We asked people if they could make some demos or art pieces about what they're doing. Then, we added more future-facing and abstract representations of this technology as well.

We were lucky enough to be part of this pop-up city called Edge City Lanna, which had many, many artists in-house. So we collaborated with a bunch of them and asked, "How would you explain or explore what cryptography means?”

The overall goal here was to educate people on this technology, get them excited about it, and also put an artistic flair on a field that tends to be very “math and technology” and a little bit pretentious at times. Trying to be more colorful and exploratory.

It was a great success. It was fun to highlight so many of our friends doing amazing work. A lot of people came by, and we were able to really appreciate cryptography differently after looking at some art pieces and some alternative ways of explaining its power.

And yeah, it was super fun. I hope we get to do something like that again. But if not, it's a really good artifact that I would love more people to learn about and see.

How to get into cryptography

From a math background

If you're a math person, which I definitely was entering the space, it's really fun to learn about what's going on underneath. Some of these cryptographic protocols are so beautiful that everything really clicks together. You can build these really powerful systems from a single cryptographic assumption. You can make stuff like zero-knowledge proofs and fully homomorphic encryption.

Vitalik's blog is a fantastic resource for medium-level articles. It's tough to find stuff that isn't so simple that you don't get anything from it but also not so complicated that it's difficult to dive into. Vitalik consistently strikes a balance between the two, which is both really hard to do and really appreciated by me and lots of other people. His sources and resources are good.

Justin Thaler has an excellent textbook on this stuff. 0xPARC has a lot of learning materials, which is where I learned how to code using all this stuff.

I recommend digging into the math.

For developers

If you don't have a math background or it's not something that excites you, you don't need to know it to really be able to do good stuff.

With Rust zkVMs like SP1, it's easier than ever to develop with this technology. And you can have all the cryptography stuff handled in the background. So, I'd recommend giving that a spin. I've had a great time using SP1; I'm good friends with the founders, and they're doing good stuff. And there are a whole lot of other options, too.

For everyone

If you don't have a technical background, there are lots of opportunities to think about where and why this technology should be used from a design, communications, product, and so on point of view.

The biggest gap in the space right now is that more people need to think about it holistically and build tools and products.

Also, feel free to contact me at @viv_boop on Twitter whenever you want more specific guides or resources. I'm happy to help!

The future of signed data

Alex asks: You also have a blog where you’ve written about signed exchanges (SGX) and how they're used. How do you imagine the future of digital signatures, owning your data, and what people do on the internet?

I'm excited for a world in which you sign and own all of your data across different sites and everything you're doing and visiting.

Data portability

The first trend around this is data portability, which allows users to switch between experiences more freely.

Twitter sucks in a bunch of ways right now. It's a lot worse than it was even a few years ago. That's a consensual opinion, but you know, millions of people still use it, and I still use it despite it being a terrible experience in a handful of ways.

We're well past the time when we have the technology to move between platforms quickly. Network effects, data lock-in, and algorithmic lock-in are really strong, and finding ways to make those more flexible will be great.

We haven't quite figured out the right UX for this. Password managers are the closest we have to something like this: you log into your account, and then there’s this big bucket connecting all your different accounts. Some iteration of that makes the most sense to me, at least as an initial version.

And then I also have a theory that if this stuff ever gets used enough or there are enough standards around, like Apple, Google, or Windows, they will build some OS-level version of this. You can already see this with some iCloud stuff. Apple does some really nice integrations. Even Apple Wallet, for example, is some proto-version of this.

There will likely be some OS-level data bucket or backpack or whatever you want to call it that is super easy for Websites to access, and there will be some standardized API for them to do such a thing.

Ideally, everything has zero-knowledge proofs, but it's easy to go in the other direction.

Now, you can put your licenses driver's licenses in Apple and Google wallets. And they have some ability to prove you are above a certain age. This is a trusted attestation from Apple, which is fine.

The cryptographer in me is like, «No, use ZK! » But for application developers and users, like it's looking, that's pretty good. I already trust Apple with everything. I'm down to trust them to make the right signature here.

Personal AI assistants

The second trend, which is approaching faster, or at least easier to act on, is personal AI assistants. They are going to become a ubiquitous part of life for many people, giving them access to the full context of who you are and verifying various things as needed.

It would be super helpful for these agents to be maximally valuable to us and grounded in who we are. Here, the topic of signatures relates to things we were talking about earlier. You don't benefit from lying to your agent: you could be yourself and let it help you.

But signatures could be useful. If your agent wants to get a loan for you or something, it may need to have some signatures on your credit score, salary, where you live, and so on.

Feeling safe on the Internet

I've been thinking a lot about the fact that, ultimately, much of this technology is working towards giving people a sense of safety, whether that be safety in terms of privacy, portability, or selective disclosure.

I really push people to think hard about this concept and understand that technology does not make the average person feel safer.

The best example of this is LLMs, like ChatGPT, which people love to use as their therapists, including myself. I'm a Claude fan myself, so I told Claude a bunch of random things about my life that I probably would not have felt comfortable telling a lot of other tools and technologies. But something about getting this empathetic, thoughtful response that’s very conversational—there's a feeling there. I feel safe, even though I know it's going in plain text to their GPUs.

I would really push developers and builders in the space to step away from purity. Stop thinking of the ideal system for cryptographers and think really hard about the feeling of your application, which will mostly come down to designing, product, and comms.

Let's place more emphasis on that than on technology because technology is essential insofar as it guarantees the user a certain level of security and strength, but beyond that, it doesn't really matter if they don't have a deeper appreciation for what's going on.

And to be clear, it's entirely reasonable for people not to understand how everything works. I barely know how a computer works, but I love using it! We need to appreciate where people are currently at and build for that.

Letting go of security purity

People are underrating self-attested data. You don't need a signature on everything.

There are lots of situations in which you don't and lots of situations in which it makes everything way easier. I want people to think really hard about this: don't default to requiring zero-knowledge proofs and signatures in your stack.

It's often fine to do something weaker, especially for MVPs.

Finally, even though secure hardware gets a bad rap in this space, it is a way for people to prototype ideas more easily and get something to people with good UX, so we should do it. We should validate that these things are important first before investing millions of dollars into cryptography research. Your hardware is a good tool. Not using anything is also a good tool; telling the user we won't sell your data might be enough.

It's amazing to see all the research happening right now. Still, it would be so sad if it was useless. We could do a better job of validating that certain things are important and that people actually need the cryptography before we build everything out.