Episode 318 - Threshold Signature Schemes & FROST with Chelsea Komlo

Transcript

[Music] welcome to zero knowledge I'm your host Anna Rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online this week Nico and I chat with Chelsea commo Chelsea is part of the cryptography security and privacy Lab at the University of waterl and it's Chief scientist for the zcash foundation we talk about the spark that got her interested in cryptography research

starting with her work contributing to tour as an engineer to moov to zcash as well as her PhD work we define threshold signature schemes and discuss the optimizations that are possible and then we dive into her work on the frost scheme which utilizes some of these optimizations we cover how threshold signatures can be used in the wild the standardization process for frost her new work on stateless threshold schnor signatures and more now before we kick off I wanted to highlight the ZK jobs board for you there you can find jobs from Top teams working in ZK so if you're looking for your next opportunity be sure to check it out and if you're a team looking to find great talent be sure to add your job to the jobs board today I've added the link in the show

notes now Tanya will share a little bit about this week's sponsor Al IO is a new layer one blockchain that achieves the programmability of ethereum the privacy of zcash and the scalability of a rollup driven by a mission for a truly secure internet Alo has interwoven zero knowledge proofs into every facet of their stack resulting in a vertically integrated layer one blockchain that's unparalleled in its approach Alo is ZK by Design dive into their programming language Leo and see what permissionless development looks like offering boundless opportunities for developers and innovators to build Z apps this is an invitation to be part of a transformational ZK Journey dive deeper and discover more about Alo at al.org

and now here's our [Music] episode today Nico and I are here with Chelsea commo Chelsea is part of the cryptography security and privacy Lab at the University of waterl and is Chief scientist for the zcash foundation welcome to the show Chelsea yeah thank you so much for having me I'm a big fan so I'm really happy to be here cool yeah we've actually wanted to have you on the show for a long while and we tried a few different routes and I'm so glad we've made this happen um hey Nico hi Anna hey Chelsea hey yeah thank you so much for all the work you all do in the community it's like it's really fun to see all the shows you all do and it's just great

cool oh thanks I mean we're really curious to find out more about you too so like I think the first question I wanted to understand was like what was the spark that got you interested in the topics that you work on oh that's fun so actually yeah so before going to graduate school I was an engineer okay um which has actually been very helpful in doing cryptography research because I feel like I can put my like rer engineering hat on and think about like oh what would we actually want to deploy and practice um so that's been really helpful when designing research but yeah before going to graduate school I was an engineer and I worked on cryptography and privacy protocols so I couldn't contributed to tour I did a little bit

of work on enigmail I worked on some of the OTR uh protocol off the Record messaging protocol for secure messaging yeah and I just loved it and then I wanted to be able to design cryptography so cool but for threshold signatures um that topic really came out of the zcash foundation so in trying to make threshold signatures more usable and easy to deploy that's where kind of my current work has come from I want to go even further back though what got you interested in working on core and and on this type of engineering like what Drew you to that topic well I it's like a little quintessential but I guess like I guess it was back in 2013 when all of the big like NSA Revelations came out

and we heard about how private data was being collected about citizens and it it made me very passionate and it made me think about what information is exposed online and what do we want to keep private and is that within our control and that's really what privacy is about is being able to control what you expose about yourself and um that's what got me interested in well first contributing to those kinds of tools and then eventually helping design some of them cool what was it like working on tour what does it mean to do that is it sort of just like contributing from afar or were you like more in the

org yes so I was a a core tour contributor I wrote some Rust that helped Inspire the use of rust and tour which is great because it's a Memory safe language um I was on the board for a little while and overall I think it's great being a technical person being able to contribute to projects that people need so like people use tour to circumvent censorship or to look up things privately and I think it's really great for technical skills to be used for sort of altruistic motivations like that did you after that then look to study it cuz as as far as I know you're doing a PhD now like yeah what what was happening maybe at the same time

academically what what led you to to the work you're doing today yeah so I was on a team we contributed to a lot of open- source projects like tour and enigmail and then we started doing work on a new version of off the Record messaging protocol and that's the protocol that signal eventually built on oh wow so so it basically does ratch things so you have forward secrecy in your messages H and in contributing to that I got to know Ian Goldberg who's at the University of waterl and I wanted to be someone who could design those protocols myself and write proofs of security and think about

not just you know implementing what exists but also thinking about like how do we design new things and and that's what inspired me to go get my PhD and I've been lucky enough to work with Ian Goldberg and Douglas sta who are my co-advisors and it's it's an amazing thing to be able to think of ideas and be able to prove them secure it's very hard it's non-trivial and like you make tons of mistakes like I feel like I've made every mistake in the world at this point but I'm sure there's more mistakes to make but it's it's a fun uh expertise to have nice Ian goldbert actually I should I should add um is one of the OG like Cipher punks yeah like for those of you

