ZKPodcast: Crypto libraries, Zcash's Zebra and contact tracing with Henry de Valence

Transcript

[Music] welcome to zero knowledge a podcast where we talk about the latest in zero knowledge research and the decentralized web the show is hosted by me Anna and me Fredrik this week we chat with Henri de Valence from the Z cash foundation we talk about crypto libraries the work he's doing at the foundation the goals of the zebra Z cash implementation and the TCN coalition a group he is working with that aims to build and evaluate privacy

preserving contact tracing protocols but before we start in I want to say thank you to this week's sponsor trail of bits in their most recent blog post trail of bits announced some important updates to echidna their smart contract fuzzer echidna is one of the tools that the team of trail of bits used the most in their smart contract audits in fact it has been used in almost 35% of these audits over the last two years this includes the audits they did for maker dow 0x and balancer in this recent update to the fuzzer they have streamlined integrations with complex truffle projects and the tool now supports smart contracts written in viper they've also removed the need for kidness specific tests and can

automatically fuzz assert statements in solidity for more about all of these new features check out their blog posts which i've added in the show notes or visit trail of bits comm for more about their tools and services so thank you again trail bits and now here's our interview with Henry so today I want to welcome Henry de Valence who is a cryptographic researcher at C cash Foundation to the show welcome to the show Henry hey nice to be here glad to have you today our plan is to talk I mean mostly about the work you do at the Z cash Foundation but we also want to talk about this project that you're involved in called TCN which is a contact tracing project which i think is very relevant today I think a good

starting point for this episode is to find out a little bit more about you tell us a little bit about your start in cryptography and how that led you to the Z cash foundation so previously to doing cryptography I had studied mathematics and I was very interested in algebraic geometry and number theory at the same time you know interested in during computer programming and also interested in you know how how people interact with each other in a broad sense of in a kind of political sense that it's like a broad understanding of politics right

coincidentally the intersection of all of those three things includes cryptography or rather cryptography has some bit of each of those and so that's sort of what was the motivating factor for me and at the time I guess this would have been like maybe one year after the Snowden revelations so that was kind of the context at the time were you also working in like security at any point or was it always straight into cryptography no I was doing academic math and then I switched to doing academic cryptography so I started a PhD in cryptography and then that didn't really work out so I

quit and ended up in San Francisco did some cryptography implementation work and then I ended up at Shane oh it wasn't it was Oleg from yes Oleg yeah because he's been on the show and he mentioned the chain team okay yes so Oleg andreev and Cathy young and I we worked at chain on doing old proofs and then last year I moved to the Z cash foundation where I am now the sea cash foundation originally I mean I don't think it was originally built up of cryptographers they feel like it was more of this kind of

foundation like management team at least that's how I understood it has it always had a cryptography team or is that were you kind of an early hire for that so the foundation started pretty small and in the last year one of the goals of the the like strategic goals of the Zika foundation has been to build out an engineering team in order to kind of practically decentralize the development of Z cash and so I was of that effort cool I think me being snowed in in rust world perhaps but I mostly know you or before you joined the Z cash foundation and I got to know you

more like through talks and whatever else I mostly know you just from the Dalek libraries how you know did those come into existence and why did you you know start making crypto libraries and rust at the time I was working on a project and we needed a cryptography implementation and the existing libraries were great we're in greater or nonexistence I don't know like if you consider sort of like trying to do SFI to open SSL to be something that exists and somewhat exists now a kind of practical level of like is there some library that you can use as a kind of like mid-level tooling to build cryptography implementations I

don't think that that really existed at the time one problem with cryptography libraries that to me seems to come out of a place of kind of like fear of rolling your own crypto is that unlike other problem domains where there are various different kind of levels of abstraction complexity that people can pop in and out of if your problem doesn't cleanly fit into one or the other then you can kind of jump up or down a layer of abstraction in cryptography libraries the impulse to kind of like no one should roll their own crypto leads to people building very brittle and inflexible api's that are designed for like oh well like only

application developers who want to like use crypto will use this interface and everyone else is assumed to be like an expert crypto implementer who you know doesn't need reusable tools but the problem is that that doesn't actually work because there is no clear kind of like bright red line between using crypto and doing crypto and it also doesn't really scale too have more complex kinds of cryptography as you do cryptographic engineering for kind of simple crypto problems like I don't know doing a key exchange or doing a signature there's all kinds of subtle

things that come up and they have to be engineered away but the the level of cryptographic complexity to kind of engineer a system around for something like z cache is just like orders of magnitude more and so as you if you if if your goal is we want to kind of like scale up the kinds of complexity of cryptography that are actually practical to deploy then you have to kind of take this sort of like monolith of a crypto implementation and you have to kind of finally segment all of the internal parts to each be their own sort of like

