ZK11: Aptos Keyless: Blockchain Accounts without Secret Keys - Alin Tomescu

Summary

Alen from Aptos Labs introduces Aptos Keyless Accounts, a blockchain account system that eliminates the need for secret keys. By tying account security to traditional web accounts like Google, it aims to simplify onboarding for new users and enhance user experience. Keyless accounts address common issues with current blockchain UX, such as the complexity of wallet installation, mnemonic phrase management, and device transfer difficulties. Alen discusses the technical implementation, including the use of OpenID Connect signatures and zero-knowledge proofs for privacy, and touches on future improvements and challenges.

Takeaways

• 🔐 **Keyless Accounts**: Aptos introduces keyless accounts, a blockchain account system that doesn't require secret keys, aiming to simplify user onboarding.
• 🌐 **Web Account Integration**: Security is based on traditional web accounts like Google, Facebook, or Apple, making it familiar to users.
• 👥 **Joint Work**: The keyless account system is a collaboration between Aptos Labs' core team and Geometry Research.
• 🚀 **User Experience Focus**: The goal is to onboard the next billion users by making the process of joining blockchain spaces easier.
• 📱 **Simplifying DApp Interaction**: Users shouldn't need to install wallets or deal with transaction prompts, making the experience seamless across devices.
• 🔗 **App-Specific Accounts**: Keyless accounts are tied to specific apps, preventing malicious sites from stealing accounts associated with different DApps.
• 🖊️ **Transaction Signatures**: Transactions are signed using an Open ID Connect signature from providers like Google, ensuring security.
• 🙈 **Privacy Preservation**: Zero-knowledge proofs are used to hide sensitive information such as email addresses and application IDs from the blockchain.
• 🔄 **Ephemeral Key Pairs**: To improve performance, users generate an ephemeral key pair for each transaction, signed by Google, reducing the need for zero-knowledge proofs per transaction.
• 🌶️ **Pepper Service**: A pepper service is introduced to handle the blinding factor for account addresses, enhancing privacy and security.
• 🔄 **Recovery Mechanisms**: Keyless accounts have recovery mechanisms in case the signature provider is unavailable, such as using an email signature to rotate keys.

Q & A

What is Aptos Keyless Accounts?

Aptos Keyless Accounts are blockchain accounts that eliminate the need for secret keys. They derive their security from traditional web accounts like Google or Facebook, making onboarding easier for users.

Who is Alen and what is his role at Aptos Labs?

Alen is the head of cryptography at Aptos Labs. He is responsible for the development and security of cryptographic systems within the organization.

What is the main goal of implementing Keyless Accounts?

The main goal is to onboard the next billion users by simplifying the user experience and eliminating the need for users to manage secret keys or mnemonic phrases.

How does the user experience improve with Keyless Accounts?

Users can directly sign up for a dApp without installing extra software, and they don't need to write down mnemonic phrases. This simplifies the process of interacting with blockchain applications.

What is the role of OpenID Connect (OIDC) in Keyless Accounts?

OIDC is used to sign transactions on behalf of the user. It allows the user's email address and the application ID to be signed by a trusted provider like Google, creating a secure and verifiable signature.

How does the privacy of users' email addresses and application IDs get protected?

Privacy is maintained by using zero-knowledge proofs. This ensures that sensitive information like email addresses and application IDs are not revealed to the blockchain validators.

What is a prover service and how does it relate to Keyless Accounts?

A prover service is used to speed up the computation of zero-knowledge proofs, which are necessary for the privacy-preserving aspects of Keyless Accounts. It helps in verifying transactions quickly.

What is the pepper service and how does it contribute to Keyless Accounts?

The pepper service helps users remember their pepper, which is a blinding factor used to generate blockchain addresses. It ensures that the address is not directly derived from the email address and client ID, adding an extra layer of privacy.

How does the implementation of Keyless Accounts ensure performance?

The implementation uses GR16 over a fast curve and circom to ensure that the verification time for keyless transactions is minimal and the proof size is small.

What are some potential issues with the current Keyless Accounts system?

Some potential issues include the reliance on third-party providers for signatures, the need for a recovery mechanism in case the signature provider goes down, and the potential for the prover service to leak privacy.

