 Bonjour tout le monde, je m'appelle Baltazar Boer et je suis heureux de vous présenter une transferable e-cache, un modèle cleaner et la première instantiation pratique, un joint-work avec Georg Fuchsbauer et Chen Kian. Parce que beaucoup de vous ne vous connaissez pas avec une transferable e-cache et probablement même avec l'e-cache, je vous introduirai les définitions principales dans la première partie et je vais tenter de vous expliquer les difficultés de définir les notions anonymes dans un contexte. Ensuite, je vais simplement summariser nos contributions avec quelques comparisions à l'état de l'art. Et finalement, je vais sketcher une version simplifiée de l'art. L'e-cache est un système de paiement basique avec trois types d'entités. Un banque, qui est offert pour l'issue d'un coin à l'utilisateur, ici Alice, qui est offert pour s'assurer d'un coin à l'utilisateur, nous pouvons donc déposer ce coin à la banque. Si c'est très facile de faire un système comme ça, avec des fonctionnalités cryptographiques basiques, comme les signatures, le but ici est de protéger la privacy des utilisateurs et les marchandises contre un banque curieux. Ce modèle a été développé par Chaum dans les années 80 et je vais être un peu plus précis sur ce que la transaction anonymes signifie dans son travail. Avec ses définitions, Chaum garantit à nous que le banque ne peut pas identifier l'issue d'un coin comme l'issue d'un coin. Cela signifie que le banque ne peut pas lier à Alice et les marchandises. Comme c'est écrit ici, Chaum n'a pas seulement défini les principales notions, mais a aussi construit une première instantiation dans les années 80 et ensuite a déployé un système concret avec sa compagnie Digikash dans les années 90. Le gros banque principal d'un système comme ça, dans un contexte offline, est la non-transférabilité. En effet, le marchand ne peut pas directement accueillir l'issue d'un coin à un autre marchandise. C'est pourquoi, plus recentement, les recherches ont développé un schéma plus puissant qui merge les marchandises utilisateurs d'utilisation par autoriser un nombre d'arbitraires de transferts sans aucune communication avec le banque. Et bien sûr, nous aimerions toujours avoir une garantie de non-transférabilité. Je ne vais pas détailler toutes les publications numéroses sur l'issue de transferts. Mais l'important à savoir est que, en 2015, Baldimiti, Chase, Fuchsbauer et Kohlweiss proposent le premier schéma de l'époque polinomiale qui vérifie les propriétés de non-transférabilité. Comme je vais l'expliquer plus tard, notre travail est basé sur leur papier. Maintenant, j'aimerais adresser aux gens de ne pas s'occuper de les défis en transactions offline. Je vais focusser sur les aspects basiques de E-Cache. Alors, qu'est-ce que le double-spendique ? C'est remarquable que nous ne pouvons pas éviter les utilisateurs de non-transférabilité pour double-spendique. Par exemple, ici, si Alice recevait le coin avec cet identifiant, parce que c'est un data classique, elle peut transférer le coin à Bob et ensuite le transférer à Charlie. Et parce qu'il n'y a pas de communication entre Charlie, Bob et le bank, les deux transactions seront validées et, à ce point, Alice a créé l'argent autorisé parce qu'elle n'a qu'une coin et elle se transfère deux. Elle est double-spendique. Donc, si nous ne pouvons pas éviter cette situation en théorie, nous devons éviter, en pratique, de faire le système économiquement soutenable. Nous devons avoir une fonctionnalité minimale qui détecte un rocher comme ça. Puis, ça implique que nous devons forcer Alice à mettre des données relatives de sa identité dans le coin transféré. Et, comme les premières implications, il traite une issue d'efficacité. Parce qu'il implique que le nombre de coins va augmenter après chaque transfert. Par exemple, ici, si Charlie transfère son coin à Bob, le coin reçu par elle aura l'information de l'identité de Alice et de l'identité de Charlie parce que Charlie est aussi un potentiel double-spender. Et il traite aussi une issue anonyme, mais je parlerai de ça plus tard. Donc, l'important à savoir est le fait que, pour éviter le double-spending, nous devons avoir une fonctionnalité minimale qui détecte un rocher comme ça. Cette fonctionnalité pourrait prendre en place deux coins déposités qui détectent si les coins ont la même origine et pourraient ensuite mettre l'identité de l'identité du rocher si il y en a un et que l'autre sera bien. Donc, maintenant, nous pouvons définir les notions d'anonymité. Premièrement, l'anonymité de coin, la définition naturelle qui peut être vécue comme les généralisations de l'anonymité de Charlie. Similarly, il nous garantit que le banque ne peut pas connecter un coin déposité et un coin de l'identité. La seule différence est le fait que, maintenant, la taille de change est arbitrarie. Mais maintenant, parce que l'utilisateur peut recevoir un coin prévument élevé, nous devons définir une feature d'anologue qui protège nous contre un utilisateur curieux. Par exemple, ici, nous ne voulons pas autoriser Alice pour connecter l'identité de coin à Bob et l'identité reçue de la shop. Nous appelons cette propriété Coin Transparency. Mais, qu'est-ce que si le banque et Alice collèvent, ensuite, nous verrons que notre toute sécurité peut s'arrêter. Nous aimerions avoir la même garantie que avant, même en ce cas. Nous aimerions être sûrs que cette équipe ne peut pas connecter le coin donné à Bob et le coin déposité par la shop. Mais vous pouvez noter que si Alice déposite le coin, elle transfère à Bob. Le banque, par l'utilisation de la fonctionnalité minimale que l'on a parlé avant, pourrait connecter le coin expérimenté par Alice, à Bob et le coin déposité par la store. Parce que si le détecteur nous a dit que les deux viennent de la même origine, par définition, la coalition pourrait déduire un lien entre ces coins. Donc, cet exemple simple nous montre que nous devons limiter la propriété anonymique si nous considérons les attaques de coalition. Pour cette raison, nous pouvons seulement garantir que cette coalition ne pourrait pas connaître l'identité de l'honneur intermédiaire du coin dans la chaine de transaction. Par exemple, ici, la coalition ne peut pas être sûre si l'honneur spécifique est Charlie Brown ou Charlie Chaplin. Donc, les identités de l'honneur intermédiaire sont protégées. Donc, maintenant, j'aimerais parler de notre contribution par comparer le coin au travail de 2015. Tout d'abord, nous avons ré-written la définition anonymique par ce qui est plus simple pour notre opinion, et nous avons également donné des noms plus descriptifs pour ces définitions. D'abord, nous avons formulé des propriétés de sécurité mises. Ici, j'aimerais vous donner un exemple. Ce n'est pas lié aux notions anonymiques, c'est plus sur les notions économiques. Let's suppose that Alice receives a coin of someone, very suspect. But let's suppose that the spender respects the protocol from Alice's point of view. But in reality, the spender, who was a malicious, has completely broken the coin. And for this reason, Alice can't transfer the coin to a potential a honest receiver, such as Bob. In previous paper, this attack was not considered at all. And in our work, we have formalized a property which guarantees that to Alice that her coin will be accepted by an honest user. And it's really important to make the economical system sustainable because the users need to have the guarantees that the money is valid. Even the spender is not honest. And finally, we have built a new scheme, more revision than the previous one of 2015. And now, I will present you a sketch of our scheme. Suppose Alice wants to withdraw a coin. Then she would generate a serial number, SN0, and ask the bank for a signature on it. And if Bob wants to receive this coin, he should also generate a serial number, SN1. And Alice, to confirm the transfer, will create a tag related to both serial numbers and which encode her identity. And Bob will do the same with Charlie for the next transaction. You can notice that the size of the coin grows after each transaction. But as I've explained before, it's necessary to prevent double spending. Now, let's consider that Alice wants double spend her coin to Bobette. Then Bobette would generate a new serial number, SN1 prime. And Alice has to create another tag, T1 prime, that links her already used serial number SN0 with the new one of Bobette, SN1 prime. So, in the end of the chain, the bank will detect easily the fraud by noticing twice the same initial serial number. And because of tag exclusability, a property already used in the previous scheme, the bank will retrieve the identity of the fraudster here Alice. So, now a good question is how to make such a system anonymous. First, look at the user anonymity. To briefly recall the user notion, it guarantees us that even a coalition can't guess the identity of an intermediate owner. So, let's suppose that Alice is with the bank. In the end of the transaction, the bank will receive all serial numbers and tags. And in particular, the serial number and the tag, which has been generated by Charlie. Then, it's important that tags and serial numbers are not linkable to the user who generates them. For example here, it should be difficult for the bank to guess if the generator was Charlie Brown or Charlie Chapin. Fortunately, this property was already achieved in the previous work of Baldimitzi et Al. Now, we would like to know if our scheme verifies the coin anonymity, which guarantees us that the bank can't recognize an issued coin. We have to focus on the withdrawal of a coin. At this step, the bank just signs on Alice's serial number. But, in the end of the transaction chaine, the bank will obtain the same signature and the same serial number. So, it's important to avoid the bank to have access to this data during the withdrawal. Similarly to the original charm scheme, we have to use blind signatures. It means that the signer signs a message without learning it. Et plus encore, il ne peut pas reconnaître le signage du résultat à la session de signage. Et afin d'assurer le reste de notre construction, nous utilisons un type spécial de signes de blindes construits par les signes commutés. Donc, nous modifions un peu notre protocole pour consacrer le coin anonymité. Mais maintenant, nous aimerons aussi acheter une plus spécifique propriété pour le contexte transferable, la transparence des coins. Alice, pour générer le tag, a vu le serial nombre de Bob. En plus, elle a généré ses seriales et ses tags. Elle pouvait reconnaître cette data si le coin a été transféré à elle. Pour surmonter ce sujet, nous avons décidé de commettre toutes les données sensitives et de prouver leur validité en utilisant des prouves grossales. Alors Alice devra commettre ses seriales et Bob devra commettre ses tags. Mais ce n'est pas suffisant, parce que Alice pouvait reconnaître le commettement qu'elle a généré. Fortunatement, les prouves grossales et les prouves grossales peuvent être renseignées. Et donc, Alice ne peut plus reconnaître les données qu'elle a générées. Mais en ajoutant cela, nous prévons la banque d'avoir accès aux numéros seriales et des tags. Ensuite, elle ne peut plus détecter la spécifique double. Et c'est une grande issue. C'est-à-dire que nous devons cloner ces éléments au-delà des commettements. Mais ensuite, cela devient problématique encore pour Bob's privacy. C'est pourquoi nous avons décidé d'encrypter les données de clon et de donner la banque secret à la banque. Nous avons décidé de ré-randomiser les textes, de prévenir Alice de reconnaître les numéros seriales qu'elle a générées. Pour faire cela possible, nous avons construit un nouveau schéma de ré-randomisation qui suit parfaitement notre casseuse. Ce schéma a été inspiré par une personne développée par Libert, Peter & Cannes en 2017. Je ne vais pas vous donner plus de détails sur notre schéma, mais comme vous pouvez l'imaginer, une grande difficulté c'est de faire le travail de toutes ces primitives puissantes dans le protocole unifié. Mais avant de finir, je voudrais parler de l'efficacité. Même si c'est plus efficace que le schéma précédent, l'efficacité n'est pas négligeable. Nous pouvons regarder en plus de détails le schéma de ré-randomisation et de noter que tout est short, d'exception de l'efficacité. Et le facteur important est celui-ci. Il nous a dit que, après chaque transfert, la taille augmente de 104 élémentes groupes, donc approximativement 20 kilobits. Ça peut sembler grand, mais c'est vraiment la première, même la construction de la construction de la construction de l'éfficacité qui arrive à satisfaire les notions anonymes. Je ne vais pas vous donner plus de détails sur notre travail, mais si vous avez des questions et des besoins, n'hésitez pas à nous contacter par email. Et avant de vous dire goodbye, je voudrais vous remercier pour votre attention.