different layers that build on each other and rather than just saying like oh well we'll have this like safe interface or like users of this thing and then internally it will do you know whatever kind of stuff because only experts look at the internals you actually have to sort of take that same design perspective and and put it at every sort of finer level of abstraction internally as well is that a little bit about like I wonder if this is similar at all to what's happened with the ZK snark breakdown and how there's certain parts of it now that are being tackled like snark as this general construction and this focus on like the parts that

plunk and Marlyn deal with or something like where is originally you would have had to construct these entire things completely now you see them sort of breaking them down does that fall into that category I mean I feel like that's a the same kind of process but rather than being applied to kind of software implementation more hardcore level just like engineering level like how to do cryptography in a good way versus how to do I mean to me it feels like actually a very similar process because it's saying you know here's this like big thing

right and that thing might be software or it might be some kind of conceptual machinery and then it's like actually what is the correct way to decompose this complex thing into simpler pieces that fit together and then once you've done that what are all the ways that you can arrange those like blocks and how can you understand you know these other 12 things as being different combinations of these same sort of like blocks so when you going back to that library that you rewrote or you thought you wrote did you think about that

differently like how did you use that structure that you just defined in your creation of that library or those libraries is it one or many there's there's a whole set I'm I'm I'm only responsible for some of the parts so there's like basically primitives for doing constant time operations one of the the libraries and then there's a an implementation of ristretto and 3509 and then there's the bulletproof s-- library that i mentioned earlier which is kind of like assembling these pieces cool did you invent the ristretto stuff or did you implement it so ristretto was

invented by by mike hamburg but i was working to implement and like write up notes on it Mike published a paper of a decaf which is the kind of like a core idea of that construction and in the paper there's a description of there's like two paragraphs towards the end of the paper that say here's how you can do this for fifty five five four nine because unfortunately the design of the curve throws some extra wrenches in machinery there's different ways that you could follow the notes in that paper to come up with our construction so ristretto is

like here's the kind of like canonical way to apply this technique to curve two five five or nine so the ideas were not mine I just did a lot of the notes I'm probably jumping ahead of the audience here a little bit because we are users of sr25 519 but maybe just before we jump into more the cash foundation stuff and get back on track what's the difference between IDI 25 519 which people are probably familiar with and sr so ed to 55.9 is a signature scheme that uses the edwards form of curse two five five four 9s are 255 is a

is a signature scheme constructed in mostly the same way that uses ristretto instead of the at curve two five five one nine directly what's the difference between normal 25 519 you know curve operations group work and like what does ristretto bring to the table kind of so maybe like an alternate form of the question is like what is the advantage of her strata or what does it give you yeah that I guess ties back into the the discussion of having kind of like mid-level interfaces whether those are kind of software interfaces or conceptual interfaces and and in fact

actually those two things you know should also be aligned in order to reduce the chance that the software has bugs but basically the problem is suppose you are a cryptographer or a crypto implementer or whatever and someone has put out some new crypto protocol and you think wow this is you know the Lubar protocol is the coolest thing ever and I want to like implement and deploy it immediately and you open up this paper that someone put on ePrint and the like first sentence of the paper is like okay let G be a group of prime order P and when you want to instantiate this

protocol you know that you're probably going to want to try to provide that group functionality using an elliptic curve but the problem is that most of the available elliptic curve parameters don't actually give you the abstraction that the paper is going to conceptually expect at least without some kind of like significant caveats so with witness to pick P 256 for example the implementation might have formulas that execute in constant time or it might not historically people have not had what are called unified formulas

for the NIST curves what that means is a formula that is valid regardless of what input elements you put in so if you have something that is sort of one formula and that's very easy to implement in constant time if the formula has some kind of condition like oh if you're doing this special operation and you do these other things that's much harder to implement and so it's much more likely that there are implementation problems to some extent this is better now or you could say I'm gonna use like curve two five five one nine because that's a very well-known I looked at curve and many people seem to like it but the problem

that you'll have there is that it doesn't actually give you a group of prime order that curve has a small cofactor so the meaning that the the order of the entire group is not a prime number but it's a prime number with serve one big prime factor plus this small cofactor and it can curve to five five one ninth case that's eight and you have this very subtle kind of abstraction mismatch between on the one hand what the expectations of the crypto protocol are and on the other hand what the thing that you are using to instantiate it actually does this can can have implications that sort of range