What are some future improvements planned for Keyless Accounts?

Future improvements include moving the pepper service on top of the validator for better security, potentially moving the trusted setup onto the validator, and working on faster proving to eliminate the need for a prover service.

Outlines

00:00

🔐 Introduction to Keyless Accounts

Alen, head of cryptography at Aptos Labs, introduces the concept of keyless accounts on blockchain, aiming to simplify user onboarding by eliminating the need for secret keys. He explains that these accounts are secured like traditional web accounts and are app-specific to prevent malicious activities. Alen emphasizes the importance of ease of use, the desire to avoid cumbersome processes like writing down mnemonic phrases, and the goal to onboard the next billion users. The talk also credits the core team at Aptos Labs for their contributions to the project.

05:02

🔗 How Keyless Accounts Work

The speaker delves into the technical workings of keyless accounts, explaining that the account's address is derived from the user's email and the application ID. He outlines the process of how transactions are signed using OpenID Connect (OIDC) signatures from providers like Google, which are then verified on the blockchain with zero-knowledge proofs for privacy. The aim is to create an account system that is secure, easy to use, and does not require users to manage secret keys.

10:04

🛠️ Addressing Privacy and Performance

Alen discusses the importance of maintaining privacy and performance in keyless accounts. He introduces the concept of a pepper service to help users remember their account details without storing long-term secrets. The pepper service uses a verifiable unpredictable function to generate a pepper based on the email address and client ID. Alen also addresses the issue of transaction tracking by Google and proposes a solution using commitments to the ephemeral public key to prevent tracking.

15:05

🚀 Implementing Keyless Accounts

The talk moves on to the implementation details of keyless accounts. Alen mentions the aggressive performance goals for transaction verification times and proof sizes. He explains the use of GR 16 over a fast curve, B254, and the implementation of the circuit in GR 16 using Circom. The talk also covers the public nature of the codebase, inviting the audience to review and build upon it. Alen also mentions the use of a hardened version of Rapid SNARK for the prover service and a Rust-based service for the pepper service.

20:06

🔒 Security and Future Work

Alen addresses potential concerns about malleability and sensorship resistance in keyless accounts. He explains how non-malleability is achieved through the use of ephemeral secret keys and discusses fallback mechanisms in case the signature provider becomes unavailable. The talk also touches on future work, including the possibility of using different OIDC providers, enhancing the pepper service, and improving the proving process to eliminate the need for a prover service.

25:06

🤔 Q&A and Closing Remarks

The final part of the script includes a Q&A session where Alen answers questions about the trustlessness of the prover service, the pepper service's role in generating or storing peppers, and the implications of GR 16 proofs being malleable. He also discusses how funds can be sent to users who haven't signed up for the service and the need for the recipient to have an OIDC signature to access the funds. Alen concludes the talk by inviting further discussion and thanking the audience for their attention.

Keywords

💡Aptos

Aptos is a blockchain platform focused on building a safe and scalable ecosystem for decentralized applications. In the context of the video, Aptos Labs is the organization responsible for developing the concept of keyless accounts, aiming to make blockchain interactions more accessible and secure.

💡Cryptography

Cryptography is the practice and study of secure communication in the presence of third parties. The speaker, being the head of cryptography at Aptos Labs, discusses the development of keyless accounts, which is a cryptographic innovation to enhance security without the need for traditional secret keys.

💡Keyless Accounts

Keyless accounts refer to a system where blockchain accounts are secured without the use of secret keys, as traditionally required. This concept is central to the video, where the speaker explains how these accounts are tied to traditional web accounts like Google or Facebook for security.

💡OpenID Connect (OIDC)

OpenID Connect is an authentication protocol that enables third-party services to authenticate users. In the video, OIDC is used to explain how keyless accounts can be verified by associating blockchain transactions with an OIDC signature from a trusted provider like Google.

💡Zero-Knowledge Proofs (ZKP)

Zero-knowledge proofs allow one party to prove to another that they know a value without revealing the value itself. The video discusses using ZKPs to ensure privacy in keyless accounts by hiding sensitive information such as email addresses and application IDs from the blockchain.

💡Ephemeral Key Pair

