Privacy in Cosmos Live: Fatemeh Shirazi (Anoma) - No Privacy Solution is an Island

Transcript

so welcome back after the break and now welcome to the stage fatima chirazzi from anoma [Applause] okay i'm going to talk about privacy today but i chose i hope the title will convey the message that i want you all to to take home it was inspired by no man is an island i guess you you guessed that and i wanted to explain that privacy is complicated and that we should collaborate more together um for better privacy

the talk is going to be about um i'm going to have some introduction on what privacy is why i think it's complicated um i have a bit of a review of existing privacy enhancing solutions in the blockchain space i'm going to talk about what type of privacy they provide and how they could be improved it is not the talk is not about saying that any solution is bad but just to explain to you how it's complicated and it's important to understand that complexity in the end of the talk i'll explain what the problems are from my point of

view and what we can do so why should we care about privacy i assume you all care about privacy that's why you're here it allows people to choose what type of information is revealed about themselves and it's important because knowledge about personal information allows abuse it allows discrimination um it prevents people from participating in the society freely in a democratic way so it's important um why is it complicated i have i had to add a picture of a bicycle here in amsterdam

and the point here is to show that even if that lock is the best lock that humankind can make this is not secure i hope you all agree i even i could lift this bicycle and run away with it and the the lock is amazing the let's assume the lock was done by i don't know nasa whatever the best people on earth but this is just security is more complicated than just having a solution as a very secure solution generally security deals with confidentiality it deals with integrity and authentication while privacy deals more with our social interactions our activities because it's hiding in personal

information so it's a bit more complicated than some security properties and it's important to look at solutions from a multi-dimensional weight in this picture you see that that one dimension is the lock the other dimension is what is the bicycle locked too and that part is completely ignored so if you just look at solutions from one dimension a lot of them seem amazing but the reality is they are not really secure it's just an illusion of security and to add also why i think privacy is quite complex is it is connected very much to our daily lives it cannot be achieved

very in isolated way like security can a lot of privacy is about hiding your activities among activities of other users or even fake activities that you could make up but this is very expensive and it's very difficult it's very cumbersome for example we are all awake at certain times of the day waking up at you know 3am and sending a message just to have a fake message sent this is cumbersome and what is to be added to privacy uh is also is connected to our family and friends and they might not want to they might not care about privacy that much as we do and they they

might find this too expensive or cumbersome so that makes for from my point of view privacy even a bit more complicated and difficult to achieve than security in blockchain normally in blockchain at least traditionally in the past blockchains were supposed to be or people thought of them as private but what they really were like bitcoin or ethereum is they have pseudonymity so you have accounts that are not associated to your personal identity but it is a single account and everything is transparent the problem with that is if you if you use it carefully or no one is looking it could be okay we don't know who

satoshi nakamoto is and it's pseudonymous it's not great privacy but we still don't know because it was early days no one was really looking there was not that much activity but as you know as soon as you start to have activity with the pseudonymous account this is going to become sooner or later broken an example of that is you can have an account in bitcoin uh ethereum as soon as you send something to kraken and you have kyc and your passport picture or something a game over um you send it to someone that the fbi can get to or or some government again game over so there is a lot of ways where

maybe if you do one transaction pseudonymity is okay if you want to do it on a daily basis a lot it's almost impossible to be enough so what we have in traditional blockchains we cannot really count on the privacy you can get lucky maybe no one is looking but the chances are if you use it a lot you're not going to to to stay private so i hope that i have convinced you that pseudonymity is not a great idea for privacy before i start to look into existing solutions i wanted to explain to you what the attacker model or the adversary is because there is no from my point of view there is no absolute private like

it's not a zero or one you're always secure or private against a certain definition of what the adversary or the attacker is an example of this is like at the door the door here is secure you know if you lock it against some sort of adversary is it against secure against a tanker no it's not going to be secured against every type of threat and depending on how good the door is it will you know keep out different types of adversaries so it's important to understand that complexity one thing to take into account is who your adversary is in terms of how widespread they are is it someone who just locally has access to a transaction

is it someone who can have access to everything is it the nsa so the the reach of the adversary is is different the other question is whether their adversary is poor or resourceful how how much are they willing to spend how much money are they going to spend to attack you or how much money are they going to spend to analyze information to find you and something that is very relevant here in blockchain is memory this is often not talked about in security and privacy circles but i think it's very relevant for blockchain because a lot of the privacy solutions here are about short-term memory and long-term memory people consider things that are not on the blockchain to be private but the

reality is you're just not having it stare for someone who has a very short-term memory so someone who cannot you know remember what happened yesterday of course if it's not on the blockchain then fine but if someone can remember anything that has happened then just the fact that it's not on the blockchain is not going to be enough so whether they are going to whether your your privacy definition is not being on the blockchain or not or your privacy's definition this never been anywhere on the internet that's a different uh it's a distinction and the last one is being a passive adversary or active so you see there's a lot of nuances in what the threat model is