from being very like fatal showstopper bugs on the one hand to having like very subtle downstream effects that you don't necessarily notice at first but that will cause interesting problems later on so an example of the first kind of class of problems with cofactors is there was a bug in Manero a few years ago that was not exploited but effectively the cofactor of eight in the curve that they were using to implement that version of the crypto node protocol translated into someone could spend a note eight times

by making sort of like seven other sort of related copies of the note Wow which is obviously quite bad for a crypto currency and that's a kind of like example of a pretty pretty fatal vulnerability although to my knowledge it was not exploited and on the other hand even with something kind of as as quote simple as edie to fact 5.9 signatures the cofactor eight causes a bunch of very subtle and annoying properties downstream so for instance the RFC that specifies at two five five one nine signatures does not actually

require all conformant implementations to agree on like what signatures are valid you could imagine that for instance if you like use at two five five one nine in an application that requires like consensus then agreeing on like whether or not signatures are valid or not is kind of important and and this this sort of through twists and turns ultimately comes out of this cofactor issue and it also means that doing things like through sort of different twists and turns doing like hierarchical key derivation is much more complicated and difficult you can even have protocols where everything seems fine

but actually sort of the effects of this cofactor problem bubble all the way up into the user interface so in an early version of the one of the tor hidden service protocols this was fixed in the design phase there was a problem where the eight in the order of the group translated into you could actually have eight different addresses for the same onion service which is kind of a surprising behavior and this is what this is what ristretto actually fixes for I guess yeah so if you use if you use ristretto then all of these problems are kind of like handled for you

you get like an encoding function and a decoding function and it does all the validation kind of all bundled in and it sort of does what you expect cool has it had its own share of like it does it have new issues or other things that it causes not that I'm aware of I think it seems to work pretty well but I'm a little bit biased so actually the the bulletproof example is a really good example of how this played out when I was at chained we used ristretto to implement the bulletproof zero knowledge proof system first to do the sort of

simpler range proof part of that protocol and second to do the kind of arbitrary circuit proof and stuff actually using some kind of like custom extensions to the protocol that was kind of a very good test case of like okay you have this abstraction is it actually useful for building things and it turned yes we kind of were able to ignore all of the sort of lower level details and just treat this thing as like oh you've got this group and it can do group operations and we ended up with what I think is a very high quality and also

very high performance implementation it's the fastest Forex implementation that I know of and I think actually it's now gonna be used by mobile coin although I don't know anything else about it other than it showed up in their cargo tunnel all right so I guess let's turn our eyes towards Zee cash foundation and maybe let's start out just simply what is your role there so I am a cryptographic researcher at the Z cash Foundation and what does that actually mean it means that I do some amount of research and some amount of engineering and some amount of

researching engineering depending on sort of what needs to be done as a small team you know you kind of have to sort of jump between things in the earlier part of last year I was doing some research on a zero knowledge proof compiler for Schnoor proofs so rather than kind of like full scale complexity of arithmetic circuits you can also do quite a lot just with Schnoor proofs but they're quite which are just statements about group elements and you know how they're related by discrete logarithms like I know the discrete logarithm of this group element with respect to this

other one but implementing them is kind of tedious and so I wrote a library that has a sort of a toolkit for doing nor proofs and then also it actually implements a proof compiler in rust macros that lets you write a proof statement using similar notation to what you would find in an academic paper and it just generates the entire implementation for you so you can sort of read through a paper and you know with one with the paper in one window and your text in the other window

you can write out a crew statement that looks almost identical to what's in the paper and it will automatically generate a sort of production quality implementation of that crew statement wow that's so useful yeah what end up so that was an early project that you worked on and then and then we started building a an engineering team and starting our project to have the easy cash foundation have a independently developed Z cash no which is zebra and zebra originated like originally paradis built that sort of first version of it mhm so I guess you were very involved in that handover you know Fredrik maybe do

you want to share a little bit about what zebra was from the paradis side at the start sure i I don't know I think we handed it over before you joined the foundation Henry but from parodies and we had built a Bitcoin client already and the original Z cash client is based on the C++ Bitcoin client and then they've added more than like originally it was just some tweaks on a fork and then they added more and more stuff and then they had their own crypto library that was all written in rust and they and they sort of you know plugged that in and once it got to that point it was actually pretty trivial for us to plug in that rust library into our rust implementation of Bitcoin and so that's

sort of where this originally came from where we're contracted by the cash foundation to build a rusts the cache implementation based on our Bitcoin code because the original Z cache implementation is written in C++ yeah but now because of how the companies moved it's like half C++ half rust FF ID monster that is really hard to deal with and then yeah when we were done you know it was thinking mean it and it was doing its job we handed it over the only one that was that was really around that I