An ephemeral key pair is a temporary cryptographic key used for a single exchange. The video explains how an ephemeral key pair is used in keyless transactions, where Google signs a public key (EPK) that is then used to sign transactions without revealing the private key.

💡Blinding Factor

A blinding factor is a value used to obscure or 'blind' data to protect privacy. In the context of the video, a blinding factor or 'pepper' is used in the address derivation process to prevent linking blockchain addresses to user email addresses.

💡Provable Service

A prover service is a system that helps in generating proofs, such as zero-knowledge proofs, more efficiently. The video discusses how a prover service is used to speed up the computation of ZKPs for keyless account transactions, though it raises privacy concerns as the service learns the secret witness.

💡Client ID

A client ID is a unique identifier assigned to an application when it is registered with an authentication service provider. In the video, the client ID is used in the context of OIDC to identify the application associated with a keyless account and to sign transactions.

💡Malleability

Malleability in cryptography refers to the ability to alter some part of a cryptographic message without invalidating the signature. The video addresses how keyless accounts achieve non-malleability by signing the proof with an ephemeral secret key.

💡Recovery Mechanism

A recovery mechanism is a process to regain access to an account or data in case of loss or failure. The video touches on the need for recovery mechanisms in the context of keyless accounts, especially if the signature provider becomes unavailable.

Highlights

Introduction to Aptos keyless accounts, a blockchain account system that avoids the use of secret keys.

Alen, head of cryptography at Aptos Labs, presents the concept of keyless accounts and their security foundations.

Keyless accounts are based on traditional web accounts like Google, Facebook, or Apple for security.

The goal is to onboard the next billion users by simplifying the user experience and avoiding the need to manage secret keys.

Current user experience issues with dApps and web3 applications involve confusion over wallets and mnemonic phrases.

Keyless accounts aim to eliminate the need for users to write down mnemonic phrases and manage keys.

The concept of app-specific accounts is introduced to prevent malicious websites from stealing keyless accounts.

Keyless transaction signatures are similar to OpenID Connect signatures, incorporating zero-knowledge proofs for privacy.

Alen discusses how to hide email addresses and application IDs from the blockchain for privacy.

The use of OpenID Connect protocol in registering applications and obtaining a client ID is explained.

Details on how applications use OpenID Connect flow to sign in with Google and obtain signatures.

The potential for blockchains to act as a third-party verifier in the OpenID Connect process is explored.

Alen describes how to fix privacy issues by using zero-knowledge proofs to hide sensitive information.

The implementation of a prover service to speed up the computation of zero-knowledge proofs is discussed.

Address privacy is enhanced by using a blinding factor called 'pepper' to hide the email address and client ID.

Alen explains the concept of an ephemeral key pair to reduce the number of zero-knowledge proofs required per transaction.

The pepper service is introduced to help users manage their blinding factors without storing long-term secrets.

The pepper service is designed to be simple, with access control managed via the OpenID Connect protocol.

Alen discusses future work, including improving the pepper service for privacy preservation.

The implementation details of the Aptos keyless accounts system, including performance goals and circuit design.

Alen invites the audience to review the open-source codebase and participate in the Aptos community.

The talk concludes with a Q&A session addressing concerns about malleability, censorship resistance, and trust in the prover service.

Transcripts

[Music]

um so my name is alen I'm the head of

cryptography at Aptos labs and today I

want to tell you about Aptos keyless

accounts which are blockchain accounts

that avoid the use of secret Keys um and

what they base their security on is a

traditional web to account like your

Google account or your Facebook account

or your Apple account so let's get

started but before we do I want to say

this is Joint work with the core team at

abos Labs the core keyless theme uh

Michael and Rex should be in the

audience and you can meet them today uh

Michael designed our circuit Rex audited

it and worked on the prover service and

also the broader app TOS Labs team and

the folks at geometry research some of

them in the audience right here uh who

helped us secure the ZK

circuit so what is a keyless account uh

well it's just the way I think about it

your blockchain account is your Google

account there are no user managed secret

Keys uh and as a result you get many

goodies which are going to which I'm

going to mention throughout the talk and

in the stock when I say Google I want

you to think Facebook I want you to

think GitHub or any open ID connect

provider or oidc provider but for