who know like history of where we come from with censorship resistance yeah Ian has a wealth of knowledge about where privacy started and where we are and he's teaching a new class at the University of waterl on just the new generation of privacy enhancing Technologies and there's so much more we have today like where private information retrieval is going um secure messaging it's really an exciting space and it's amazing to see people deploying these Technologies that's so cool it's funny I I think in before we kicked off here I mentioned to you that I think you might be one of the first guests that we have on from University of waterl or maybe there were other guests that were from there and I we didn't know that but

the university for me it's been famous because you know vitalic went there and there was this legendary hackathon in 2017 and then another one in 2019 that you know spond a lot of products and ideas that are still used today in our space um but what is the University like what is the lab that you're part of like what what are the focuses yeah I'm just kind of curious to hear what it's like to go there yeah I mean it's a big lab so I'm in the crisp lab the cryptography security and privacy lab and people are working on all kinds of things so like everything from private machine learning to like more pure cryptography to apply cryptography to um censorship resistance

so there's a lot of different topics it's really fun I actually so Alfred Manas uh teaches at the University of waterl and I was sitting in his cryptography class and vitalic actually came to give a guest lecture so it was kind of a very full circle moment which is really fun ni um there's a lot of postquantum work going on as well so um David Chia who kind of came up with the uh sidh um super singular isogeny Dy hman is faculty there um so there's just a lot of topics it's a it's a fun place to be very cool so Chelsea what has been your focus within the lab yes since 2020 I've done a lot of work on threshold signatures this was kind of an accident

I started doing work at the zcash foundation in 2019 and one of the first questions they asked me is can we have a more efficient threshold signature scheme so they were looking to use threshold signatures within wallets in the zcash ecosystem and at that time for schnor threshold signatures specifically the most efficient schnore threshold signature that existed at that point was one um by Stinson and Strobel and it was five rounds wow and when you have basically in a multi-party protocol when I say rounds what I mean are network

rounds so rounds where parties are communicating to all other parties so Network rounds are very important because parties could go away or you could have Network latency or packets could drop and so multi-party protocols that have fewer rounds are much easier both to implement and overall faster so the core question was can we have a threshold signature with fewer number of rounds than five and there was kind of a folklore protocol of how to do a scheme in three rounds but then the question we wanted to ask is well can we do even better and that's where one of the first projects that I worked on which is called Frost and it stands for flexible

round optimized schnore threshold signatures and uh we were able to come up with a threshold schnor signature scheme that is secure in two rounds oh wow and what's what's very nice about Frost is that the first round can be pre-processed as well so if you especially care about Network latency you can do the first round in kind of a batched manner and then the you can just have one online round and that was something people were interested in and so it's kind of taken off since then and I've done a lot of followup on work work on threshold signatures since then cool I also think an interesting question is why do we care about schnor signatures

now yeah and like why is there so much work going on in schnor signatures yeah so schnor signatures have existed for a long time in terms of like the history of cryptography they were a very early signature scheme to emerge and really what a schnor signature is is it's just a proof of knowledge of discret log but it's bound to a message so your secret key is some like field element and your public key is some group element where your secret key is the discret log of your public key and so allor signature is is just proving knowledge of your public key but you additionally bind the signature to some message and that

that's all a schnor signature is so it's it's very very simple it's existed for a long time but it's quite amenable to building protocols on top of because it's linear so um it's quite amenable to building things like uh multi-party signatures because basically what you can do is you can have all the parties derive a signature share which itself is a schnor like signature and then you can just aggregate all the signature shares and come up with itself the a aggregated signature is itself a schnor signature cool so basically the these um pieces are very composable and schnor signatures lend

themselves to sort of more advanced Primitives that are easily combinable who was schnor who is this person CL cloud schnor is still a cryptographer gosh I I wish I knew all of the things that he worked on but the signature scheme is named after him and I think it came out in the 90s but I'm not sure okay so long time by cryptography we're talking 30 years yeah yeah 20 30 years okay yeah yeah you were talking about aggregating multiple signatures are we talking about signatures over different messages over the same message from different people um what do we mean by aggregation here yes so I know

there's been work done where you can aggregate over different messages but when I'm talking about aggregating here it's over the same message and so I guess maybe I can take a step back let me let me take a step back and talk about how a threshold Shor signature works and then I think it'll become obvious of how what aggregation means in the setting cool that great so the goal for a threshold schnor signature is to Output a signature that is verifiable under the same algorithm the same verify algorithm as single party schnor and the reason why that's nice is because if you're in implementation and you already verify schnore signatures then you can