talked it was Deirdre and George he he was like just joining as we were handing this off and then I had a sync up of a few months after that and they taken it on they broke the code base a bit and started started working on it but I don't really know where it's gone from there so with with zkg this the situation is as was just described right you've got this kind of like rust implementation of very high sophistication and complexity cryptography and then it's sort of like bolted on to the side of this Bitcoin code base

I don't follow Bitcoin super closely but my understanding is that since the cache was started the quality of the Bitcoin code base has improved considerably but not all of those changes have sort of landed because G cash forked too early so you have a situation where you have this kind of like very precisely engineered like you know sort of like beautiful v8 engine that's just kind of like bolted on to the side of this clanking machinery and you just called it Z cash D so Z cash D I think we have covered this before on the show but C cash D is this is the original client that version of it was basically created and is now maintained by the ECC the

electric coin company one of the questions that I have had kind of and and I was hoping you could help us coming on the show is a little bit about like how do you work with the ECC do you work with the ECC like you have your own client implementation now so like is do you share things like how is the communication between you I would say that at an engineering level there's very good communication when we have questions or concerns about things in the Z cache spec or about some of the various common libraries that we share you know we have very good engineering communication in terms of kind of like strategic priorities

it's totally independent got it and and actually so one of the things that has been really beneficial from us working on this second client is that we've been going because we have been doing this implementation based on the Z cache protocol specification it gives us a really good way to kind of spot any inconsistencies or bugs in the spec or bugs in the implementation because we have to kind of go through things with a very fine toothed comb Wow yeah it's almost like it sounds like a verification of sorts like you're

going step by step through like an audit even though you're I guess you're recreating it yeah I would say that the the process is quite similar in their respect let's go back to zebra so I want to hear a little bit more about what you are doing on zebra now so we've kind of we've we've outlined this differentiation between these two clients but so and you'll still work with them on the engineering side to stay I guess synced but what where is the project at so we're part of the way through we have a slightly different goal it's overlapping but I would say they slightly different with G cache D right the goal of that software is it's supposed to be a node implementation

right but there are a lot of things that you might want to do that aren't just sort of being a node implementation all kinds of sort of like tooling for things that aren't necessarily literally a full node or maybe they need to be a full node as part of doing something else but really what they want is tooling for interacting with the Z cash chain and so our kind of development process is that we are basically building a set of tools and libraries for working with the zk chain also you know very convenient side effect if you assemble those together then you get

a full note but our focus is on having that kind of come as a collection of building blocks and so we're making pretty good progress on having all of those blocks complete last fall we wrote a completely new network stack for easy cash that allows basically we have this library called zebra network and although it's still unstable you know in the future if you have an application that wants to interact with the Z cache network in some way you can import this library and call in it and all of the kind of node network layer machinery

gets spun up for you automatically and you know has a connection pool and sort of does all that stuff we have also been working on a library for sort of modeling all of the different data structures that are used in Z cache so as the kind of result of the historical development of D cache Z cash transactions have four different formats that are all quite different right they're sort of like the classic Bitcoin transactions and then there are the SPRO transactions there's also sapling transactions because so after getting the initial prototype done they moved from the

original zero knowledge proof system which was using BC tv-14 proofs codenamed spurt to a much much better implementation using a different proof system codenamed sapling there's sort of all these different versions and we were taking a sort of very kind of like functional programming type approach to modeling these things so we actually defined a data model for Z cash transactions that makes all of the rather than letting you sort of have all these different pieces of data that might or might not be valid in combination with each other we use enums and careful sort of

of all of these components to make sure that it's actually impossible to ever construct a transaction object using this library that doesn't correspond to a kind of sort of structurally valid G cash transaction and and in the process of doing that we've identified a couple of sort of small bugs in the spec which has been a good experience you're sort of I wonder if it's not proving that kind of idea that having two clients makes for a safer more secure Network - or more let's say just having at least two teams maybe more teams potentially really solves for a lot of the the vulnerability get basically would mean that vulnerabilities would be found

faster easier yeah I don't know that it would sort of solve everything but I think that it can definitely like cut out like a particular class of bugs it's relatively easier to write a specification that reads as if it is very precise but the actual test of specification is like can you implement it because that requires working through sort of every tiny detail it's very difficult to check that without sort of actually doing it I'm just curious what the size of you know the engineering team at foundation is now because as I said earlier when we handed this off it