Simplicity I'm just going to say

Google so why do this why enable keyless

account the short answer is we want to

onboard the next 1 billion users we

don't think this is going to happen if

every time a user enters a space they

have to write down 24 words and put them

somewhere safely and lose them and then

never engage with the space again so if

we're going to get people in this space

we need to find a way for them to join

the space very easily so if you think

about the current user experience of

using a d app or a web 3 application you

have to install a wallet what the hell

is a wallet users are very confused they

have to write down this memonic this is

very

combersome uh it's very easy for them to

lose this pneumonic and lose their money

uh they have to deal with transaction

prompts what the hell is a transaction

prompt most users don't know and it's

very painful to move your device uh to

move your account from your laptop to

your mobile phone to your

tablet so what we want is kind of the

opposite we want we still want wallets

but we want the possibility of being

wallets we want users to directly sign

up for a d app without installing extra

software we don't want users to write

down the monics that's just painful uh

nonetheless we still want the account to

be very hard to lose and we'd like to

avoid transaction prompts if possible

and we'd also like to for things to work

across

device and additionally we might also

want other goodies like we might want

kyc via the IDC provider we might might

want to be able to send transactions

directly to an email address that would

be great um so that's what I'm going to

tell you about in this talk how to

enable all these things so how do

keyless accounts work at a really high

level there's four things I want to say

here so first a keyless account its

address is derived from two things your

email address and the application ID of

the wallet or the D app you're using so

that means these accounts are app

specific uh so they're associated with a

D app like d app. XYZ or they're

associated with a wallet like metamask

and this is what prevents a malicious

website like medium.com from stealing

your keyless account associated with

dxyz the fact that you have this the dab

specific

binding and this is also what allows for

wallet list apps um the fact that we

have this binding now a keyless

transaction signature the way this works

is it's really the same thing as an open

ID connect signature from the provider

and really it's a zero knowledge proof

of knowledge of such a signature for

privacy reasons and this signature from

Google is over a couple of things the

transaction hash your email address and

the application ID

and lastly we add a splash of zero

knowledge for privacy so we want to hide

a couple of things we want to hide the

email address and the application ID

from the chain from the full nodes

validators everybody but we also want to

hide transactions from Google we don't

want Google to be able to track which

email addresses are are associated with

each blockchain addresses and which

transactions are associated with an

email

address so at a high level this is the

picture uh next I want to go a little

bit deeper and actually show you some

some

details um so let's start with uh the

open ID connect protocol and how

applications register in this protocol

in order to get a client ID a so-called

client ID so if you have an application

like media.com or dap. XYZ you go on the

Google Cloud console for example and you

register it in there and at the end of

this sort of manual process you get a

so-called client ID so this will be the

application identifier that I mentioned

before which is committed in your

address and it's also signed by Google

when it signs your transaction right so

that's the first step so now that the

application is registered let's see how

kind of uh open ID connect flow works so

you're all familiar with this because

you've all used websites that asked you

to sign in with Google so this is what

happens when you use those websites you

you go to the app and the app displays

to you this prompt uh by redirecting you

to Google and in the URL that the app uh

redirects you with you actually have a

few param in there so you have this

client ID that I mentioned before which

is the identity of the application and

very very importantly the application

can specify any arbitrary data to Google

and what Google will do when you sign in

with your cookies is it'll send the app

this signature right and the signature

will be over three things your email

address that you successfully logged in

with the app's identity and this

arbitrary data that the app included

right and this of course this arbitary

data here will be very important because

guess what that arbitrary data will be a

transaction so and this is how we're

going to get Google to sign your

transactions for you and this is how

we're going to make the account be

keyless um and what's worth emphasizing

here also is that this is a digital

signature right so this is publicly

verifiable so anyone who has Google's

public key can take the signature and

verify it so now here's a couple of

observations what if this third party

verifier is a

blockchain and what if the application

is a wallet or a d app and what if the

data being signed is a transaction right

then you're basically looking at the

keyless picture if you get one thing

from the stock it's this slide this is

basically 90% of a picture the next part

of the talk I'm going to refine it a

little bit since we we're going to need

to deal with

privacy um right so the way it works

is your wallet will will sign you in and