so let's go to the first solution that i found i have never used um many of these and again i don't want to i want to emphasize that this is not um critique on any single solution but rather really showing to you the complexity so mixers the idea of a mixer is that you instead of sending a transaction directly from a sender to a receiver you're sending it around you send it to fake accounts that you created and they're they're sending this these transactions around until it goes to the receiver and hopefully no one knows that all of these fake accounts in between were yours your own they will think that you know these were other

people and it will somehow disconnect the direct connection between the sender and the receiver of a transaction um it is private for a very very weak adversary so your adversary has to be really really weak for you to consider this pretty private because maybe one time you can do this but if you do it a couple of times with chain analysis this is not so difficult to break um but it's it's one solution another solution are off-chain option transactions these are the idea is that you have some sort of settlement on the main chain all the micro transactions happen off

chain on a different network so here i have examples like lightning network um on on bitcoin you can have a settlement between two users they lock 200 worth of bitcoin then they go off bitcoin they do a lot of transactions back and forth which is not recorded on bitcoin and in the end they come back and settle the rest what is what is left over so what you achieve here is that on the blockchain on the bitcoin blockchain there is really not much information about all of the activities between these two people um but that's really what it is um you're not really private against a strong adversary you're private against the adversary that only can see bitcoin and that's it like their

computer only sees what happens on bitcoin um so that and here i don't think the problems that a local adversary that sees what is happening between these two sender and receiver can easily find out what the connection between the sender and the receiver and another point is and i didn't bring this up in the previous slide but it's time and correlation this is quite big in the privacy community you identify people based on timing it's metadata there's a famous quote from a guy in nsa who was saying we kill people based on metadata we don't need to know just the fact on when someone is sending

what if you do it long enough you can identify based on who is awake when when you have activity you can identify who is having a relationship with someone else so timing correlation in this case is still still possible another solution is monero which is a very elegant solution the idea is instead of having one signature that is identifying the identity of the sender you have group signatures so you have eight people who sign something so each one of these eight people could be the signer the signature does not identify which one of the eight people has signed

this is okay if you do it once and if the competition of these eight people also makes sense but i can give you an example maybe there's eight people seven of them are from vietnam and one of them is from switzerland the receivers are taught from switzerland it's not so difficult to guess that probably the guy who sent from the one swiss person in the eight people um is the one that signed the the transaction so is it a bad solution no but is it perfect the group size is too small uh depending on the diversity of the signers um depending on how often this has been used this can reveal um information the other point about this uh different than

the lightning network the off chain transactions here every the whole history is on the blockchain on the monero blockchain so you can look really into this look at the signers of each one of these group signatures and at some point it should be possible to identify some people they do also in monero also you do not hide any timing signatures so again based on activities based on when you're awake when the receiver is awake there is a lot of like conclusions that one can make the next solution is mimblewimble that has been deployed in green sorry green beam and light coin recently also

the idea with mimblewimble is that you aggregate transactions it's very similar like going to a restaurant and when you pay you put all of your monies together and then pay the waiter at once the beta doesn't know which money came from who you're aggregating transactions from different people and then uh just give the collected transaction to to the blockchain which is cool in the sense that it's also reduced actions that are recorded on the blockchain so it's a scalability also solution the problem that mimblewimble has though is that collecting these transactions or collecting these bills has to be done in a way that the waiter is not seeing them if the waiter sees

who is putting money on the pile then really you're not achieving much and the same is with member wemble the network layer where these transactions are collected has to be designed well and if these transactions are you know just broadcasted which they are in some cases then you're secure against someone who has a very short memory and does not remember what was broadcasted and only sees what is on the blockchain but you're not secure against someone who can remember oh i have seen these transactions before and then later on they were added up and put on the blockchain um the last solution i have to review is ecash it is a also very

elegant very nice solution zcash uses zero knowledge proofs and the idea is that the sender receiver and the amount of the transaction are not visible it has a transparent and a shielded mode basically in the transparent mode you're very similar like other blockchains in the shielded mode these the sender receiver address and an amount of transaction are hidden which is very cool so i really like zcash though there is still some problems that also z cache has one is network layer when a sender is that the timing that the sender is sending something and the receiver

is having any connection to zcash this is not hidden you what zika suggests is using tor but it is not integrated in in the protocol itself and the other problem is that there is no hiding of timing signatures one can have transparent funds transparent and then put them in the shielded pool and then remove them again and there is no delaying between these so based if i have two users alice and bob they both shield then they do the the transactions they unshield every time they do that same time at some point it's very clear that these two people are exchanging

a transaction with each other and this is again not so difficult to such conclusions are not so difficult to make so what are the problems the main problem i see is that often in the blockchain world people equate using a tool as we have solved privacy and it's just not that easy if you use tomato you don't have bolognese there's more complex complexity there is more details that you have to to have to take to account um if you just use draining signatures or just zero knowledge proofs this is not solving the solution only you have to look into the whole dimensions on other details that you're that you're

adding the other problem that exists is that there is not really a standard for tread models or solutions all of the solutions that are presented to you they were really designed for different types of adversaries for different types of needs but these are not really standardized so for the user like let's just my mother or my dad who are not privacy experts um if they would wanna they would use any of these without really understanding uh what the difference between these solutions are so i think we need more standards for both threat model and for solutions because otherwise for the user it will be very very difficult to know what what solution to use