was one or two people I assume it's larger now and you know where is where is the team headed a certain moment the engineering team at the foundation is sort of three and a half people there's myself there's Derek Connelly who's our engineer there's George Tankersley who is the director of engineering and we have some of Chelsie Carlos time and the rest of her time is spent on her PhD work so yeah it's still pretty lean team then yes I mean I like the approach just talking about the networking stack as an example this is something that's come up

in a very intense of times where someone wants to write an or crawler or something just to figure out how many nodes are online whatever and they like both the open aetherium implementation and rust and the go implementation are written in such a way that you can't really pull out networking and use it on its own so anyone who wants to write a crawler may ask to rewrite the networking stack from scratch so it's interesting that you bring that up as an example because that was actually kind of what we had done - so one other kind of small but important pieces of Z cache infrastructure is what's called a DNS cedar which is a

service that basically crawls the network and then it lets you make a DNS lookup and then it will hand you some peers that you can sort of bootstrap your way into the network when we were trying to figure out what direction we wanted to take zebra and we were trying to figure out whether we could sort of along the way when the original parity Bitcoin codebase was made the whole like rust async networking ecosystem also advanced by like several light years so we were trying right so all this like async/await stuff is now built into the the language and so we were trying to

figure out it would it be possible to kind of like jump directly to like the latest version of async rust and also have this kind of library first architecture and our MVP to kind of figure out was that is that realistic and like could we do a small projects or D risk that design was actually to make a crawler that could serve as the backend for this DNS cedar and so this this exact problem that yes other people also have is perfectly solved by by the way that we've redesigned the zebra

architecture no so sort of to change course but stay within the Z cache foundation topic I was wondering if you if your work there if you're touching on cross privacy research because I've sort of heard through the grapevine that you were doing something around that and I was curious to hear a little bit more about it well or whatever you feel like sharing yeah so actually we were planning to publish some stuff about that and this week actually so I'll just sort of tell you about things that we've been working on cool we previously put in our Oh in fact all of the engineering work that the G cash foundation does is part of a public road

map because we you know we're supposed to be transparent and accountable and so we said that we were gonna work on the design of a D cache to cosmos peg zone and after publishing some kind of like very basic initial notes and then going around to try to talk to as you know a bunch of cosmos people we have a kind of a sort of second iteration for that design that were we're planning to publish a description of real soon what would it mean though like if you like the Z cash chain with the she'll that accounts live in one place yeah

would it be like a bridge to another chain like I'm confused actually about what that cross like what that means in this context what would it look like so in cosmos specifically they have a whole kind of cross chain system called IBC which stands for inter blockchain communication and that's kind of like built into like what cosmos is yeah basically it you're gonna lock up funds on one chain and then transfer kind of a bearer token for those locked up funds to the second chain but what that requires is that the two different chains or zones as the cosmos people call them both have

transaction finality which for cosmos which is approval state system kind of comes naturally but in any proof of work system you don't ever act Ashley get finality for like did this transaction happen all you get is you know how many confirmations have happened how many blocks have been lined since this transaction happened and that gives you kind of a probabilistic finality where after a certain number of confirmations you can say okay the probability that there's some like alternate chain gonna happen is so low that I don't really care but that doesn't quite work with this IBC design so instead in cosmos for doing

interoperability with proof-of-work chains they have what's called a peg zone mechanism where essentially you in the sort of cosmos universe you have this standardized cross chain thing and there's a special zone that then sort of takes the responsibility to decide when some transactions have happened on the proof-of-work chain and what we've been working on is actually how to make a cosmos peg zone that can hold funds like in a shielded way or like the prior shielded way yeah yeah because that's like the regular pegging from other

chains is probably I mean there's probably a system to do that but the we're kind of the unique thing about the Z cash build is that there's this shield at account private transaction and and the really cool thing about this is if we can get it right you know so they're just gonna hedge that a little bit because it's still a work in progress but if we can get it right then we can actually combine like the coolest feature of Z cash with the what to me is the coolest feature of cosmos which is this sort of interoperability and and to me the coolest feature of Z cash is that unlike all of the other cryptocurrency privacy solutions z cash has very very

strong network effects for privacy and the way that that works is there's only one shielded pool right so new users gain anonymity from all prior transactions of all existing users and in turn contribute to greater anonymity for the whole system and so if we can build a basically a shielded cross chain that allows you to sort of bridge not the sort of transparent universes but bridge sort of the inside of a shielded pool to the inside of another shielded pool you can sort of broaden those

network effects for privacy and anonymity to also the include other other chains Fredrik is there also a way to peg from outside into polkadot yeah is it same thing it's a similar thing so if you crack this Henry you might be able to use it in a few different places I guess yeah I think in in any sort of bridge solution it's the same thing yeah so I'm not sure that there's really anything that's like super cosmos specific about this it's just sort of what we picked as our current sort of target cool that's exciting I mean that idea of sort of cross chain privacy has