then you want to send transaction for

your

address and you will include this oidc

signature from Google together with the

application ID and your email address so

so far this is not privacy preserving

right we're going to fix it in a second

and you can send this at the blockchain

validators and what the blockchain

validators can do is they can verify the

signature like I showed you before

because they have your email address

they have the client ID and they have

the transaction and additionally they're

going to match that the address you

included in the transaction

is indeed associated with the account in

the signature right so they're going to

verify for example the address is the

hash of the email address and the client

ID right so far so

good but there's a problem you are

revealing in plain text your email

address and the application ID and in

particular the email address is very

worrisome but even the client ID could

be problematic if you reveal it because

it leaks which applications are doing

what so we got to fix that and obviously

the very trivial fix is to just throw a

zero knowledge proof at it right so

instead of giving all of the secret

witness like the client ID and the and

the signature and the user email we're

going to we're going to move it inside

of a zero knowledge proof and we're

going to do all of the work inside the

zero knowledge relation here so this is

a zero knowledge proof of knowledge of

an oidc signature and an email address

and a client ID such that the IDC

signature verifies over the public input

public key and over the public

transaction input right and such that

the public address input is derived from

the secret email address and the secret

client ID so from the blockchain

validator perspective all they see is an

address and a transaction and Google's

public key and this proof assures them

that there is an oidc signature over the

email address inside the blockchain

address right and the client ID and over

the public transaction

okay so this is again a very you know it

looks very simple when you put it on the

slide it's very hard to implement but

it's a very simple change you just throw

a zero knowledge proof at things this is

what we like to do in this community

anyway good so there are some

complications with the zero knowledge

proof uh it takes I think about 30

seconds to compute in the browser so if

we're going to use this for our users

it's going to be very bad ux so we'd

like to speed it up so we have to rely

on aover service

um which is going to make the

computation of the Zer knowledge proof

much faster we can compute it in under

two seconds but it's going to have some

privacy implications and we can talk

about those

later because in particular the prover

service will learn the secret witness so

it learn the email address and the

client ID uh nonetheless I should say

it's very important to emphasize here

that theover service cannot steal your

funds I'll I'll describe that uh in a

second as

well uh nonetheless there's still more

problems left so as you can see here

Alice has to compute one zkp per

transaction and the blockchain has to

verify one zkp per transaction so we

don't like that for performance reasons

so the way to fix that is using a layer

of indirection that's every problem in

computer science can be solved with a

layer of indirection uh so what Alice is

going to do is she's going to generate

an ephemeral key

pair let's see right I have an ephemeral

key pair here es and an EPK

and next what we're going to do is

instead of signing the transaction we

will give Google this EPK to

sign and in the transaction signature we

will include an ephemeral signature over

the

transaction under this es right and then

the blockchain validators can simply

verify this ephemeral signature so we've

added a layer of IND Direction so now

you can think of the zkp as a

certificate for this ephemeral public

key and the transactions are signed by

the ephemeral public key and this

signature verification is in plain text

right the validator see an Emeral public

key and a signature on the transaction

there's no privacy loss there and notice

that although there's a key here these

keys are ephemeral you can lose them it

doesn't matter if you lose them you sign

back in you generate a new es and Google

will gladly sign it for you so they're

not sensitive from a loss

perspective and for those of you who are

familiar this keare can actually be a

web aen Pass key keare so this way you

can actually be very secure that it

won't it won't be stolen right if it's

backed up in your iPhone's Enclave let's

say still we have more problems the

address uh that uh is stored on chain is

a function over the email address and

the client ID so it obviously leaks an

attacker can brute force your email

address and the client ID and tell who

you are on chain so we want to fix that

too and the very simple fix there is to

just make the address be a commitment

rather than a hash of the email address

right so we're going to use a blinding

factor for that we call this blinding

factor a pepper uh these are just random

bits now if we did this naively the user

would have to pick those bits and

remember them and if the user loses

those bits then they can no longer

access their account so that would

defeat the purpose of this whole

approach because the whole point is we

want to avoid

storing long-term secrets so instead

what we're going to do is we're going to

have a pepper service that's going to

help users remember their pepper so the

way this will work is the pepper service

will evaluate a verifiable unpredictable