also verify threshold signatures without having separate logic so from an implementation perspective it's very useful because it just allows for more Simplicity and less like logic switching so yeah so the goal is to Output a plain schnore signature but instead of having one party control secret key you have many parties and so what's nice about that is then you have things like redundancy so if one party loses their key you still have other parties that can issue a key and you also have a distribution of trust so if you say control a large amount of funds for your customers your customers might want some kind of they

want some kind of assurance that one party can't just disappear with the funds and so you might want to distribute Trust of that secret key so we want a couple things we want unforgeability under all of the secret key shares we also want unforgeability under the single key that's secret shared among all the parties and then we want to make sure that when all the parties sign those what we call Signature shares aggregate to a single schnor signature yeah so I guess in this case what we're talking about is one message there can be varience with additional messages but that kind of lends itself to a different protocol and different properties why is there work on this now if it already existed for

kind of some time before yes that is kind of a spicy question actually so uh so Shore signatures were patented oh and so a lot of people don't know this so a lot of people don't understand why we have both ecdsa and schnor and ecdsa is actually like quite painful in the multi-party setting so you can design very very simple multiparty schnore protocols and for ecdsa it's much harder because of the structure of the signature but what happened is we had schnore signatures first but then a patent was issued and then ecdsa was designed to kind of circumvent that

patent wow and so we were left with essentially years of building more complicated protocols around uh a more complicated scheme that circumvented a patent W so yeah so I think this is a really interesting thing to know and to talk about because I've heard Arguments for patents which say things like oh we're investing resources into cryptography we should be able to reap the rewards of like those resources which I think is a compelling argument but I think history shows us that patents in cryptography lead to Decades of work that we didn't necessarily need to do and and actually schemes which are

harder to implement and potentially less secure because there could be bugs and implementations it's also harder to analyze right E from a proving perspective yes so I think as a community we really need to be conscientious of where we came from and think really hard before diving into patents because you know for a certain company like it might be beneficial but for the community as a whole it's very difficult to design around yeah wow which company did the patent like could they have built more stuff yeah I I'm actually I haven't looked at the patent myself so I don't I don't I can't go into that much

detail I just sort of know that it was patented and that delayed a lot of and ecdsa came out around it and so I guess the important thing though is that the patent expired I'm not exactly sure when the patent expired but that's where as I understand we've seen a lot of reemerging interest inore signatures and things being built and developed around it nice so there was there was a delay in research and development and then when the patent expired we were able to say like oh this is a protocol we can actually deploy now again and so that's why we've seen a reemergence of of research in this area what's the connection between schnor signatures and Bitcoin or zcash

like you you said sort of it came out through your work at zcash I'm guessing Bitcoin oriented yeah what's the connection yes so zcash uses a variant of schnor signatures called red DSA so it's a randomized variant of EDSA signatures again the the difference between EDSA signatures and schnor is extremely minor EDSA you hash in the public key when you're signing the message but the structure is essentially same the same so when I'm saying schnore you can sort of also substitute EDSA they're extremely similar so zcash was already using a variant of schnore and then Bitcoin recently with tap r is

starting to move to EDSA or a variant of EDSA signatures as well okay just to emphasize EDSA is not ecdsa and I've seen people make that mistake before and they look very similar I kind of made a mistake in our last episode where I used it incorrectly it can be confusing but yes EDSA schnor Lake ecdsa gets around the schnor patent yeah don't don't blame the users the the names are very confus so I guess this then leads us to the work you did on Frost because like just to to sort of go back to the purpose of it you talked about the rounds are the rounds like a

function of speed or cost like trying to get these rounds down sounds like a good idea but what are you actually accomplishing when you do that yeah it's speed essentially so anytime you have a multi-party protocol all the part start then they send messages to all the other parties then they do some processing then they send messages again and eventually you have some kind of output so anytime you send a network message there's delay so you have to wait for all the messages to arrive if not all the messages arrive you need extra logic so there's kind of a lot of complexity that go into Network rounds and for things like signing if you're an

exchange and you have to issue like millions of signatures a day having fewer Network rounds is is quite helpful who are the agents who are actually like getting that speed up though is this for the miners is this for the like a wallet like I'm yeah I'm kind of curious where this actually gets used yes that is a good question and I think that does play into some of the discussion around do we actually there's been a discussion around do we actually need speed in these signatures okay and um there's been similar discussions I think as well around like do we need speed in zero knowledge proofs so I think uh Henry devent who's with penumbra said something which I thought

