 I'm a developer here in Taller. I've been working here for like two years ago. I wanted to show you something that I built for a talk. You might know Taller because he's already been presented here in this kind of events. But if you don't, you want to remember that there is an exchange where we draw money with our wallet that we can install as a web extension or as a mobile software here as Android. And we can use the wallet to withdraw money and pay to our merchant that has a back office installed. And the merchant can do the deposit of the money. And the most nice feature that it has is it is completely private. I have privacy for the one who uses the wallet. So not even the exchange or the merchant can stop the people from using the money. It is not built using cryptocurrency. It's a digital payment system that is used token-based payment. What I built here is a device that uses a cash validator and converts the signal to USB serial. And there is a server that listens to this information. So whenever I send money through here, it will say, OK, you have $20 or $20 to pick up. And then we can scan it using our web extension or using the mobile device to fill up our wallet with the money. Essentially, what we are trying to do here is when you go to buy some coins to play in an arcade machine, so after having the money in the wallet, I can scan another QR code that will talk to the payment listener, and it will send information to the arcade machine to play the game. So we can have this. Let me, for example, show you. This is the arcade-taller pickup. There is no money yet. I'm going to start it again. So if I reload, there is no money. And then I'm going to insert here some money. It is validating the cash. So if I send some dollars here, it won't read it. I'm going back. So now the server has 20 bucks. If I go to this page, it will redirect me to collect the tip. And when I open the wallet, you see there, it has detected that this page has a taller tipping protocol. So when I open the page, the wallet will get the information, and I will be able to accept the tipping from the merchant. Right now, I don't have any balance, but when I accept the tip here, you will see my money in the wallet. After picking up the money, there is no more money here in the server. And then I can go to pay. I can go to pay on a machine. I can scan a QR code or go to the URL. I'm going to show you here through the web extension. I'm going to the Arcade Teller pay. I'm going to show me another QR code to make the payment. And when I use my wallet to pay, it will present all the information to be paid. As you can see, it's really fast. And after paying, it should be running. Ha! I forgot to run the notification. Then it started again. So what I have here is a little calculator that is always watching the money pick it up from the machine. And then another service here that is checking the merchant backend where the payment is made. And after the complete payment, it runs the game. So that's it. That's the talk. Hope you like it. Does anyone have any questions at all? So I've got one. So with security in the system, with the QR codes, is there any extra security on top of that? Or do you have a password to access the wallet? No, the idea here is that the exchange is the one who holds assets or holds the money. And it's the one who's printing the coins to the wallet. So when the wallet goes to the exchange as for the money, the money is already saved into the wallet in the world station or in my phone. So it's more like cash. It's not that you have an account somewhere and you need your password or your account to save your money there. So if your phone died, would your money die? Exactly. You have a gap. That's why we have this feature here, to the backup of your wallet. And yes, definitely. If you lost your money in the real world, if you lost your wallet in the real world, you also lost your money. You gave the example of an arcade. Has it been used in that scenario? Or what scenarios has it really been used? Well, this is recently built just like two weeks ago. So, but that's the idea. That's the idea. You can use it in the arcade system. And as you saw, it's really fast. So there is no long transaction delay or long transaction cost because it's a service running in a server and not anymore. There is no proof of work or proof of anything. What made you design the system? What was your thinking when you invented it? What I was thinking, using like this, like fast payments. What made you come up with it? Just the speed? Was that the idea? Yeah, that's just a demonstration. Sorry, anyone else got any questions or anything? Was there a follow on part for the talk? Part two, you're both on the same project, is that right? No, not well. Yes, also, but not this time. Oh, OK. So your friends, you know each other? Yes. Oh, OK, fine, cool. Sorry. Thanks, we'll just do a quick changeover. I meant to ask, actually, those money detection machines, can you hack those? Are there ways to get around those where they've got 20 years and you haven't? Well, how do they work, actually? What? How do those actually work, detecting the money? Well, the cash machines. Yes. He'll probably turn it off in the back. It's green light, isn't it? What's your name? Sorry, Christian. OK, fine, great. Oh, that's coming up, so that's all the top of the screen. So you're set. Great. We'll pass on to Christian to tell us more on the same related subjects. So take it away. Thanks. Well, oh, wait for this week. Can we turn the microphone on or back? OK, well, the last question we had was, OK, what if you lose your wallet? And then his answer was, you have a backup, right? And then the next question is, well, if you have a backup, how do you encrypt your backup? Right? And then the next question is, OK, I encrypt your backup as a key, and what if you lose your key? That's my talk. So, and I'm going to give you a demonstration of GNU Anastasis, which is a rather new GNU package. And so this is the idea. You start by identifying yourself. And before you can identify yourself, you have to tell me who you are, where you live, because we're going to ask you a bunch of very personal questions, because this is a privacy project. I know, I know. It doesn't make sense, right? Well, the personal information we ask you for is going to stay on your computer. And we're going to use this to derive an identity and encrypt information with it. Not the main information, but some information. Now, for this demonstration, I'm going to live in Testland. And, well, whatever, my name is going to be Max or something like that. And in Testland, well, usually, we would ask for your social security number, your text by identification number, stuff like that. In Testland, we're going to ask for your prime number, two, because it's an odd one, and your square number. I picked one. Is that OK? So, again, think of this being high entropy information that not everybody has, because we kind of have two adversary models, one that no stuff about you and one who doesn't. And the adversary who doesn't know all of this information about you has no chance of getting anything. Anyway, so the next step is making sure, OK, we don't forget this, I am sure, is to configure authentication methods. And so you can pick the usual one, send me an SMS with a pin code, send me an email, use TOTP. Is this your phone? Does it have TOTP readers on it? Well, I can't unlock it anyway. He trusts me very well. He left his phone. And you can also send physical mail, but I'm going to stick to security questions, simply because the rest is a bit more involved. And I'm going to have very simple security questions here. First question, first answer. Don't use those. Now, the system requires me to put in multiple factors for authentication, but I can do the same ones multiple times. So I'm going to be, again, very creative. Q2A2, right? I maybe do a third one for good measure. Yeah, I really can't type with this microphone in my hand, so I'm going to keep it very short. OK, three top security questions, I recommend highly. The next thing is you, the system will distribute your key shares across multiple providers. And now here you can kind of configure your recovery policy. So by default, if you are putting three, it suggests two out of three. But you can also say, no, I want all three or one out of three. And you can also specify at which providers they're going to be stored. In this case, the providers I've got running for the demonstration purposes are the data loss incorporations. Again, in practice, we have actual providers that run the system in various locations and various jurisdictions. I'm happy with this default policy for now. Now I can name my secret, whatever, mch. What is the good secret for mch? I don't know, 2022? Not very creative, OK? And now I've made my backup. And again, the different companies have stored different shares of the secret. None of them has access to everything. And they are additionally encrypted with information derived by my identity, which also serves as an account identifier. Now, if I go and say, I've forgotten what year it is, I can recover the secret. Again, I have to say where I am, because I didn't restart the application test remembered, at least this form. Otherwise, you have to reenter it, of course. Now you can get a list of all the things you've backed up at all of these providers. It basically went already in the background and asked all of these providers, hey, do you have backups for this user identity? I can pick based on the secret name, only have one here, which one to recover. Now I have to solve the security puzzles. And it basically tells me, we've got three policies, solve one of them. So for example, I could say, OK, I can solve this one, A1. And now I've solved parts for these two policies. Or I could solve Q3, A2. Oh, that was wrong, right? Now, if I do this too many times, it actually locks me out. Correct answer was A3. And it has reassembled the secret, 2022. So multi-party backup, the providers learn very little, effectively only actually things like your email address, your SMS number, during recovery, this free software available from GNU. Thank you. Does anyone have any questions there? So, oh, yes, we do have some. Sorry, right. So for others that work with phones and mail recovery, is it like external party, phone and email and maybe snail mail? Is there an external party that you need to rely on? Yeah, all of the key shares are always stored at a provider. And that provider will send you the email or the SMS. We also have another method implemented where you have to send me money. That's the business model. You authenticate by being able to send from your bank account to me, 1 euro. Then I believe it's you with the right wire subject. But of course, you rely on email providers or phone system. But in the case of security question or TOTP, of course, not really. What kind of encryption is used at these data providers? There's multiple layers of symmetric encryption. The first one is basically use your user identity to encrypt both the key share that you have, which, again, is itself used to encrypt part of the key that is actually the secret that's actually stored. Then we have another layer around it which encrypts the authentication information so that that only becomes available during recovery for the provider. But it's mostly ASGCM encryption, symmetric encryption. We use, of course, I think it's the S-crypt, so PBKDF hash function to make it more expensive. And we hash the user attributes. But there is no asymmetric encryption required here. The only asymmetric part is we sign the uploads. So if you upload multiple secrets, we know it's coming from the right accounts, so to speak. Does that answer your question? Somebody have a question over here. Same data. Do each of these data providers have the same data? No. They all have completely different data. Each provider has a public salt. And so we even make sure that when we re-identify the account, the accounts look different at the different providers. And they have different key shares. So of course, also the things that they're storing is completely different. But they can't even tell that they're serving the same user, except if they log IP addresses and say, oh, it's the same guy who's coming from the same address. I have a question, too. Could you technically design the encryption in a way so that the password is never known by the provider and just you use the answer as the decryption key? And if the output has the right format, then technically the provider would never have to know the answer. He doesn't. So what we do all of this, so in fact, the password is hashed in two ways. One is used to also decrypt the decryption key locally. And the provider doesn't learn that. And the other one is the password is hashed with a strong salt. So it's against brute forcing. And then that hashed with a strong salt hash is sent to the provider. So the provider never learns the actual passphrase. But good question. I actually have a question that goes in the same direction. Is that just simply a white paper detailing all that linked? There is a bachelor's thesis detailing all of that, which won the Information Security Society Award of Switzerland in 2021. So bachelor's thesis, not a white paper. OK, thank you. And how are you going to find it? You would find the bachelor's thesis in the Git repository and on anastasis.lu. It should be linked somewhere. OK, hopefully I find it. Thanks. I'll check afterwards. So, cool. Does somebody have a question on the side? Or has that been answered? Oh, yes, here we are. So currently you have about six providers where to store information or? Currently we have three providers in operation. A fourth provider is in the I'm setting it up but taking some time. We have six different authentication methods implemented, five of which are operation. The sixth one is waiting for the bank to give us the account details so we can actually do the bank authentication. It works in a test setup but not in production at the sixth authentication method. But we have currently three providers. If you're interested in running another one, please contact me. What about a blockchain, like Bitcoin? What, a blockchain? Why would you need a blockchain for this? It's all about storing data somewhere, right? No, because you don't want the data to be necessarily public. Now, in our case, if the provider were compromised and the provider's database finds itself on the internet, you're still in luck because he's only having key shares. And it's additionally encrypted. But you still don't want this data to be public because if I compromise enough providers, which hopefully is difficult enough because there are enough of them around the planet and maybe they don't know everything about me, but basically I can bypass the authentication if I compromise the provider. So this data should not be public that's sort of the providers. So you are dependent on the provider adhering to some form of security? We are adhering to a sufficient subset of the providers being both available and not disclosing their information. And against a strong adversary who knows your name, your social security number and the other information in the first screen. Clear, thank you. So if a few providers fail, is there a risk that the system loses your passwords? Well, the system doesn't have your password so you can't lose your passwords. But it might lose your stored secrets but it depends on your policy, right? If you decided any one of the providers is enough, then only one provider needs to survive. If you said I've distributed to three providers and I need information from all three, then one of them failing and you're done. But it's freely configurable. Actually I think I just answered my question. I was gonna ask if it made any sense to have anything air-gapped at the providers but I guess the answer is no, they can just use a data diode or something internally. Yeah, I think as a provider you probably want to also serve the customers when they are really in urgent need for the data quickly and I don't think there's an air-gap need here, no? I noticed there was an expiry date on some of the secrets. Why would you want that? There's an expiry date, mostly because the providers might not wanna commit to storing things forever and we actually have built the toddler system as a payment system into it so the providers could ask for your money to store stuff and if you promise to store stuff forever, well, the price would have to be infinite, right? But if you say I'm gonna store your key shares for five years, you can calculate how much it's gonna cost. Of course you'll be wrong with the inflation but at least you have a chance of making a business, of running the service. And at the same time I also go and say well, we don't have a deletion capability because we said well, if somebody could delete my key shares that might also be just as bad as keeping them, right? So, but having an expiration where you tell the user upfront, this will be kept for five years and then you might wanna do a re-upload and partially you might not have the same phone number, you might not have the same physical address so your authentication methods might change so it's a good thing to tell users, don't do the backup once and forget about it for the rest of your life. The providers of holding the secrets, if one goes out of business or goes bust, is it like a RAID system where you can reallocate that to another one, that rebuilds elsewhere automatically? If the provider is willing to hand over his database to another operator, then it would be possible. If one was compromised or... If, again, compromise has two different ways. If he loses the data, then you can't hand it over to somebody else, right? If the data is public, well, you can keep operating and give it to the legitimate users and you just have to hope that not enough are compromised for your actual secrets to become known. And is the system in full production now? Is it something that people can use or is it just in development right now? We believe it can be used, but we're in the test phase because we're still playing around with the user attributes that we're collecting for different countries, the validations and getting some, let's say, initial production experience. So we don't recommend using it production, we recommend trying it out and telling us what's wrong. So people can sign up, try it, be beat assessors. It already works. We have also a web user interface that you can use. We have the GTK user interface. So it works, but it just works, right? I said we've just made it work. And so maybe let's not do the $5 billion dollar Bitcoin wallet in this tomorrow. That's the only way of keeping it secret. I would be a bit worried. But you can use it. There are not really any significant known bugs. Cool, great. Thank you very much, everyone. So, well, thank you for the talk. So with the lightning talks, we only had the one or the two talks today. So if anyone, does anyone fancy doing another talk or should I pick on someone randomly to do a talk? Ah, you fancy doing a talk? Super, why not? Cool. Oh, is that one on? Is that microphone on? Is this on? Can we turn it back on again? So, yeah. My name's Jeff Burgess. Oh, sorry. Can we have the, speak of microphone on, please? Try it, try it. Oh, it's working, okay, yeah. My name's Jeff Burgess. I work on various things. I actually have worked on taller before. That's why I came and found them. But the, so there's a, so taller uses these blind signatures. This is the thing that you're hearing about. It's sort of the person who signs the thing doesn't know where they're signing, which is an interesting problem, which is a useful thing. And there's a number of things, well, maybe I don't want to run off in that direction, but there's a number of things that people have done with blind signatures where you can sort of issue them once and then redeem them many times, things like this. So what I want to tell you about is an interesting construction that we came out, came up with for doing things at my current job. It's what we're calling a ring VRF. So a VRF stands for verifiable random function. It's, everybody here, people here kind of know what a hash function does or what a MAC is. So it's like you, it's a function that we believe it's kind of a random function. And you have a key to it and when you put something into the function, then the thing that pops out the other side looks fairly random, you know. And this key defines which function from this family of functions you're taking. Okay. So that's a symmetric cryptographic construction and you can have an asymmetric one where this is a public key system. So what this means is that if it's my function, if I know the secret, then I can evaluate the function and nobody else can. And, but also there's a signature-like component which means I can sign that I can produce a signature that proves a particular evaluation of this function and it doesn't leak anything about any other evaluations. Okay. Kind of an interesting kind of construction. We use them a lot in, they're used a lot in certain kinds of distributed systems, fancy new blockchains, proof of stake things. They're also used in, they should be being used in DNSSEC but they're not yet. It's been around for a while, that proposal. Anyway, the, okay. So this thing is these guys are signatures. You sign something with them. There's another, there's also another kind of signature called a ring signature which is that I have a set of people and I just prove that one of the guys in the set signed. And there's, okay, there's a bunch of different types of ring signatures, really, really lots of them. And, but one of them, people here have probably heard of Zcash. So Zcash is a kind of a funky ring signature where the ring is all of the keys that have appeared in the chain in the past. That's a way to think about it. And so it has this way, it keeps growing this ring and then when you sign with one of these UTXO keys you can spend the money. Okay. So what we needed for something was, we needed this ring VRF for a certain protocol we were building. And so what is it? It's just a ring signature that's also a VRF. So you sign, so each key, each real key defines some pseudo random function and there's a ring which we can keep growing and you can sign something with it with one of the keys in the ring. And what that does is that it just proves that one of the functions in the, this is the evaluation of one of the functions in the ring. Pretty handy. Okay. So where did the idea for this thing came from? It actually came from this, from a guide AP, I'm the first person who came up with the term ring VRF but it came from some work by Brian the idea for doing this came from some work by Brian Ford at EPFL which says, which basically he wants to have an identity system where you have IDs that are issued, either what he wants to do it in a very anarchist way but you could also have them just be government issued. So you have these IDs that are say government issued and what you do is when you swipe you tap your card on something, it evaluates this pseudorandom function and it proves to the thing where you're tapping your card that you have evaluated this function correctly. Now, okay, what's that useful for? Well, it means like you have a very ephemeral ID. I can say, look, my identity for getting into this club today is this or look, my identity on your particular website, I put in Twitter or whatever into the random function or my ID that pops out the other side is my identity on Twitter. So what this proves is that there's only one me on Twitter or there's only one me going into this club today or whatever. So there's another thing that's very useful that you can do with this, it is identity. You can use it for rationing. So if you, in France right now we have a mustard shortage, we're about to have a lot of fuel shortages in Europe. You can literally have an EU ration card which would say, here, look, I'm an EU resident. I wanna buy this thing today and here's my right to buy mustard today and you can do it on, you can do it by month, you can do it a number of times in a day, whatever, they're all unlinkable. Anyway, there's a variety of nifty tricks you can play with this primitive. Another trick you can play with, a lot of these VRF protocols can be represented as games. You can also play cards against humanity but that's another, in a decentralized way but that's another thing I'll talk about another time. Ah. So we got some questions. I have just a short question. You said that you can, with a hash, definitely prove that someone, or you can authenticate them as themselves but isn't it technically possible? I mean it doesn't fit for the analogy but that a hash collision could cause two people appearing like the same person? Yeah, well this is, these hashes are large so. So there are 256 bits but the elliptic curve only really has 128 bits of security. If somebody wanted to create a collision by designing their keys, they could do it but you can't really do it with only 128 bits of security but you can't really break that. So you can, even if you wanted to, to have really different keys that collided, you can't. Oh, we'll go to a question over here as well. Hi, can you just talk a bit about the R in VRF, like verifiable randomness? Like can you talk about an application where that randomness is important and where it comes from? So a lot, okay a lot of times when we're using like in a cryptographic protocol when we're describing a hash function we use what's called a PRF which stands for pseudo random function and the definition is basically that we have a family of functions and we imagine that we're picking one at random and we, and then we make certain statements about this. Okay, VRF is a signature that, I mean there's a formal definition I can drag out but it's a signature that essentially it has these pseudo randomness properties and it also also has this fact that you can, that the public key uniquely determines which PRF is running or which element of the pseudo random function family is being picked and that, and then the signature part is you're proving the evaluation of this function. Did that make sense? Yeah, but where do you get the randomness from? Like can the person you approve it? The randomness always has to be coming, there always has to be something in the, well really the randomness is coming from the key but which is picking which function in this random, this family of random functions but sorry for trying to leave for this way in the cryptographic language a bit but really your, the real randomness is the key so which is why I can do something like Twitter on the 14th of July as my input and claim that the output that comes out is random is because the key is really the source of the randomness. However, there are a number of applications including this Cards Against Humanity thing that I was talking about where you, it's that's not enough, you also need the, so for the identity application that's enough, there's a number of other applications where you need the randomness, you actually need some randomness coming in on the things so in particular if you wanted to, any time where you're afraid of the users picking their key to brute force something then you need the input to be random and you need it to be made up afterwards and so for example if you paid any attention proof of strike blockchains or vice-prouse uses that and they have to have the randomness that goes to the input to the thing come after all of the keys said hey we're staking. Thanks. I've got a question again. So do you see mainstream password managers embodying some of this technology at a time? So there's, so VRS there's a construct, a lot of the PAKE app if you've heard of these PAKE like password authenticated key so the thing I'm talking about wouldn't really be for password managers, I haven't thought about that. There's a, when you talk about PAKE systems which is like password authenticated key exchanges they tend to use a primitive that is somewhat similar to this but a little bit different. Great, thanks. So we've got a couple of announcements so. Yeah, thank you very much. And that's certainly very deserved. Hi, I'm Torolf, I'm one of the guys who are actually running the lightning talks and we are actually looking for speakers. So if you've got a topic then you think that's interesting, you've got unfinished research that you want to share or talk about, think about it. Getting up here is not really difficult, you can or you don't have to have slides so just get up here and talk. I don't have any slides with the name just Google Lightning Talks, MCH, you'll find the page where you can submit all the information or you can find me or some of the other people around the Garafel Village, thank you. Yeah, so I was asked to do the ending of this, I'm the co-herald of him so I have a few things to ask you, first of all is to drink a lot of water but I think he told you that already. The second thing is please consider becoming an angel, like we too are angels, we're doing this right now and any angel who does a shift can get an angel shirt that's not an angel shirt as you can probably see and angels who do parking or trash, they will get a patch, it's probably not that well visible, that's the trash angel patch and there is an angel for parking, they also get their patch and you can keep it afterwards and it's just a nice memento. And I have another little thing, all scattered over the camping field are field phones, these are the ones with the hand cranks, just feel free to use them, we can connect you to anyone on the field, if you could select their deck number or you can connect you to the info desk or anywhere else. So have a nice day and be nice to each other.