been at least something that's come up a couple times here but like who would implement it and like how close do you think you are so at the moment we're working on scoping out the design and in particular trying to break all of the so we have this sort of you know final beautiful goal of the dream world and breaking down okay here are all the steps that would be required to get there and of all of these different components that are required for this end thing what are the ways that we can sort of assemble subsets of those to have like useful intermediate products

along the way to building sort of this final thing we have a kind of a two-phase design where the first phase is just going to be like a basic peg zone that is set up to enable all of the features that we want in the second phase where we would add a shielding into the peg mechanism itself and would you build it yourself this is like a Z cash foundation build or is it combined with other teams so we're working on a plan to build it we probably would not do all of it ourselves but we're kind of in discussions with various people to see interesting mmm this is a very exciting

part of like like Z cash to me has been in a way like the champion of zero knowledge proof sand the education and it's amazing like interesting ecosystem but still sort of standing alone like because it can't interface with a lot of these other things so I'd be so curious to see what it what it looks like once it once it starts connecting up to other networks that's really cool very excited so now we've covered a lot about your work before Z cash and drains e cash and now I want to kind of go forward because I know that you've been involved in another project a contact tracing project so maybe we can find out a little bit about what you're working on there yeah so there's a few different

projects for doing privacy-preserving contact tracing I'm involved with one of them called TCN coalition TCM stands for temporary contact number which is the term for the numbers that are broadcast over bluetooth all of these systems are kind of supplemental contact tracing or maybe it's better even to call them just contact notification technologies should we define what that is like what is contact tracing what is contact notification I think so because it's also a thing that I really struggle with imagining what it actually does like what does it bring to the table how does it help with anything

that sort of like I see a bunch of people talking about contact tracing and a bunch of companies started working on it rolling on solutions and I'm kind of sitting here going well what's the problem what what what is it solving so the basic idea of contact tracing is like okay you've got some kind of infectious disease and it spreads from person to person and so when someone turns out to have contracted this disease to slow or prevent the spread you should find out as best as possible all the people who they could have come in contact with and try to sort of do something whether

that's test them or ask them to isolate or whatever and so far it's been done manually basically like when when somebody got sick you could you hear about it like I remember when the first case happened in Germany like they were able to trace you know all the people that this person had come into contact with but not because of an app or because of an outbreak right this is like a totally like classical technique of Public Health it's not like a new new idea what what is the new suggestion is that now that people carry around devices that have little Bluetooth radios in them maybe it's possible to provide an automated technology that can

either supplement the sort of traditional methods or act as a kind of a backstop in the event a day don't work for whatever reason sort of hinges on some action being being taken I think that's where it breaks down for me because I always see the context of these applications being talked about as gathering data it's just gathering data for analysis it's not that I then tell someone that they've been in touch with someone they should go get tested or whatever it might be so I yeah I guess that's where mentally but it breaks down for me I mean it's obviously a controversial topic because of this because everyone is just talking about tracking and

taking a bunch of data and I guess that's in part what you're trying to address with these projects is actually doing in our privacy-preserving way yeah so there's a number of different projects the all have the kind of comment goal of demonstrating that in fact this sort of data collection that you're talking about is not necessary it's not necessary to track everyone's whereabouts if you can just be able to determine who someone's potential contacts are and I would also kind of stress that this is something that that is one tool among other tools that there's a lot of problems where a kind

of technical solution can be very useful and it's worthwhile to try to develop but it's not by itself sufficient to solve the entire problem however you know the people who have skills relevant to designing sort of privacy preserving crypto protocols are not going to be able to usefully apply those skills to like any other aspect of this crisis like someone can't just sort of like pivot to be like oh you know I'm a biomedical expert and I can design your testers right although Twitter you know crypto Twitter makes us think otherwise but yeah so so the thing that the reason that I

mentioned that right is that to me the thing that is like unique about this problem is that it is one aspect of a very large problem that will require you know a lot of work by many different people with many different skills but here's like kind of one niche part of that problem where it is actually useful to have cryptography interesting do you want to tell us a little bit more about what this TCN coalition is unlike what it's made up of at the Z cache foundation we wrote a blog post that was basically a kind of a call to action for cryptographers should involved with contact tracing protocol efforts through that I got connected with Dana Lewis and