was very useful to think about which is for like a client side application the most speed you need is enough time for the user to process something which is kind of slow in terms of like computer speed so I think that that's actually something useful to think about so yeah if this is a wallet and it's on a user application like you could probably tolerate speeds of up to a second MH but if this is an application so for example there's companies that hold shares on behalf of their clients and so the the agents are servers performing signatures directly then speed matters because these are

just computers talking to other computers okay so the the agents do they they differ and the speed requirements differ as those agents differ but then also in terms of like complexity Network rounds can can be important as well because you have things like packet dropping and and other things like that it's funny that you mentioned speed and panra because in a recent episode that probably came out a few episodes ago we talked about the same thing with elen and I made the same shout out to Henry and pum how their tools do everything in the background so shout out once again yeah I think it's important for for assumptions I think it's important to challenge them so sometimes I think we

get very caught up in speed and sometimes it it doesn't matter and I think that's important to to know it's context dependent absolutely other other things that I think are also important to know is like on the cryptography side if you're designing cryptography systems you want the most security possible in like every Dimension but sometimes those like security trade-offs are acceptable in other dimensions as well such as like for Speed or simplicity so there's been kind of a tension around so Frost for example is secure under an interactive security assumption and schemes that have more Network grounds can be proven

secure under weaker assumptions and so there's been a lot of discussion around what assumptions are fine what do users want what like what is better and I think the the important lesson to come out of this is that it depends and it's it's context dependent so is this where the the frost magic happens like is this how you reduced all these rounds yes so um exactly so so schemes with more rounds can be proven secure under for example discret log directly which is a weaker and kind of well understood assumption yes so Frost requ Rees an interactive assumption it's under what we call the algebraic one

more discret log assumption still still in the random Oracle model so at least you know there's that but it's an interactive assumption and it basically says let's say you're given l+1 discret log challenges and you're allowed L queries for Solutions can you produce l+1 Solutions so basically can you produce one extra solution than queries that you're low so sounds reasonable I think intuitively it sounds reasonable this assumption has been out for a while it's very hard to prove blind signatures secure without this assumption so this assumption was introduced in the context of blind signatures so again it's it's

context dependent I think I I personally feel this assumption is reasonable and especially in a practical setting it's it's a fine tradeoff but again it's it's context dependent one last thing I wanted to ask ask when we start a threshold signature do the signers have their private key that they generated on their own or do they have to somehow have shares of a key like where do we start from yes the bootstrapping question is a very important question to ask um yeah so so signers have to bootstrap with a secret shared key it's Shamir secret shared so basically every party has a point their share is essentially a point on a PO

and the secret key this joint secret key is the constant term of that polom and when you combine signature shares what you're doing implicitly is polinomial interpolation to some other point on the polinomial which is unknown so really the magic it's very simple is given t + one points on on a polinomial you can find any other point on the polinomial so that that's all that's happening under the hood and so we we bootstrap by using either just plain Shamir secret sharing using a trusted dealer or another um multi-party protocol which is what we call a distributed key generation scheme and so

what that is is again you have all the parties they're all participating and the output from that protocol is secret key shares that every party holds that combine to some secret key that no party knows but all parties have contributed too so it's kind of like a magic Black Box every party throws in some Randomness and at the end they all get secret key shares that combine to secret key that no one has actually seen so the thing I'm still not entirely clear on is almost like in a system like zcash do you implement this somewhere or is it on an app like is it on a wallet level like I understand the research

being created but I don't really know where it fits in M yeah so zcash Foundation has implemented Frost and also a dkg and trusted dealer keyen and then applications can pull it in okay as they need to so if you're zcash wallet you will pull this into your application and the team right now is doing some work to make pulling that a little easier so they're working on demos and other things like that but this is kind of like a core library and then it's pulled into various applications and this is why it's being used outside of CC as well because it's essentially protocol agnostic so you can you can pull it into to like other wallets that

maybe need to implement more signatures and like you said usually the applications will be either creating redundancies and making sure that if you lose one of your key shares you have more and someone stores them for you yes so account recovery or multi like Distributing trust having multiple people having to sign yes so something that's very important to know so we didn't write this in the frost paper originally but there's tricks for doing share recovery so if one party loses its share there's established protocols out there for rederiving that share or creating new shares so that that party can recover their signing key and there's also protocols for generating

new shares for new parties so if you're out there and you have questions about like okay do I have just a set number of shares or is this Dynamic the answer is yes it's Dynamic and protocols exist for that and you've you've mentioned sort of multiple parties throughout this but we haven't actually said like multi-party computation does it fall under that category or are we working like beside are they just similar yes um so it is yes so technically threshold signatures are is a special form of multi-party computation I think it's nice to distinguish because when you say multiparty computation this

