Security in Privacy Applications

Transcript

Um, hi everyone. I'm Nico. I've been working for eight years trying to build secure blockchain applications. Currently working at Aztec. Per that worked with open Zeppelin and Balancer which turns out was not that secure. Uh, I want to discuss security in the context of privacy preserving applications. >> Oh, okay. [laughter] >> Thank you. Yeah. Okay. I can go without the slides. I think I know it by heart well enough already. >> Um, so the point that I want for you to take home is that >> privacy must be a long-term consideration as any sort of privacy preserving application is being built.

You can't just slap CK into a smart contract and call it a day. Uh, it needs to be considered from day one and as a long-term uh, consideration. what we refer to as security incidents. Most other industries would just call software bugs. Uh but they have much higher severity in our case due to the very nature of blockchain. Uh once a hack occurs, once a contract is exploited, funds are lost, uh systems are blocked and there's no fixing them. The same properties hold for privacy. Once information that we thought would be uh secure and not revealed gets leaked and is now publicly available, there is no going back on that. We cannot put the genie back into the

bottle. >> Yeah. Yeah. I I'll go. >> Sorry. >> Um additionally, privacy applications have what a sort of unique feature in that they can also fail retroactively. Uh which is not something smart contracts typically do. Uh imagine for example the Ethereum block hash function. If we were to uh suspect that there may be an issue with a block hash function uh leading say to block hash collisions, we can just fix it. We can have a hard fork fix the block hash fun block hash function and at that point we're fine. Um even if someone were to then try to perform an attack, the fact that we used it in the past is completely relevant. We're now using only the new version. So the issue

does not apply. But consider that you instead deposit funds into a privacy pool. You deposit, sometime passes, you withdraw, you now have no longer no longer any funds in the privacy pool. And you think that's good. It's a system I use in the past. This no longer applies to me. If the system, say years later, fails in such a way that depositors are linked to withdrawers, that may still affect you even though you're no longer part of the system at all. Your information also is immutable. So the depending on what it is, how important it was for you to have depositor and withdrawer be unlin this may damage you greatly.

>> We often say that privacy is a spectrum which is typically a shorthand for just saying that um in some cases it may be okay to reveal some public data. But it also means that the expectations of users when it comes to the privacy of their information depends on the very nature of set information. If I am playing a private game of battleship, it is totally fine if the nature of the game gets revealed as soon as the game ends. If I privately purchase coffee, that's totally fine.

Say if five years on the line, everyone learns about that. But things like medical records, uh, private messaging, um, any kind of financial interaction, there's likely no time frame in which I would be okay with that information me thinking was private becoming leaked. Leakage itself is also on a spectrum. uh even if the underlying data remains private, you're still exposed to things like metadata leakage, uh IP addresses, time stamps of transactions which from which time zones may be inferred uh any queries that are made to public nodes as data is being fetched to say build your knowledge proofs. All of those continue uh der uh degrading essentially the

privacy of the user at which point might be as severe as revealing the underlying data itself. Essentially, all of these things put together paint a clear picture of privacy being something that needs to be considered from day one. Any loss of privacy is as severe and as final as loss of funds. Um, users have wildly different expectations of the security of applications depending on the nature of data. So, that must also be kept in consideration. And there was a third point that I'm glossing over because of the lack of slides unfortunately, but it was very good. Uh again what I want to leave you with is any privacy preserving application must have from the get-go

strong considerations long term long after users stop exiting the system in terms of how private information is kept and how it is stored. Thank you. >> [applause] >> Give a round of applause to Nico.