function over the email address and the

client ID and that defines the pepper in

the blockchain address associated with

these two and this actually makes the

pepper service a very simple service it

just has to store a 32 by VF key like a

BLS key

and it's also very easy to decentralize

so you can have a decentralized pepper

service with 20 servers that just

computes a threshold signature for the

user to get the user the pepper and of

course there's an access control issue

because the pepper service better not

give my pepper to somebody else it

better only give it to me and the way we

actually guarantee access control is

also via the open ID connect protocol

because the pepper service can actually

verify these these

signatures uh from Google before giving

you your pepper

um so that's the good news about the

pepper service and right now the pepper

service is not privacy preserving but we

can actually make it price of reserving

as well so the pepper service could in

principle receive a zero knowledge proof

of knowledge of an IDC signature and a

blinded um hash of the email address and

the client ID and evaluate the BLS

signature over that blinded hash so that

so that it doesn't even learn which User

it's Computing the pepper for uh we

haven't down yet but that's plans for

the

future good so next step is one last

tiny detail is that Google will actually

see this EPK here in the nons right and

if it can see this EPK then it can track

transactions on chain um so now it knows

which user is doing which transactions

this is also a very trivial fix instead

of putting the EPK in the open ID

connect signature we're going to put a

commitment to the EPK using some

different blind Factor R which is part

of the secret witness of the

zkp and basically we're done that's the

design this is it so if you get a second

thing from the stock it's this picture

right here uh which is the complete

privacy preserving story with the pepper

service and the approver service for

performance all right for the next part

of the talk I just want to uh mention

some things about our implementation so

when we built this because because this

is a layer one primitive right we are

putting these kind of keyless signature

on our transactions we have some pretty

aggressive performance goals so we want

the verification time of such a keyless

transaction to be very small and also

the proof size the zkp to be very small

uh in particular this is kind of

stringent if you think about it because

if an attacker puts bad zkps in your

transactions you have no recourse like

you're going to get dossed because if

the zkp fails to verify there's no

account that you can charge gas to right

there's nothing you can do so you really

have to make the implementation fast uh

so our only choice was to do gr 16 over

a fast curve

b254 and to implement the relation in in

uh in gr 16 we use circom we have 1.3

million R1 CS constraints and our code

is actually public we invite you to look

at it we invite you to build over it um

it's in a way very related to the ZK

email work that you've seen before and

some previous work on verifying jwt's in

snarks um and what's interesting about

our circuit is that we have some new

polinomial based protocols for doing

substring matching in a circuit which is

otherwise very complicated to do and

very expensive to do I should say so

this is what helps us achieve a small

number of

constraints we did an NPC ceremony for

the circuit we used potion uh fixed a

couple of bugs in it and we had 140

participants over the duration of one

week

and our prover service is implemented

via a hardened version of Rapid snark

which is a C++ code base it's really

fast the only thing faster than rapid

snark that I could find is maybe gar but

I couldn't manage yet to Benchmark our

circuit in gar because we have to take

our circom circuit and put it in gnark

if any of you know anything about that

please talk to me uh our pepper service

is just a rust based service uh that

uses BLS uh to evaluate the pepper

and that's it that's our implementation

so to conclude the talk um I think ux is

key for blockchains and good ux Is

keyless so open source uh codebase

please take a look at our rust validator

code at our repo uh at our MPC trusted

ceremony and Prov service I think and

pepper service are all public we have a

test deployments uh active on the appos

blockchain this is deployed in devet and

in testnet and will become to main net

pretty soon um it's also already been

used in the app toss random hack where

we've seen a few projects build on top

of it so that's very exciting uh and if

you want the nitty-gritty details and

all of the security implications and

details you can find them in an Aptos

Improvement proposal that I wrote

there's a PR open there's a couple of

more things to address

there um future work I think this kind

of approach raises some interesting

questions about

what kind of oidc providers would you be

willing to trust with your blockchain

accounts so this approach is not to say

that all users should use it it's

probably for 90% of users who are novice

right but even for those users maybe

Google is not the right choice so maybe

we There's an opportunity here to think

about identity providers for blockchain

users and maybe there's even a business

space in that um we want to try and move