can be done generically so you can essentially take any function and distribute it among parties and there's generic tools for doing this those generic tools could also be used to do threshold signatures but they're generally less efficient okay and so and this is common in like other kinds of crypto cryptography where you can design generic tools but they're less efficient or you can design you know schemes that are for specific use cases and then you can tailor them for that specific use case and they tend to be more efficient so I think it's kind of nice to distinguish hopefully one day we'll have generic MPC that can just NPC everything um and people like I think especially in

the F world are are moving in that direction which is very exciting um but right now we we have the very simple threshold signature case which is quite tailored so got it I'm glad I got to work that question in because yeah just a shout out to Nigel smart who who did finally introduce us he was the one who finally made the connection and he had recommended he we've done an episode in the past or actually two episodes on MPC but a pretty recent one um so I can we can also link to that yes absolutely and yeah I I am really excited for what places like Z are doing and having yeah having generic MPC and like fhe is a really strong tool and I think it will

be it it's really exciting to see where it'll go in the future so hopefully we can have FH for everything and you know all of our problems will be solved easy although what it looks more and more like is it SE like combos like ZK and FHA anyway so back to frost you said Frost was developed coming from the use case that zcash needed is this kind of a standard technique is this I guess being standardized for other people to use yes so we wrote an informational draft for the cfrg the cryptography for research group within thef the reason why we did it actually was because we put out Frost and then I

had a lot of people emailing me to say that they were implementing Frost but they were implementing it in slightly different ways and making slightly different choices around things like serialization of data um hash functions just yeah like slight variations that I knew down the line would potentially be confusing and then potentially having bugs as well so I was that very stressful to you seeing the working taken apart like that I mean it was exciting but also I I was worried that well one we would have like a lot of incompatibilities and I actually had um Auditors tell me that they had seen bugs

pop up so for example someone told me that they saw an implementation of frost where the nonces were being derived deterministically as they're done in EDSA so instead of sampling nonces at random the nonces were generated by hashing the Seeker key in the message so if you're used to single party EDSA this is what you do you hash the message um and the secret key to generate your non switch is private so that's totally reasonable but in the frost setting this leads to a secret key recovery attack and two signing sessions whoa so it's like a total break if you if you do this is this the insecurity of Ros paper no so R yeah Ros comes down to

how the scheme is actually designed and so Frost was one of the first schemes that was Secure against Ros and it's because of how Frost essentially has two knas you hashen like the transcript from the first round and then that becomes your overall nons and that avoids Ro attacks but the the key recovery attack if you derive your nonsense deterministically is just because the the adversary has input into the challenge MH so essentially as long as the adversary changes doesn't follow the protocol deterministically but the honest does there's a trivial key recovery Tech

oops that you can't detect um so someone told me this and I was like oh no it would be great if we actually had something because a research paper isn't written with like exact engineering details um it's basically enough to show what's going on so that you can prove the scheme secure but it's not enough details for engineers to follow to make really important decisions like materialization or ordering or other like details that are somewhat important so so yeah that's why we decided to write this informational draft basically because people were implementing it and we wanted something that was more useful so that that process is wrapping up

right now and conveniently Nest has also put out a call or they're very soon to putting out a final call for threshold schemes as well and will be basically taking what we submitted to cfrg and turning that into a into a nist submission but then with nist does nist need to choose that and then it becomes sort of the standard but you're kind of up against other types of so this threshold call is different than what nist did for the postquantum call okay so for single party signatures it's I think it's easier to have a kind of uniform competition because you can do things like Define what the AP is uh

Define what the inputs and outputs are and this is what was done for the nest postquantum uh competition for threshold signatures it's a little harder because there's so much variation within the actual schemes itself so even though for threshold IED Ed DSA they all might be putting out a single party EDSA signature the internals of the scheme are all quite different I I think right now n is trying to decide what they'll do but this call is basically uh send us your schemes in more detail than in the paper and and then the and is still being decided as I understand got it so um so

yeah so Louise um who is at Mist who's sort of organizing all of this would be a great person to have on the show so he has more context and a plan and vision for where this will go so hopefully you can have him on and ask him these questions maybe we could do an app on standardization generally we've never talked to anyone from nist yes he would be a great person to have insight into what they're trying to do so we now have or soon to be your Frost standard what comes next what's the rest of Chelsea com's work well hopefully I'm just getting started so I have grand you know Grand plans for the future but um I guess one thing that

