ZK11: Aptos Keyless: Blockchain Accounts without Secret Keys - Alin Tomescu
Summary
TLDRAlen 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
π 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.
π 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.
π οΈ 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.
π 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.
π 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.
π€ 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.
Mindmap
Keywords
π‘Aptos
π‘Cryptography
π‘Keyless Accounts
π‘OpenID Connect (OIDC)
π‘Zero-Knowledge Proofs (ZKP)
π‘Ephemeral Key Pair
π‘Blinding Factor
π‘Provable Service
π‘Client ID
π‘Malleability
π‘Recovery Mechanism
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
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
Browse More Related Video
URGENT: HOW TO CREATE A NEW ANCHOR WALLET (GREYMASS ACCOUNT)-TO SECURE YOUR XPR TOKENS (+OWNER CERT)
How to upgrade CDSL Easi to Easiest | CDSL Easi ko Easiest me upgrade kaise kare
Troubleshooting the most common Active Directory account issues | Real World IT Tickets
Microsoft (Bing) Ads Account Suspended? 7 Tips for What to Do
Awas, Beredar Aplikasi Peretas Berkedok Undangan Pernikahan
How to Set Password on Windows 11 or 10 PC!
5.0 / 5 (0 votes)