Scott Lee Brand who had started a project several weeks earlier called coop E which stands for community epidemiology and the idea of that project is basically like rather than waiting for some kind of centralized response people could have a way to altruistically just self-report symptoms to each other you know as it kind of explicitly opt-in just people sharing information and they had been collaborating with another project called kovat Watch which was also

focused on the problem of doing contact tracing I'll be it with a slightly different model focusing on sort of luck test results reports from doctors etc and so they were working on a common protocol I got involved with that there were some really great design suggestions from George Denise's and I kind of helped combine and streamline different design elements into a kind of proposal for a contact tracing scheme obviously with with many other people then this effort kind of started snowballing because there were all these other people who also you know wanted to interoperate on having a common protocol

and so at that point the kind of interoperable protocol layer was spun out into a new organization which by which I mean actually like a new slack instance called the TCM coalition and this is this group at all working with any governments or is this plan to have it be a standalone so you sort of mentioned it's opt-in non-centralized but would you still want to like connect with the with the larger governmental efforts I I can't really speak for all of the projects that are involved so that at this sort of level of this TCM

coalition the effort is making a common interoperable protocol for doing Bluetooth communication for contact tracing and then there's different applications that are using it and they believe that some some of them are attempting to work with different governments I'm not really kind of you're not working at that level yeah I have been just trying to sort of stay on top of what's been going on just with like Bluetooth level protocol stuff because in any in any product there's now I think more than a dozen different groups that are kind of joining up with this effort and in any kind of project

that starts snowballing as the size grows you sort of have to kind of pick like okay here are the things that I am able to pay attention to to deal with they're good trying to focus on the critical stuff I mean I do think we have a few guest line or kind of I'm in talks with a few upcoming guests where we're gonna explore some of these topics a little deeper probably on the different levels but I think for the TCN coalition from what I understand it's really just focused on coming up with the standard with a standard of sorts what is it what does it look like like what I mean I know it's not built yet but like what are you even playing with what kind of cryptography the cryptography is very

simple the cryptography and Bluetooth part to some extent is already either built or on its way to being built the basic kind of shape of this protocol you can think of as being a kind of a weird type of messaging app where you go around and you are carrying a device that does bluetooth and it broadcasts pseudo-random numbers called temporary contact numbers thus TCN I guess right while doing so it also observes all the numbers that it receives over the radio and at some later point as a user you

can send a message to all of the people who you were in broadcast range to containing some data and when you do that you you actually prove that you were the one who generated all of those numbers and different applications can have different policies for basically authentication of those messages so for instance an application like Co epi that is trying to focus on people doing symptom reporting has a kind of a different trust model than an application that is focused on test results that are in some way verified

but that's kind of like an application level concern at the core protocol it's kind of agnostic to what that decision is how can I send message to the people who've been in touch with without there being like a centralized register of these are the people that exist and what their IP is or what they're you know who relays the message so you you do need a centralized relay but the relay does not need to be trusted and the relay learns nothing about the kind of social graph of interactions between people so effectively the way that the protocol

works on a kind of a abstract level is you break up your history into chunks you know as you're moving around in the world right every so often you sort of start a new chunk and in that chunk there's a basically a ratcheting procedure that lets you derive an arbitrary number of these temporary contact numbers later when you want to send a report to people who you may have come in contact with you upload to the relay server some data that is sort of like a pre image of some chain of hashes that allows anyone to

download your report and kind of regenerate all of the temporary contact numbers that it is related to and compare those against the local observations so because the server only ever see is you know here are reported numbers it doesn't learn anything about the the social graph of the users I see and you can sort of prevent learning metadata by observing the relay server because basically everyone downloads every report and tries to see if it's relevant to them so the way that this is that works on on the back end is that you would quantize time into fixed blocks like say six hours and for every time interval the

server will accept you know all the incoming reports and then when that interval ends it takes the batch of all the reports that are got it randomizes the order to prevent someone from saying like oh well if these two reports are next to each other then they're more likely to be like different chunks of the same users history or something like that and once it does that it's got like basically a very compact static file that can be put up on a CDN or something so there's very little server load although there's bandwidth use because all clients download all messages you don't have a problem of having a ton of compute heavy server work it's very

cacheable how close are you to kind of finalizing this proposal do you think you're talking like weeks or months is there a timeline or a goal it's very difficult to make a prediction because the contact tracing ecosystem is in flux I would say that there are a number of teams that are currently working on integrating the protocol into the current revision of the protocol into their application and we are currently working on planning the next iteration of the protocol version it would be great if there were compatibility between so TCN is not the only proposal