this process has taught me and I kind of referred to this before which is there's different tradeoffs in deploying cryptography for PR into practice so the trade-offs I sort of think about are things like usability security assumptions and then performance so those are kind of the the different axes when you're designing a scheme and you have different trade-offs along the along those different axes so before I talked about how people were using Frost deterministically and it was trivially broken yeah I've been thinking about how to do deterministic frost for a long time and it's a very hard problem it's

extremely difficult to do it in a way that's secure there's been work done to do deterministic threshold schnor signatures and basically those Works requir things like generic snarks or generic NPC so so you can do deterministic threshold schnore but it requires some kind of heavyweight tools mhm I guess so even taking a step back when I say deterministic threshold schnore the reason why this is something we want is not only because you can not have to rely on Fresh sources of Randomness when you're generating your signature but

also because signers can be stateless so basically you perform around and you don't have to say any state and then you perform your next round and you can just rederive all of the state so from an implementation perspective this is great because you don't have to cach things in a database take a lock on the database look up the thing in the database carefully delete information that if you don't delete it your secret key is leaked unlock the database um so so we really want like these games are actually quite attractive I think in practice but currently they require heavyweight tools yeah so I have some upcoming work which I think I'm I'm interested to see what

practitioners think about it so basically the work is called Arctic which I'm I think is nice thematic yeah yes is it also an acronym it's not I couldn't I couldn't think of an acronym with like DTS came into like a nice word um I spent a lot of time thinking about it um but was the best I could how much compared to the time thinking about the paper I mean not as much but there I I did I did try hard to make an acronym and just just failed um I'm always on the market for like good scheme names so okay tell me your good scheme names in the future if you have

them there's lots of variation on cold things that could fit into all of this yes so I'm I'm on the market for it in the future um Yeah so basically Arctic is a deterministic threshold chore signature and it's very simple it doesn't require generic MPC or um things like generic zero knowledge proofs but the trade-off that it makes is that it requires a larger number of assumed to be honest signers so basically for frost the security model that it's secure under is you can have t signers and up to T minus one of them are assumed to be honest so one honest party would be enough exactly

so and that's like a very nice security model that you can you can reason about so you have one honest party um for Arctic Arctic assumes total 2 T minus one parties where T minus one of them is assumed to be dishonest mhm so really what we require is of your total set of signers the majority of them are honest right so we go from single honest party to majority honest yes okay but couldn't really just be like 51% honest kind of just a little bit yes just a little bit more honest you're it's not a 66% situation

no it's it's like 51% honest and and so it's interesting because we do have assumptions like that already in cryptocurrencies so for things like consensus so in other places we have like 51% honest as an assumption but so far in in threshold signatures we haven't really explored those kind of assumptions and so with arctic basically we we say okay if you're fine with those kind of assumptions you can have a stateless scheme um that's pretty simple so then again it's up to implementers to say what trade-offs am I fine with am I fine with deploying more signers and

then having a simpler scheme that has like these nice security Properties or do I really need that like all but one honest about your your last axis speed how how does Arctic perform in terms of speed it's pretty fast is it still two rounds or is it a bit more it it's two rounds so I guess so there there's a trade-off so for groups under like size 25 it's pretty fast um there's a a tradeoff and like for larger groups music DN which requires generic as your knowledge proofs mus DN is faster so there there's a crossover point but what we see is like okay for smaller sized

groups where you're fine with 51% honest you can have a faster scheme but again I I think it's interesting putting out these axis more explicitly and then thinking about like what are we fine with but at least we have like all of the options and you know applications can say I don't know we don't mind implementing bulletproof and like we're fine with something being slower music music D is fine or Simplicity of the implementation is important to us because we're scared about bugs and we want something to be fast for smaller groups then something like Arctic is a better choice you've sort of said like i' I've heard more

about deterministic but also stateless how like are those the same thing are those connected yes so determinism is the means to statelessness in this set so we have a deterministic scheme or you might read about deterministic threshold Shore schemes but when we say deterministic that means that the scheme is also stateless because basically given an input I can derive some State and you know what it in some round mhm and you know what it is and then in the next round save yes St somewhere else okay exactly so if you're given the same um inputs to these different rounds then

you can deterministically derive that output cool so but they they are like kind of thrown around interchangeably so it's a good it's a good question when is this work coming out um as soon as I put the paper up on ePrint okay which is hopefully this week oh cool so it's can link it in the show yeah yeah by the time this comes out we should have it yes that would be great um yeah I really am curious this was kind of a hunch that I thought something like this would be interesting to implementers so I'm I'm very curious to hear feedback or thoughts from from people working in practice so like as people see it and think about it if they have questions I would love to talk to