the pepper service on top of the

validator so that it's as secure as our

validators as well as making it privacy

preserving we also want to try to

potentially move the trusted setup on

top of of our of our validator so we can

easily bug fix and upgrade our circuit

or ideally move to a universal snark

that meets our performance goals and

obviously we want to work on faster

proving to eliminate the prover service

um and there's a lot of cool features

that I did not get to discuss I'll I'll

leave them here for you and also a lot

of nuance and details in particular the

this Emeral key that I mentioned

actually has an expiration date it

doesn't leave live indefinitely and

there's implications around D specific

accounts that you have to deal with and

there's implication around wallet list D

apps that you have to deal with and just

this Json web token stuff this open ID

signature format uh and and how we deal

with it in our application uh but that's

it uh thank you so much for your

attention and would love to get lots of

questions thank thank you do we have any

questions there's a microphone do you

know the system by now okay don't sy so

is it's coming up all right fantastic

thanks great talk uh I had a question

about malleability and whether it's an

issue here so great if right so was the

intuition um I'll wait for the slides to

come yeah can I get the slides

back yeah malleability was actually I

think in the list of stuff it was sorry

like I blanked at that point then I yeah

so we we deal with it in a very simple

way we get non-malleability by signing

the proof with the ephemeral secret key

uh which is a nonmalleable signature as

well um that's how we got nonm and and

yeah we were worried about it in

principle all of our transaction

signatures are non-malleable because we

don't want people to worry about

malleability so so this solves the

problem of

malleability of the of the gr 16 yeah

because the ephemeral signature itself

is non malleable and then there's just

gr 16 and then you have to be careful

that other things like metadata next to

the zkp and the FML signature is not

malleable as far as we know it's not but

if you want to take a look at our code

thanks thanks for the

answerers okay any other questions yes

in the

back there's a microphone down on on the

chair just press the

button uh sometimes they don't work now

now you can hear okay so I want want to

ask what's your sensorship resistant

model and more specifically what's the

fallback in case the signature provider

goes down or doesn't want to provide the

signature for a specific user uh I

couldn't hear it very well could you put

the mic can you put here is it better

okay so I'm going again what's your

sensorship resistant model and to be

more specific what the fallback in case

the signature provider doesn't want to

provide the signal to specific user or

anyone else yeah that's that's a

that's a very good question so there's a

few ways to deal with that um it so at a

fundamental level you want to pick o IDC

providers that you have recovery

mechanisms for in case they stop playing

bow that doesn't answer the question

though because any provider can go down

any day so if I have an account in an

app using a kills model that means if

the signning provider goes down for any

reason reason or doesn't want to give a

signature for my user for example that

means that I lose everything yeah

correct so if you if you have a bad

provider that that's bad for you you

don't pick bad providers you would pick

really trustworthy providers I think the

only risk here is that the provider

probably says look I don't want to have

to do anything with blockchain

applications so any client ID that is a

wallet or a d app I'm just not going to

provide signatures for and in that case

you need a recovery mechanism for your

users and there's two things that we can

imagine doing one thing is we can use

for example the ZK email approach to

recover your account if you've been to

their talk so basically you can send an

email from your Google account which has

a signature from Google and that email

can authorize a key rotation for your

keyless account so that that would be

okay it would be kind of user unfriendly

but in principle it would give you back

access to your funds another way would

be to have a recovery service so a

recovery service with its own client ID

that users log into and the only thing

this Recovery Service does is it rotates

your key so maybe you know Google stops

playing ball but it allows this recovery

service to help users recover um so

those are two things that you can do and

in general that's what I mean by yanto

IDC providers that admit recovery

mechanism so let's say you use Twitter

you could use a public tweet to rotate

your account to a new publicy if you had

an HTTP Oracle on chain right that's

another recovery mechanism for another

provider I I hope that answers your

question but I'm happy yeah we can also

talk after discusser yeah there's a

microphone on the ground do you see it

it should be red

light yeah sometimes they don't

work okay thank you uh so you have

mentioned that you are using proven

service in your application is it is it

trust us or to which degree is it trust

I suppose uh I I fail to emphasize that

huh not sure what happened with my

slides uh it's trustless so if you think

about it the prover