and the last part is that solutions are not compatible or complementary a lot of solutions are solving very nicely sometimes one part of the problem but then when new people come on board they do not build upon that but create something new and i understand that it's cool to you know create new things it's not so cool to go fix other things or um you know complement other things but we have to remember as an adversary you attack the weakest link always if you want to get into some you know in into a room you don't go and try to to crack open the most difficult door that the room has you will go through the window which is open

so ignoring the dimensions and solving something is just giving an illusion of privacy but for an adversary you're not really doing much this is more of an illusion of of having solved the problem so what do i think we should do first of all we should identify complexity we should acknowledge all the problems that are the needs that the the users have the whole stack whether it's wallets and i haven't even i wanted to add information about wallets but i thought that's a whole new like presentation it would be too much for 20 minutes to talk about so wallets uh the blockchain like so many parts of

the whole stack have to be taken into consideration the second part that i think is important is to have privacy as a goal and not have using a tool as the goal so the and the same is again when we talked about um you know tomato and bolognese the question is do you want to make bolognese or do you just want to use the tomato and this is something that you have to have in have in mind so privacy should be the the real goal um the other point that i think is important to improve um the the privacy of the whole space is simplicity and understandability so we need to make um solutions as simple as possible

we also make to make need to make them as understandable as possible for um for users the next point is privacy loves company privacy is often about hiding in the crowd hiding among other transactions of other users hiding um your identity in the you know in the forest of of all other uh users and that's why it should be easy for users to participate in uh in these tools because the more users you have the more privacy the whole the rest of the users are going to have and the last part which i hope is one of the big messages that you're going to take home is collaboration i would

really really really wish for more collaboration between blockchain i mean projects in general but definitely privacy blockchains that care about production projects that care about uh privacy it's important to have compatibility with each other to um to work on standards to to improve things and the last slide is about the project that i'm working in the moment um how is anoma trying to improve sorry for the red i hope it's not too much of a contrast compared to so what are this trying to do and we are trying to work on a multi or we are working on a multi-attribute pool the idea here is to

have to allow users to use similar technology like zcash does but with multi multiple assets so uh allow users to have to also enjoy interoperability the next point that we are working on is design of incentives that also take into account um privacy so normally incentive design focuses many more on economics on incentivization in terms of security but for us privacy is a big factor there too we are working also on end-to-end privacy and this is looking into privacy for the whole stack and this is something that also came up in a presentation before we are using the ibc standard and are working on

privacy bridges and mainly to allow users from different types of chains like penumbra namada anoma and ethereum all to be in the anonymity set which basically makes the the forest bigger and makes the crowd bigger and hides users more so that's it i hope um that i that you all take a take home that yeah we should collaborate more and we should get into the complexity of privacy thank you thank you very much before we release you from this stage do you have any questions was everything too difficult or too easy

uh yes could you uh maybe uh highlight some of the end-to-end privacy things that you're doing the privacy yeah within the end-to-end layer like networking and mempool and stuff like that the auntie i don't know here you mentioned that you're also addressing privacy end to end end to end yes so what we are looking into is integrating network looking into the network layer privacy and integrating it in in our technology we are also looking at privacy at wallets which is basically where the users are are interfacing the most uh with the blockchain

um [Music] and something that we are also looking into is delays um which is the timing signature that i was talking about um so yeah we're trying to really look into from the starting from the user on the blockchain anything on the way very very there are places where information can be leaked thanks i'm i i guess i'm just interested in um how does the private bridge design work and like oh that's a good question um i have not been involved with the pride do we have chris here maybe you want to

because i have a private bridge in mind but it's not the one the other design that you do you want to yeah i can give a quick answer here so the tricky part in private bridges in the ibc context is balancing these competing goals of providing fault isolation which ibc has in ics 20 by metering supply transferred across the bridge so it's like basically one blockchain has an account on the other blockchain and you can stop the other blockchain from sending back more assets or other kinds of state transitions that you didn't originally send to it or

didn't originally authorize it to do but as soon if you you know have say zcash style sapling circuits on multiple chains and just do zero knowledge proofs for your like ibc cross chain transactions that's fine except that now you no longer have a way to meter supplies you don't have this fault isolation so in order to preserve this fault isolation we need some kind of encrypted computation that allows us to keep this like counter say of how much supply of a particular asset has gone from chain a to chain b while not revealing it because if we revealed it each transaction that would of course break privacy so we're specifically looking into a solution that uses basically limited additive homomorphic encryption so when you perform a

cross-chain shielded transfer you can add to this encrypted counter and test this encrypted counter when you perform a transfer in the other direction never goes negative meaning that more assets are never sent back than you originally sent but without revealing anything about the value of this counter or the value of individual individual transactions so it's mostly a cryptography problem to try and get these two constraints that we want to satisfy thank you i think we all said thank you very much once again a round of applause for tampa fatima [Music] [Applause]