people about it cool um in this you talk about this concept of dishonest but I don't think we've really talked about what that would mean to be dishonest in this particular case I mean we know what dishonesty is for validators sometimes we know but yeah what what is dishonest here yeah that's a good yeah that's a good question because we also throw that term around a lot um it generally just means someone who you have no assumptions about how they will interact with the protocol so they could follow the protocol honestly they could appear to follow the protocol honestly but like store extra stuff um you know generally with some like

nefarious goal in mind like recovering the secret key or outputting a forgery or you know per Performing denial service attacks but technically when we use that word it just means a party for which you have no guarantee how they will act within the protocol where would would these agents act dishonestly is it like in the rounds before after yeah so it could it could be anytime so I'm an adversary I have corrupted let's say two participants and I know they're secret cues I could initiate signing rounds with honest parties and follow the protocol exactly

and then I could take everyone's information and then I could try to do something nefarious with it afterwards afterwards I could take my secret keys and do something to them like flip the bits or something and then I could participate in the signing protocol honestly take the stuff that I received and try to do something nefarious with it so it's really it's very tricky and I think um writing proofs for these types of schemes is quite hard because there's a lot of nuance in what a corrupted party could potentially do so it's anything from before it starts while the protocol is going on or even afterwards and when we say honest majority do we mean these actors act honest throughout

the protocol or do we say at each round a majority of people have to be honest yeah so when I say like honest majority what I mean is that there are t participants who follow the protocol as described throughout okay yes throughout the protocol mhm so practically what this means is there T machines whose secret Keys have not leaked like this is practically how it how it translates but like when you're writing the proof this is kind of what you mean when you do the modeling are there any schemes that consider the case where the set of honest parties changes between rounds yes um yeah so there's schemes that

consider adaptive security and this is exactly what you're talking about so static and adaptive is I would say kind of a more theoretical term with like a a practical lens so when we write proofs something that's very easy when writing the proof is saying let's say you have n parties and at the beginning of the proof I say parties one through five are corrupt and they're those are the dishonest ones and the honest ones are like you know the last party and like the world stays the same throughout the proof but that's not actually what happens in practice like what happens in practice is like you can have an are that corrupts one machine and then it determines like on the Fly who it wants

to corrupt afterwards um and this is essentially adaptive uh security where throughout the protocol the adversary can choose who it corrupts um from a proof writing perspective this is much harder to model sounds like so um so I do think there's you know benefits for for writing proofs statically but the Adaptive model is closer to what we see in practice wow so do you have a an Adaptive Frost variant um I think we can prove Frost adaptively secure itself so direct Frost um the proof is very hard okay it's very we're working on it it is a work it is currently being worked on but it is

non-trivial yeah so it's an interesting research question around what theoretical trade-offs do you have when you assume adaptive security so again like if we have simpler schemes which are statically secure is that better I think that's an interesting question to to think about and like if you're assuming adaptive Security in the proofs but you have a less efficient scheme what like what does that mean and you know that's kind of an interesting conversation for all of us to have cool so I I want to ask a question about not this new work but the work we were just talking about before Frost before we sign off which is on potential use cases like we sort of mentioned you know security these systems and people had

actually implemented them I'm curious if you could just share any of those implementations yeah so the thing I love about Frost is it's kind of evolved into its own thing and people are doing lots of stuff about it and then I learn about it on Twitter which is like the best thing in my opinion it's so cool um so one project that's seemed exciting is um Frost snap so the name is really fun and it seems like they're implementing Frost like for the Bitcoin ecosystem and Hardware oh cool again I think it's amazing cuz like I actually don't know them I just watch their work on Twitter and I think it's it's great I think I've seen these it was a picture of like little things that plug into a phone and they can plug into each other as well oh

co and then together generate a a signature oh cool yeah they'd be fun to have on the show so I would I would love to hear how they're actually doing it are there ever cases of these kinds of signature schemes being used together with zkps and I'll give you just a bit of context to this question like we have seen a lot of crossovers with General MPC and zkps or FHA and zkps so I'm just curious if like can something like frost be used with ZK I mean obviously it's used in zcash so there's some connection but I don't is it really kind of being used together with zkps yeah so I think this is an interesting question and something that's still being explored so

in the Z cash setting it's interesting because Frost is used at the signing level so signers um sign a transaction but then the prover can be a separate entity that isn't trusted to hold the secret signing key so you can have a setting re of many signers and one prover oh okay and that's I think a very nice architectural and system design and that these um roles are separate so that you can set a separate out the signing key from the theover functionality so so that's what what zcash is doing there has been work into like

