 Alright, it is 940 Pacific, so I guess we should get started. Can everyone hear me? Awesome, I guess we're good to go then. Welcome everyone to our panel on cryptography, from theory to practice and hyperledger. The goal of today is to be fairly interactive, to allow you to ask questions. We've put together a broad range of people from cryptographers to cryptographic engineers, basically lots of people who use and build cryptography in a wide variety of ways today. So we'd like to give you the opportunity to ask questions, see what people are up to, and really just interact with some of the core cryptographers in hyperledger. So I'll start by introducing people and letting them speak briefly about what sort of cryptographic work they do in hyperledger. So I'll start with Angelo DiCaro. So Angelo, as many of you may know, is one of the original architects of fabric and is an integral contributor to its cryptographic systems. He has a PhD from the University of Salerno. And he's also an accomplished cryptographic researcher with quite a number of publications across cryptography and security. So Angelo, would you like to say a few words about what your cryptographic interests in hyperledger are? Yeah, thanks for the introduction. Definitely today I will focus mostly on zero knowledge, and in particular I would like to discuss, to talk about this new project in the fabric space to bring tokens with zero knowledge on top of fabric. So very, very exciting news coming, and I'm looking forward to talk about these things. Wonderful. Thanks a lot. So next I'd like to introduce Marta Paikarska. Marta is another accomplished academic. She has a PhD from the Technical University of Berlin. She's a very accomplished security researcher with a lot of publications in the area. Marta has a long and very interesting history working in blockchain, which I'm sure she can tell you about from a block stream to a long time in hyperledger, and now working in DeFi at Balancer Labs. So Marta, would you care to say what kind of crypto stuff you're interested in and working on? Sure. So I guess given my background and the stuff that I'm doing now, and kind of commanding the two, I'm really interested in how we can make DeFi more usable and secure, and what are the differences between the usability of, especially the usability of permission blockchain systems and permission less. So how does that impact usage? And are there things that we can learn from the permission less world into hyperledger or the other way around? So thanks a lot. So next I will introduce Mike Lodder. For those of you that don't know him, Mike is our most prolific Ursa contributor and maintainer. He's done a lot of work across many hyperledger projects, including indian Aries, and he's a very, very prolific freelance contributor. If you have used a lot of blockchain technology, there's a very good chance you have used some of his code. So Mike, would you like to introduce yourself and say what you're interested in and working on? Mike, you're still muted. Mike, are you there? He said in the chat he's trying to get his audio to work. Well, then I guess we'll skip to you then, Brent. So finally I'd like to introduce Brent Dundle. Brent is the principal crypto engineer at Evernom. He's been a long time prolific hyperledger contributor. He's worked on and been a maintainer on Ursa, Indie and Aries. And perhaps most famously he has a Best Real World Crypto Talk Award, which is something many famous people in academia covet heavily. So Brent, would you like to say a few words about what you're interested in crypto and what you're working on? Yeah, I'm most interested currently in cryptography that allows for safe and non-correlating use of verifiable credentials, such as the India non-cred system and more recently the BBS Plus signatures that were introduced to Ursa. Today I'm going to talk mostly about the different uses that BBS Plus is being put to in the real world and how it's being incorporated into different standards, efforts, kind of around the digital identity community. Fantastic. Finally, I'm Hart. I'm also a cryptographer and one of my big interests is post-quantum crypto. So I know there have historically been a lot of questions on post-quantum cryptography and I'll be happy to answer any of those today if people are interested. So our goal for the panel is to give all of the audience, so all of you guys, the opportunity to ask all of these expert cryptographers like Angelo, Mike, Brent, and Marta, all the questions you want. So we're hoping to do that with breakout rooms. So I guess, Gary, is there a way we can start having people go to breakout rooms? Hey, so I believe that you were supposed to have links to those? Were those provided? So the individual people with breakout room, sorry, Angelo, Brent, Mike, and Marta, I believe got links. How can we have others join? Do we need to post those links in chatter? I think that's probably the best way. I can't think of a better way, so I would say go ahead and do that. Say, you know, if you'd like to join my room, please click this link and then each individual can post that and then the person will be able to join it. Okay, do you guys still have those links or alternatively we can answer questions? I do have some of them or you could maybe start off as a combined room and see how it goes. Yeah, why don't we start by answering questions in chat? So does anyone have any questions about any of these topics that you'd like any of our panelists to answer? Please feel free to start asking in chat. Otherwise, Angelo, I'd like to start by asking you a question. So you were talking about some zero knowledge enhancements for fabric. Can you elaborate on these? Yes. So there's been a long request a long time since people have started requesting support for UTXO tokens for fabric. And in the background, at IBM, we have worked on this and we wanted to provide a solution that was very simple to use. I think I'm very much related with what Marta said. The cryptography is cool but can be very complex to be used. Not only from the end user perspective but even from the developers who have then put these building blocks together and make them and develop a distributed application. So what we open source it's called actually fabric token SDK. It's a piece of software that allows developers to develop distributed applications in fabric using for tokens for UTXO tokens. The beauty of this SDK is essentially you can at any time decide to use zero knowledge or not use zero knowledge in an absolutely transparent way. So not the developer, not even the end user had to feel any burden in using this zero knowledge technology. In practice, what does it mean that this framework takes care of the key handling, generating the proof, make sure that the metadata are distributed to all the parties. There are things I think one of the most complex parts was exactly distributing the private information to all the parties that needs to be aware of the information. Why is this? When we talk about zero knowledge, we are essentially talking about publishing commitments to the blockchain because we don't want to reveal the content of the tokens, right? So we just use this digital commitment, which is an equivalent of a sealed envelope, right? It's a digital version of the sealed envelope and zero knowledge just allow us to prove statements on top of this, on the content of this commitment. But if, for example, by swapping, for example, assets, they must have a way to communicate to communicate to each other the secrets that they are using to perform the operations. So orchestrating this was actually more complex than implementing the zero knowledge proof system itself. So I can maybe give you the link in chat so you can start to explore this project. And if you have any question, I'm very, very glad to answer them. And in particular, we want this project. So we started the first batch of the code, which is just give a very simple experience with zero knowledge. And then in the coming days, we put more and more technology out. Thanks a lot, Angelo. Please post that chat. I'm sure a lot of people will be interested. So we have a couple of questions. Mike, I'm going to pause on your question. HyperZ asks, is Hyperledger fabric framework turned complete? Yes, the smart contract framework is turned complete. There's a question from Pritam, which I think Brent maybe you can answer, or Mike can answer. The question is the following. Could you guys talk a bit about domain and domain proofs in BBS Plus signature and share any kind of references or codes for domain proofs? I'm happy to turn it over to Mike if his audio is working. Otherwise, I can try to muddle through. I believe he's still having audio problems. I'm trying to direct message him and work on that. But for now, I think he's not able to connect. Yeah, there's another question on BBS Plus in chat, Brent. So if you want to talk a little bit about that, that would be fantastic. I'm having trouble seeing the questions. It's in the Q&A tab. Yeah, so you have to go session and then Q&A. Session. See, this is where, okay, too many tabs. We have the question for you. Would you like that? No, I see, what do you mean by domain proofs? It would be my response question. So I could talk to the first one introducing predicate proofs into the JSON-LDZKP BBS Plus scheme. This is something that we've actually stood up a working group at the Decentralized Identity Foundation to begin working on this. You're hitting on the key thing there again. Right now, the decomposition into N-quads as part of the canonicalization algorithm limits us from being able to structure the inputs in such a way that is conducive to doing predicate proofs on them. And so one thing that we're looking at is first, adjusting the canonicalization algorithm to not use RDF canonicalization so that we can, they can be more cleanly specified exactly how the inputs are being formatted. The second is to, the first way we're looking at doing it is actually incorporating some of the ideas from Microsoft's Spartan proposal. And work on that is kind of just taking off. I'm happy to drop links to the sorts of things we're doing there. Awesome. Thanks a lot. I guess we can go back to that if there are more questions on that. In the meantime, Marta, I had a question for you. So what do you think the role of, I'll call it, I'll be nebulous and call it advanced cryptography or advanced cryptographic protocols are in DeFi? And how do you think that will drive cryptographic development? Well, you know, I guess it's interesting because DeFi gives a lot of great incentives for people to actually think about cryptography because it's money and nobody wants to lose money. So I think that it is, it's something that is top of mind for everyone. And like, not only in terms of just traditional crypto, but just analysis of the code and security like audits and things like that. Balance are actually for their v2 version to launch a bounty program that initially was one million and then increased to two million dollars, which I don't think I've ever heard about that big of a bounty. And that tells you something about how serious the security is or thinking about security. So definitely there is a lot of scope for research in terms of understanding how can we prevent stuff around smart contracts? How do we prevent smart contracts that are broken from executing? How do we analyze something that is very interesting actually is discussion around ultimately all of those DeFi protocols want to become DAOs, decentralized autonomous organizations. So one of the models is that the governance or the community can propose new changes that are immediately encoded into smart contracts. That's the compound to a style, which is they just, if you have a proposal, you write the smart contract for it and then you propose it. Now there is a lot of mechanism in place in order to kind of have a cool down cool off period of I think two weeks before it actually gets. But then once it gets executed, it's just like two weeks that you can actually analyze this stuff and then it's there, it's out there. And then there are methods of preventing if or like putting a call on the system if there is a bug or some issue. But there is not much thinking going on into how do we streamline that. Thanks a lot. Yeah, I mean always interested to see, you know, sort of, you know, how the big money drives crypto and the bounties are super exciting for that because it, you know, it puts real money behind it. I have a question for you. Sure. So you mentioned, you know, that you want to talk about or you're interested in the post quantum prove toe and quantum prove toe. I guess my constant question there is how big of a threat is it? That's a great question. And I think Paul Watkins asked a similar question. So truly figuring out what sort of threat quantum computers have is really for a question for physicists. So I'm not a physicist and I can't tell you exactly, you know, when this quantum computer will be ready, when we'll be able to crack, you know, RSA with quantum computers and so forth. There are a number of issues. And the biggest issue I see is what's called forward secrecy. So basically what this means, right, is in today's world, right, we encrypt data with Key Exchange, right? You know, we send data over the Internet. And there are lots of people recording all of this data, right? So if someone records my data now and then five years later someone else comes up with the quantum computer, right, then all my old encrypted data might be able to be decrypted, right? So the idea is if you're using some kind of encryption scheme today and someone is saving your data, it could be broken in the future with quantum computing. So if you think, and I think this is probably, you know, way too optimistic, but if you think that a quantum computer will be able to break crypto in five years, you know, any data you have now that might still be sensitive in five years, you need to start thinking about using a post-quantum encryption scheme or a Key Exchange protocol. So sort of the forward secrecy threat is the biggest one. And certainly for government and military applications, probably the most likely people to be able to get their hands on a quantum computer are going to be state-level actors. So, you know, governments, people like that. So that is a big thing. Fundamentally, we're going to, for blockchain at least, we're going to need to change our signature algorithms and there's a big NIST competition on this. So we'll probably end up using what's called lattice-based cryptography for new digital signature algorithms. Fundamentally, there's not much change in terms of what an end user would see, although the key sizes are substantially larger. So you'd see some performance degradation. So I hope that answered your questions. We've got a lot of other questions that we'd like to answer. So, Angelo, you were asked, can you illustrate a use case for UTXO in combination with ZKP? Yeah, definitely. I replied also that that's interesting. The first one that comes to my mind is definitely central bank digital currencies. There are a lot of initiatives from many central banks in the world to digitalize fiat currency. Not only privacy, but also privacy with auditability. So the systems are, especially if you are talking about central banks, you will have, by law, parties that are entitled to be able to look at these transactions. So some special parties in the system. So if we just deployed zero knowledge as it is, this will forbid this kind of auditability settings. So that is probably the most crucial point because it becomes also the weakest point in the chain. So if there is a master key that can start kind of decrypting, even though we are not posting in the solution that if you use our token SDK to implement CDBC, we are not posting any ciphertext on the ledger because there are other regulations that would forbid anyway you to post ciphertext on the ledger. So there are other ways from which you can extract the content of the commitment. But anyway, this auditability is definitely the most interesting aspect in the enterprise application in the CDBC. Definitely every time that you won't start tokenization of any assets, digital assets or real-world assets that you want to move to the digital space and you want to have multiple parties playing with these assets, you immediately face the need to some level of privacy and then with it you will come immediately to some level of reconstruction so you might want to see the history of certain assets that you have tokenized or you might want to do auditability. So that's more or less the set. It's pretty huge, Jack. It's pretty huge. Thank you. Brent, so there was another question from Will Abramson on using CL or BBS plus-based credentials as group SIGs. Mike had a very brief comment on that. Would you like to elaborate on it since Mike's audio is still not up? Yeah, I mean it's a natural question to ask because the original reasons BBS and CL signatures were, I mean they are group signature schemes so why don't we use them as group signature schemes for credentials is a really good question. The only answer I really have, we've talked about it some, talked about that it is a capability that we could introduce but what has kind of failed to emerge in the conversations is a really key use case to drive it. So it's not that it can't be done, it's that nobody has come along and said, here's my use case. I really, really need group signature functionality in order to enable it. Gotcha. Yeah, that makes perfect sense. But pairings-based signatures, you can typically get this extra functionality without a lot of extra effort. It's just a matter of people needing it. So I guess we have a minefield question that I will defer to the Europeans on the panel. So what is the best way to implement business rules in chain codes that need to support the GDPR model? Marta or Angela, would you like to tackle this question? Marta, please. No, I just replied actually with a paper. It would be easier if the box that says turn your mic on didn't copy my icon icon. So I was saying, I think, Angela, you're the best person to answer that and I would actually love to hear your summary of that because it is definitely something that is coming up a lot. In information blockchain space especially. Yeah. So definitely what I can say that I can point, I posted a link in reply to a paper written by accepted the conference, a peer reviewed paper, written by colleagues on mine from Haifa and they go in lots of details about this right to be forgotten, which is in a sense GDPR is also is giving to any person or is recognizing as a right for any person. So I just refer to that paper. There are a lot of many details written there. There was also a proposal to bring this to fabric actually to simplify the life of developer. If I understand the question, it's more from a technical. So how do we write this in practice? Unfortunately, that's another topic where we really would like to have the community helping us in delivering this GDPR support for fabric. It would be really fantastic. Otherwise, you know, it's like saying that we are implementing the same solution again and again and again and again, which is essentially based on the current stage with the private data collection. So you are posting only hashes on the ledger that are not brute-forceable. So given the hash, if you don't know anything else, you cannot really know what's behind. In a sense, you can consider the hash as a commitment, a hiding commitment in this sense. This alone is not enough because even now the private information are stored somewhere and even somewhere you have to give a possibility to erase this information. Keep in mind that there is no way or definitely not a cryptographic way. And I think this would be a physical problem. How can I prove that I really deleted the something? And indeed, I think GDPR is only saying that certain pieces of information are not accessible anymore. So that's one of the other goals. So I'd like to take this from the Indy perspective. We've struggled with this a little bit as well. The first thing that Indy did and Sovereign in particular, which uses Indy, is they avoid putting people's information on the chain in the first place. That's like number one rule. If it's not there, there's no need to have anybody asked to get rid of it. And then the second, the mechanism that they were looking at introducing, should it become necessary to do so, is actually because the Indy is a permissioned network, it's possible for the nodes, if the node validators, it's possible for the node validators to be able to say, oh, I no longer have that information. It's on the chain, but it's not retrievable anymore in any sort of secure or verifiable way. And so that's kind of a similar approach to what Dr. Piccaro was saying. Different chain. It is quite interesting, this whole right to revoke or right to delete data. I've always been of the opinion that at least the fact that you can record and prove that you requested it in a reliable way is better than the system without blockchain where you can just claim it, but it's claim against claim. I'm wondering, do you know, because I actually don't, how does the forward secrecy that Hart was talking about, how does that impact GDPR? If we say, well, today the data is secure, because it's encrypted and hashed and everything, but in five years' time, all of those and it is not private anymore. Is that something that the regulation takes into account? I would say that it's a killer. If you start posting ciphertext on the ledger, that will kill you, that's for sure, because the ciphertext, no matter what, even if you get forward security, I mean, the past will be lost. So that's a problem. So you should not put ciphertext on the ledger if you want this kind of right. Indeed, there is also another problem. I think this, I heard this the first time I was dealing with the banking world. A bank, so there are certain legal parties that if they are storing ciphertext, they are responsible to be able to decrypt them. So they must know the secret key to decrypt those ciphertexts. But if now anyone is starting pushing ciphertext on the ledger, I mean, how can I have, I don't have all these keys to decrypt. So that's a no-no. Ciphertext on the ledger is just a no for many days. Once the ciphertexts are out, then of course this is a different story. So if a hacker is able to penetrate your system, then of course the past is lost. What you could do actually, it's instead of storing the ciphertext in a single place, you might start secret sharing in the ciphertext. So you know, you put pieces, it's like breaking the ciphertext in multiple pieces. And yeah, you start spreading the ciphertext in multiple places. So in such a way a hacker, even if he breaks a few servers, he will not be able to reconstruct not even the ciphertext. Yeah, to go technical basically, to adhere to sort of all these privacy rules, you can view sort of hashes and other things as commitments to things. So if I put a hash on a blockchain, it's sort of a commitment to the blockchain. And commitments, well in the ideal world, they're either computationally hiding and statistically binding, or statistically hiding and computationally binding. Now I'm not sure how much sense that makes to non-cryptographers, but basically what that means is if I have like a message or something, and then I pad it with a bunch of random stuff, and then I hash it, well I can view that hash value as sort of a proof of the original message due to the collision resistance of the original hash function. But if someone breaks the hash function, then they can't come up with my message because they're just too many possible messages. It's information theoretically hiding. So there are, I think there are ways around this, but as Angelo points out, you can't store ciphertext on the blockchain if you're worried about forward secrecy and privacy loss. So speaking of Angelo, there are some zero-knowledge questions for you. Is there any advantage to use interactive ZKPs over Nizix and consortium blockchains? And what about setting up the trust infrastructure between parties? Brent, you can also jump in here if you want. Yeah, very interesting. I would say it very depends on the blockchain system. So as I replied in general, it's a no in the sense that the verification, if you take Ethereum, the verification cannot happen interactively because it's like saying that the entire network should connect to the prover and interact in order to verify if a zero-knowledge proof is correct or not. So in blockchains like Ethereum that use the paradigm order and then execute, you can only use Nizix, so non-interactive zero-knowledge. But in fabric, actually we use a complete different paradigm. We instead say you first execute, then you order and then you validate. So during the execution phase, you can say, okay, now there are a bunch of servers that what we call endorsers that will verify the zero-knowledge proof possibly even in an interactive way. And then the rest of the network will trust these endorsers via the endorsement policy in having done this thing. So in a more in fabric, even interactive zero-knowledge proofs are possible if this brings some advantage, but it remains to be seen. Non-interactive zero-knowledge proof, especially when it's a snark, it's a succinct, it's very efficient to verify. So the burden of interaction, why should they set up? Set up is also another very dramatic thing. Luckily there are now non-interactive zero-knowledge proof systems that do not require a trusted setup. You just have to pick a hash function and then you go with it. So these are very good. And even some that are updatable. So once you publish the public parameters, this can be updated continuously. So a lot of progress on this. I wouldn't say that this is an issue as it was a few years ago. Thanks. So Brent, we have a question about threshold signatures. Would you like to answer this? I can repeat your answers shortly. Yes, we're working on this. Or by we, I mean, Mike Water is working on this. It's definitely something that we see as being valuable. There are use cases that are asking for it and requiring that require threshold signatures. So what we are looking to build in ERSA is a capability to essentially thresholdize any of the signature schemes that we already have. So yeah, short answer, yes, longer answer. Come to the ERSA meetings to talk to us about it. We'd love to have info. It's a good point. ERSA meetings are open to everyone. You can just show up. You don't have to speak. You can just lurk if you want. So feel free to join. Angelo, do you want to address the question on the difference between the fabric tokens? Yeah, I was just replying. That one, the sample, the sample was published there. It was just really a specific example of how you could implement tokens there. The token SDK that we are now proposing is actually has this beautiful two-layer API that gives to the developer an abstraction that is agnostic to the actual implementation of the token on top of Fabio. What does it mean, this in practice, that you can switch the technology that you use behind so either zero-knowledge or... Actually, when I say zero-knowledge, there are many, many zero-knowledge proof systems that can be used. So you can change the zero-knowledge proof system that you use or you can even just use a plain version of the tokens if you don't need any progress. Or in certain settings, you might need to have auditing in others, you don't need to have auditing. So the token SDK brings all this knowledge in a single place, in a systemized way for the developers to quickly develop token applications for Fabio. So that I would say is the... And also the interesting thing is that the technology that we are deploying, we are open-sourcing for the zero-knowledge part is also... It's in a paper that is peer-reviewed. Anyone can look, I posted also the link here. Just as a side, that's the technology that we are going to open-source. Thanks a lot. So I'm assuming VCs is verifiable credentials here and not verifiable computation. But Dan Yamamoto asks, is there any work of provable security of VCs? Can we just apply anonymous credential models, game-based or UC-based to evaluate it? Brent, would you like to take this question? Yeah, I can try. So for VCs in particular, I don't know of any provable security work happening right now. For the most part, I believe you can just apply the anonymous credential models for those signatures that are applicable to those models. One of the things about a verifiable credential is some of them use DVS+, some of them use CL signatures, some of them use E25519 signatures and aren't selectively disposable or zero-knowledge proof capable signatures at all. And so for the most part, there are the anonymous credential models, I believe apply something that would be worth examining is the impact that introducing JSON-LD aspects into the data model itself might affect the provable security there. So it's an open question. It's something we're interested in exploring and folks need to look at. I think that the UC model is a great model to look at blockchain in if you're familiar with what it is. Just because, well, we need... Blockchains are never used in a vacuum. We need to compose constantly different cryptographic protocols. So it's very useful. The only issue is that UC proofs are catastrophically long and complicated. If you look at any of these UC for blockchain papers, they are literally hundreds of pages long and full of incredibly complicated proofs. So that's probably why we haven't seen any, to my knowledge, UC for verifiable credentials yet. Just... I can only imagine the paper length. So I guess we have another question. Arnab asks any thoughts on bringing SMPTC techniques using fabric private data? Do you want to answer that, Angelo? Yeah, I just posted another link to a paper that we published a few... I think 2019 or 2018 where we show that it's actually an application to the finance, the financial world is the initial public offering. So how do we run the initial public offering with full security, with full privacy? Privacy with respect to the orders of the bidders, of the investors. For example, they might not want to trust an investment bank to collect the orders and then to decide the price of the new stocks. So definitely yes, and there's no need for fabric private data, actually. What is interesting is that at that time we didn't have yet another piece of software that we have already open source a few days ago. We just open source that we called Fabric Smart Client that will give you the ability to implement these kind of things very easily on top of Fabric. Thanks for posting the link. I think everyone appreciates the posting of the papers and links for all of the relevant questions that are being asked. So I guess I think we've answered all of the questions in chat at this point, so please, everyone, feel free to ask... I see one. Did we answer the NP complete problems? No, I don't think you did. I replied to that one. But Angela replied. Actually, I wouldn't... It's not like anymore... I wouldn't go that far. You don't need to look at the NP complete problems or you look at it. It's just a complication that we don't need to go into this kind of data. It's just enough to know that there are general purpose, zero-knowledge proof systems that can generate zero-knowledge proof for essentially any statement. Then how they do that, it's very technical. It doesn't really matter. What matters actually, maybe that's also... I guess it's important also for the different industries that might want to use zero-knowledge technology and in particular the finance space is to come up with the standardization of zero-knowledge proof. Because in decay proof, the best from the decay proof standard, they are definitely doing a great work to push in having a standardization of the primitives of the assumptions, the cryptographic assumptions, how the proofs are encoded, how do we encode the statements that we are proving? That's definitely something that is very interesting. And also, there is also another aspect that I think it's not a minor, but we must have a way... For example, if we talk about the UTXO token and let's suppose the talis wants to spend a token, most of the time in an enterprise space, the secret key that talis might use to spend this token will be in an HSM. So we must have also zero-knowledge proofs or statements that are friendly with the HSM. Therefore, again, HSM is hardware, it's very difficult to deploy new cryptographic signature schemes on HSM. So we better be compatible with existing signature scheme like ADDSA, that's really actually a very good scheme, very secure, very powerful, very compatible also with HSM and with the most advanced zero-knowledge proof system that we are aware of. So if you use the HSM, you get compatibility with HSM, full power at the zero-knowledge space, it's a win-win, I would say. Can I ask a question? Sure. So I was wondering what do you think about the kind of development of building HSMs in the cloud or whatever you want to call them, but moving from the hardware part of HSMs in order to kind of catch up with the cloud development? Maybe my colleagues, my colleagues are enduring a better aspect than all the possible scenarios. I don't really know what's the security, what's the threat model there. I think there is a threat model where essentially even someone who has root access to the machine cannot access the HSM, so they are kind of in an isolated environment. So now it's all about trust, right? You buy, you are buying this service from a cloud provider, you are trusting that they are not cheating or they are really delivering on these premises. Anyway, no matter what, if you don't trust a single provider, you can always spread your secret keys. I think there are in the HSM space protocols to have keys dispersed in multiple HSMs and then they come together, they speak to each other and then they generate a signature. But again, it's always a trade-off between security and performance because then to generate a signature, if you start to interact, you don't generate a signature, you take more time. So again, it's a matter of compromises. So Mike, we have you back. Can you actually hear me though? Yeah, it's great. Oh, good. We have some questions for you. So do you want to talk about the work being done in URSA on threshold signatures? Yeah, so I'm working on implementing all the threshold, the major signature types like the Bitcoin curve, ED2519 and BLS. So with both a distributed key gen and distributed signing. And that's mostly for the clients I work for. That's what they're interested in. And I know that this is a major interest to blockchains, right? And so we've looked at different HSMs. The best one that I've seen that I'd like to use, since you were on that topic, Angelo, is Amazon's new Nitro enclaves. It's similar to Intel SGX, but a heck of a lot simpler to write code for. So that's what we're using. There's no network. There's no persistence. And the memory gets wiped every time the thing starts and stops, which is really nice. But that also means we have that problem of we can't persist the keys, right? We can't inject them. And so we're doing all sorts of techniques with Shamir's secret sharing to talk directly to the enclave, inject it over SSL, and then the keys are set. But then we're trying to do distributed key gen signing versus doing these HSMs like cloud HSMs or Azure's secret computing. I can't remember the exact name, but you get the point. And take your pick, right? So Azure's based on Intel SGX. Amazon's is their own proprietary thing, but it's pretty simple to use. And then they've also got cloud HSMs and then Google's got their secure compute. So I mean, it's all over the place. Yeah. Yeah, interesting. Great. If anyone else has any more questions, please feel free to ask. We're running up on our time. We only have about 10 more minutes left. I would like to emphasize that everyone on this panel is relatively publicly available. And you can ask us more crypto questions or whatever questions you want. Maybe you're interested in Brent's basement. But you can ask whatever questions you want on the public forums. So yes, please, you know, don't be shy in the future even if you didn't ask your questions today. So I guess I'd like to close with sort of some forward-looking questions. What do you all on this panel think we need to do going forward for sort of both cryptographic functionalities on blockchain and general cryptographic and security safety on blockchain? What should we be looking to do in the world of cryptography? Anyone can take this. I can start. I'll start on the self-side. I think that we are still lagging in thinking around blockchain. When you build out a blockchain consortium or a consortium in blockchain, how do you figure out the interactions between participants? How do you ensure that people feel comfortable and understand what it means to use a blockchain? Also, in permissioned space, there is not much thinking about the on-chain governance versus off-chain governance that usually falls under the off-chain governance and then it's not really a blockchain. So I think these are the things in permissioned space that need kind of analysing and looking into. In general, I think that we are really still very much behind usability. There is too much that people need to understand in order to build their systems and even to use them. And I'm seeing that actually there's more even in DeFi than in permissioned space. Unfortunately, people are losing a lot of money because they don't really understand. I like to say that we try to say that we democratised finance space but it's like giving people knives and not telling them to point them outwards. So they just mostly end up stabbing themselves. Awesome, yeah, that makes a lot of sense. Does anyone else have any more comments? But look, from my point of view, I like a lot competition. I think we have to foster competition in this space. Blockchain, first of all, is giving us a huge opportunity to deploy some crypto technology that was considered very fancy, very fancy. Even though, let me say, even threshold crypto, I think it has more than 40 years. So it's a very well-established, at least in the academia and academia, it's a very well-established technique. Though there is a point, and I totally agree with Marfan this, even threshold is not so usable in practice. It's not so obvious to deploy. And the same thing is for zero knowledge. While understood primitive from a theoretical point of view, you always forget that there are the small details that actually when you go and deploy, you start asking yourself, ah, but where is this? Where is this? How do I deploy this? Ah, but this becomes now the weakest point in my chain of security. What do I do here? So you see, there are very problems. So we have to foster this competition. I hope that Hyperledger will push stronger and stronger on this tool to set the bar very high on the projects that are coming in. To ask the projects, hey, come with real solution that people can really use and can make a difference. The biggest problem with threshold is, is not necessarily deployability, but practicality. You know, yeah, it's great to do five out of 15, but how many, when it actually comes down to it, are you actually going to wait for five people to sit there and participate? No, everybody wants their things now, so what is everybody doing? Two of two, for example, right? No one wants to go higher than that because it takes too long, or they want their stuff now. So I agree with you. Yeah, practicality is a big issue. There's a tendency in the cryptographic community at academia anyway to say something is practical if it can run on a computer the size of the galaxy. But that's pretty far from the truth. You know, one of the things I am excited about is the potential for sort of one-off multi-party computations to be used in a lot of blockchain applications. There are a lot of things you only need to do once, and maybe you don't care if they're super efficient. So that's sort of something I think will become popular in the future. So I guess with only a couple of minutes left, does anyone have any final words or how to get in touch with you or how to answer more questions or any sort of tips like that for the audience? Panelists, anything? We should definitely point, folks, to the ERSA channel on Rocket Chat. That hasn't been done, and I don't know if we're having a meeting this week, but in two weeks from today, at least there will be an ERSA meeting. Folks should feel free to come to bring your questions there. We love sitting around and talking about crypto stuff. That's pretty much why we keep going to the ERSA meetings. So you're welcome to join us there. And yeah, I'm not sure. What else should we say? There's a bunch of other security talks over the next two days, and I have to be sure to check them out, including, actually, I just checked the schedule, and there is a GDPR and fabric talk. So even then... Awesome. I posted the link to the ERSA chat channel. Everyone here should feel free to post and use that or the mailing list, or come to the meetings, where, as Brent said, we do like talking about, you know, random problems in cryptography. So even if... Well, we're like anyone else. We like procrastinating real work to talk about fun crypto problems. So... Well, thank you so much. Yeah, thank you. Thanks to all the panelists. Thanks for participating. Thanks to the audience for all of the questions. I hope you, you know, learned at least a little something. And yeah, please feel free to follow up with anyone. I mean, we're all, I think, publicly available on Rocket Chat. So if you even want to, you know, message us individually, that's totally fine. So, yes. Thank you all for your time. If there are PhD students, please apply to IBM. Come, we have an internship. Nice. Definitely. Yeah. IBM Zurich is a great group. So... All right. All right. Well, thanks. Thanks to everybody. And have a great rest of your HGF. You too. Thanks, Hart. Thank you, Hall.