Service uh gets this soidc signature

over an EPK right it doesn't know the

associated es to sign transactions with

so the approver service simply you know

you lose privacy with respect to the

approver service but there's ways to

deal with that you can MPC the appr

service and in fact snarks like grat 16

admit very efficient MPC protocols but

you know that's the only problem privacy

which which is addressable um stealing

your account isn't impossible because

the approver service doesn't have the es

and it cannot get a new IDC signature

over an EPK whose es it knows right does

that make sense yeah thank

you any other questions where the

front Okay we have time for a couple

questions I'll just take this one first

out of proximity I'll come to you um

does the pepper service generate the

peppers or stores them too yeah good so

um I mentioned in the talk that the

pepper service is uh using a verifiable

unpredictable function to generate a

pepper given an email address and a

client ID by simply evaluating a VF over

them a VF an example of a VF is a

deterministic signature scheme like BLS

why can't users do that themselves is it

too expensive or what but well they

would have to remember it if they did it

that that themselves right so it does

store it or generates it time it only

stores is the secret key of the VF so

that's 32 bytes and from that secret key

and a email address and a client ID it

can derive the pepper without ever

having to store it but what happens if

the pepper service fails if the pepper

service fails then users are locked out

of their account if they don't have

their pepper right so it's very easy to

mitigate against that so one one way is

for users to back up their peppers if

they're paranoid but we don't like that

uh another way is to actually

decentralize the pepper service and make

sure the key is never lost what you want

to ensure is that the secret key of the

pepper service is not lost now maybe you

know the top 2% of users uh might just

generate their own peppers and they

won't use the pepper service we I don't

think that's realistic for 90% of the

users but some subset of users might

want to uh in general we're not very

worried about the secret key of the

pepper service getting lost because it's

really easy to protect the key for you

know getting lost okay

thanks good so many questions it's good

thing your presentation was

shorter yeah I just wanted to connect to

what was saying the person before so you

say that the prover you have kind of no

privacy to the prover but then since the

secret key is in your possession then

you know it can in reality gross 16

proofs can be are maleable in itself so

the pro can randomize them to embed

tagging information in the proof itself

and then the user will sign and will go

so

yeah uh one second let me just okay uh

you're saying a malicious prover could

yeah because if the Malisha approver has

access to the email address it can

somehow embed it by randomizing the

proof and until some bites match like

grinding through proofs that's a really

interesting uh uh yeah I like that

that's interesting I would say the way

to mitigate against that is probably the

same way you would mitigate against the

uh the Privacy issue by MPC and the pro

service which would which would fix that

but yeah actually we haven't considered

that I really like that thanks a lot

okay we can discuss later yeah did we

have another question here cool I think

that's um hi can you derive uh public um

address from email address like if I

want to send some funds to someone who

hasn't used the the service correct so

what you could do if you wanted to send

funds to someone that isn't signed up is

you could derive an address for them so

let's say you want to send fun to Alice

on some wallet or some pay application

um like let's call it pay to email right

so pay to email has a client ID you know

it and you know Alice's email and then

you just pick a pepper for Alice you

pick it for her you pick random 256 bits

and then you email Alice hey Alice I

send you funds here's the pepper for

your address Al Alice can rederive the

same address and can sign in with Google

into the application and obtain a open

ID signature engage approver service get

a zkp and as a result get access to

those funds but the only difference in

this case is that you're not using the

pepper service Alice is simply using the

pepper that Bob picked to pay her is is

the pepper choosed by Bob or just Bob

initial initiated uh the pepper service

I mean no it's it's it would be chosen

by Bob would probably be the best way to

do it but you could also imagine that

the pay to email application could when

I say chosen by Bob is really by that

application right and then that

application would email Alice with the

pepper or maybe you would create a link

and embed the pepper in the link um and

Bob can can't use this pepper to gain an

advant advantage of this

account uh no no so remember that

there's two things you need to access

this keyless account for Alice you will

need the pepper because you will need to

do the address match but you're also

going to need an oidc signature from

Google and Bob is not going to be able

to get that IDC signature because he

doesn't control Alice's Google

account okay I think that's all we have

time for so thank you so much elen

another round of applause please thank

you so much for the questions