multi-party zero knowledge proof generation so there's um some work and we can link it in the show notes but there's some work where you take your witness your secret witness and you secret share it among provs and then the provs generate the proof in a distributed Manner and then they send it back to you and then you combine it uh that's that's interesting I think um the downside of that work is you have to Outsource your witness to other parties Okay and like maybe that's fine but like maybe sometimes that's not fine yeah that's not that just means there's no privacy right or like or there's only privacy between you and this other party

yes um so the witnesses secret shs they don't learn it but they do learn like what you're proving so okay I think there's also been some recent work using F again which is like the magic thing that hopefully will solve everything where um where you can have like an untrusted server doing FH to generate your proof without ever actually seeing your witness in the clear so I think that some of that work has been done um by sunam gar at the University of Berkeley there's been like many implementations of frost and I won't list all them here but in the cfrg GitHub repository for frost we list out different implementations and the

organizations that have implemented it hopefully we can include those in the show notes so people can go and look at other works that are using Frost as well cool we'll add for sure kind of bringing it back to your earlier experience and sort of the the thing that first got you excited about the general space working in privacy um I'm just curious what your feelings are about the space today and the research that's being done and sort of how it's being implemented so I think it is a thing people care about and it is a thing people are designing products around so that's a great place to be I do think sometimes some privacy research goes a little into the like how do we

collect data but in a way that's private or how do we like allow tracking but in like a more private way and I think practically that research can be useful if it means like it gets us to a better place than collecting everything and storing it m but I think as a community you know it it it always comes back to like the ethical implications of your research and I think we always have to think about what are we designing and Beyond it being like a cool and hard research problem which like I love those myself I love the challenge like we all do but like what are the ecosystem implications for the work that we and there's always the Practical like

well you know in the ad tracking business people track everything now anyway so let's do something that's a little better yeah so I don't think there's a right answer but I think as you know there's the the moral obligation of the work that we do and we always have to ask the question about what is making something better versus what is legitimizing tracking and what organizations do we support and what goals are they trying to achieve again I think that's why like FHA and like the work that's being done to make that practical is like an amazing feat um that's really exciting and in the meantime like there are always tradeoffs and like every organization makes trade-offs so like

for example tour makes security and privacy tradeoffs to make the tool fast so like every every organization has tradeoffs and you can't get around it but as long as we're talking about what those trade-offs are and who it benefits I think that that's the thing we really have to sort of think about I have a variation on this I was just thinking about this has come up you know for many months many years the the idea of ZK being used not for privacy but for other things and um I've sort of argued that well ZK is useful ZK is a a useful short form for like all sorts of different cryptography also snarks that aren't in

you know using the zero knowledge property but actually just recently someone joined our telegram group kind of shocked that all of these companies that do rollups with ZK at the front of their names are not private at all and um I was I was a bit like oh no like that's like a messed up narrative there b a bit of a m it's a miscommunication and uh that actually worries me a little bit because I think then people think they're operating in a private space when they're not and that could lead to potential problems I think though there's a big so when I first started doing cryptography research I

was like I will never work on something that is not practical I was like I've been an engineer I've seen all the papers that like you can't Implement I will never do a thing that can't be implemented um but but I actually go oh I mean yeah it's actually very hard to do things that are ready for use and practical immediately so I think the stance of viewing things as a progression is great and even though like yeah maybe ZK isn't being used right now the work that's being done to make it fast means that tomorrow we could have a private driver's license on our phone like that is a reality that

I think is coming to fruition and the work that's being done to standardized ZK means that companies who like want standards and like maybe to use ZK and another in another context could do that so I don't actually think anything is wasted and the progress that's being made is amazing and I think where I sit now after being in the space and in research for a while is it's very hard to tell when something might be useful and actually like you throw something out in the wild and like you don't know and then maybe 10 years down the line someone finds another use case or Builds on it or finds a tweak that actually

makes it useful in practice um so I I do think we will see like ZK for things like private identity in the future and for sure especially like I do want to give a shout out to the people who are doing um standards work in ZK like that's a very complicated thing to do um writing standards is very hard and it's kind of like an uncelebrated job even harder when the schemes keep changing yes yeah yeah the field is moving really fast and like the schemes are complicated but like the people who are doing that are doing like Heroes work because I think in the future it will unlock a lot of use cases for ZK cool Chelsea thank you so much for coming on

the show yes thanks so much for having me this is such a pleasure and thanks for all the work you all do I'm glad we were able to to organize it this time around we're really excited to see the new work and yeah hope to have you back on with your next Endeavor I would love that cool thank you so much all right thanks Nico thanks both and thanks Chelsea for sharing some of the new work I want to say thank you to the podcast team Rachel Henrik and Tanya and to our listeners thanks for [Music] listening