for doing decentralized contact tracing and it would be great to try to achieve compatibility or sort of combination of designs and there's discussions about that ongoing and of course Apple and Google announced you know their own entry and so you know obviously they have like a very large install base and on the iOS side in particular they have access to kind of the like platform Bluetooth internals but it remains to be seeing like exactly what the final version of that design will be or what that will

actually look like and how private that actually ends up being I mean I would say that although there's like a lot of kind of reflexive skepticism of Google and Apple in this instance I think that the protocol that they published is relatively good you know like there are a few things that I think you know I personally think could be different but if that was the thing that ended up being deployed I would be very happy relative to the alternative of you know some government mandates that everybody reports their GPS locations I do think that the the AG protocol is pretty

privacy-preserving and you know the privacy team at Apple does actually care about user privacy also there are there are many people at Google who who care so in this case I think that those people were successful I think that would actually be interesting to talk to somebody from one of those teams to find out about what they're planning I don't know if they'd come on our show of it yeah it is it is an interesting space and a scary space I mean in one part of me goes if Apple forces me to have contact tracing out you know break my phone in half and go back to the Stone Age and part of me is like well I know you just just

encapsulated everybody's attitude very well they're good well one thing that I would one thing that I think was may not have been made totally clear in reporting on it is that in their or protocol it is essentially indistinguishable from just normal having bluetooth-enabled up until the point at which someone reports that they tested positive or something and so the the question is not whether like Apple would force you to use the app I think that the question is whether some Health Authority would force people to use the

system to send reports and I think that would be very bad I think that these systems should always be opted in one of the problems that's very difficult to solve for kind of fundamental reasons is the problem of reported privacy so anytime you have a decentralized contact tracing system at a minimum it's possible for someone it's always possible to come up with a scenario where someone could infer the identity of the person who is reporting just based on circumstance like if you met with one person during you know

Wednesday the 27th and then later you like get an alert on your phone that says like on Wednesday the 27th you may have been exposed than like you know anybody set of 1 right that's one variant of the problem another is if you go to a place like London where all of the garbage cans have Bluetooth antennas and try to like track everyone's movements through Bluetooth then effectively you know all of those garbage cans are also you know quote users of the system who want to like know whether they were exposed and and

so there's a sort of a fundamental problem there which is that if if you are trying to tell other people who you came in contact with that they may be at risk that's information that they'll and and that information may be possible to combine with other information and so it should be your choice to decide whether or not you want to do that I think the natural fear here is not the application at hand but what like the scope creep that can happen when every device in the world has this installed the government suddenly goes well you know we need to enable this for everyone

because we want to stop terrorists you don't like terrorists who you know so you need to tell us when you're in touch with a terrorist and then it's well you need to tell us when you're in touch with a pedophile you don't like pedophiles do you and then you know oh you need to tell us when you're in touch with a drug dealer or and like it just goes on and on and yeah so I think that it's a good concern but there's a way to address that concern which is to build a system whose design is structured in a way that kind of prevents scope creep and so for you know the TCN proposal with the Apple Google protocol with the DP through T

protocol all of these are based on people pushing messages to other people that they may have come in contact with and so all of the examples that you you mentioned of scope I'm not saying that no scope creep is possible but in particular the sort of potential scope creeps that you mentioned wouldn't really be possible to retrofit into this system because nobody can learn who they came in contact with until that other person publishes our report so it'd have to be the drug dealer saying I'm a drug dealer and then everybody would find out

that they'd come in contact with the drug dealer right doesn't really I mean maybe drug dealers that I'm sure that there's ways to like make horrible laws that would misuse the system but the kind of the really obvious baseline ones I think don't aren't functionally compatible that somewhat reassuring but yeah there's no there's also no shortage of horrible loss so I don't know but it's I I think it's been interesting following because there's a healthy amount of criticism but there's also like a lot of people that come out and defend the systems that even like I saw someone come out and defend Apple on

I'm like no these engineers know what they're doing they they've thought about this or that thing and like it seems like a reasonable system to build I've even heard I mean in the last interview I did with Claudia Diaz last week this what she mentioned sort of it she had almost an optimism about what's possible for privacy tech today versus what she had seen during sort of post 9/11 fighting terrorism level of surveillance this you know today just feels like a lot more helpful towards people like the goal is to actually you know help people not get sick it's the goal is not to like find out who has bad ideas in their heads and that lack of confrontational

approach could maybe offer some opportunity I mean we don't know but I thought that was like a nice way of thinking about it yeah alright so we've talked about a bunch of things and it's been very interesting we've gone from crypto library since Izzy cash into TCN and a bunch of things in between it's been great having you on so thank you very much well it's been really great to talk with you and thanks for having me and to our listeners thanks for listening thanks for listening you [Music]