►
Description
Efficient Anonymous Updatable Credentials - Samuel Jaques, University of Oxford
Maybe you want to put your credentials on the blockchain, but you're worried about privacy. You don't want to be tracked every time you present your identity. One option is something called an accumulator. Accumulators use a short piece of data to represent a list of credentials, with users doing most of the work to maintain extra data to prove that they have a valid credential. Accumulators can easily issue and revoke credentials, and can be constructed with high privacy guarantees and little trust required. However, this makes them slow. Many variants on the classic constructions have been proposed to improve performance, but these compromise privacy and trust, sometimes in subtle ways. In this talk Sam will give an overview of what accumulators are, how they can be used, and describe some fundamental limits on the trade-off between privacy and efficiency. He and collaborators are working on a new approach which uses distributed trust to avoid some of the theoretical limits and create a completely anonymous accumulator that should be faster than previous methods.
Sessions Details & Slides (if available): https://sched.co/14H4l
Access All Sessions: https://events.linuxfoundation.org/hyperledger-global-forum/program/schedule/
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Discord: https://discord.gg/rVCn4j7UFd
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #Blockchain
License
Creative Commons Attribution license (reuse allowed)
A
My
name's
Sam
I'm
from
the
University
of
Oxford
so
coming
from
sort
of
a
more
academic
perspective,
then
I
think
I'm
getting
from
a
lot
of
people
here.
So
apologies
if
I
sort
of
tell
you
something
that
you
already
know
really
well
or
if
I
skip
over
something
that
you
don't
know,
feel
free
to
stop
me
at
any
time
with
questions.
A
What
I
want
to
talk
about
is
efficient
and
Anonymous
and
updatable
credentials,
or
this
thing
that
we
call
allosaur
and
I'll
explain
how
we
got
to
this
tortured
acronym
somewhere
through.
So
this
was
a
project.
I've
been
working
on
with
heart
Montgomery
here
at
hyperledger
and
Mike
Lotter
at
coinbase,
and
in
this
talk
most
of
it
is
going
to
be
very
high
level
and
describing
the
problems
that
you
can
run
into
with
privacy
and
digital
credentials
and
centering.
A
Maybe
you
don't
need
to
tell
this
crowd,
but
you
know
you
go
to
the
a
lawyer
and
your
lawyer
has
some
sort
of
certificate
on
the
wall
that
says
actually
that
this
lawyer
has
gone
to
law
school.
They
passed
the
bar,
the
Law
Society
verifies
then,
and
but
these
days
we're
trying
to
move
this
all
to
computers.
A
So
what
sort
of
happens
there
and
some
examples
to
keep
in
your
mind
through
this
talk
that
are
sort
of
inspiring?
What
we
were
thinking
about
is
all
different
kinds
of
credentials.
You
might
imagine
certifying
your
age
if
you
want
to
buy
something
age,
restricted
a
license
to
do
something
like
driving
fishing
hunting,
practicing
different
kinds
of
professions.
A
You
could
imagine
currency
as
some
sort
of
credential
prescriptions
parking
permits,
maybe
even
in
the
future
having
some
carbon
credits,
but
these
all
have
massive
privacy
risks
that
can
come
up
if
you're,
not
careful
about
how
you
make
them
digital
and
privacy
risk
that
they
don't
currently
generally
have
today.
So
if
you're
using
your
age
to
buy
things,
it's
hard
to
sort
of
build
a
profile
of
where
you're
buying
them,
because
you
know
someone
looks
at
your
ID
at
the
convenience
store
and
they
forget
it
immediately.
A
But
if
this
goes,
if
some
electronic
system
needs
to
record
that
it's
much
easier
for
that
system
to
remember
what's
going
on
and
then
they
know
what
kinds
of
things
you're
buying,
which
could
be
insurance
companies
could
use
that
nefariously.
That
location
data
is
bad,
something
like
a
fishing
license.
A
You
know
we
want
to
know
when
fish
are
being
harvested,
but
we
don't
necessarily
need
to
know
who
is
harvesting
then
and
sort
of
professional
licenses.
The
Privacy
risks
if
you're
verifying
that
you're
a
lawyer,
this
field
may
be
less
of
a
privacy
risk,
but
you
could
imagine
if
we
had
some
scenario
where
we
had
different
credentials
for
different
kinds
of
medicine
and
a
doctor
in
a
particular
neighborhood,
all
of
a
sudden,
all
of
a
sudden
starts
verifying
their
credential
for
some
aspect
of
medicine.
A
This
tells
you
something
about
the
neighborhood
prescriptions
and
currency
fairly
obvious
privacy.
Concerns
parking
permits
reveal
your
location,
carbon
credits
that
one
I
struggle
to
see
a
privacy
issue,
but
if
you
think
on
it,
maybe
you'll
find
one.
So
this
is
kind
of
the
the
framework
to
think
of
here.
So
a
lot
of
security
requirements.
We
need
from
a
credentialer
simply
solved
by
a
digital
signature.
A
If
you
can
have
some
certificate
that
signed
that
says,
I'm
a
good
lawyer
and
you
send
it
to
the
client
and
generally,
the
client
starts
to
wonder
all
of
these
things
like.
Is
it
real?
Does
it
really
belong
to
this
lawyer
and
yeah?
A
digital
signature
satisfies
most
of
this.
We
can
imagine
the
Law
Society
in
this
case
is
some
sort
of
authority.
A
They
send
their
certificate
to
or
some
sort
of
information
to,
the
Law
Society
who
signs
it
and
returns
it
back
and
now,
when
the
lawyer
presents
it
to
the
client,
the
client
has
the
law
society's
public
key
and
can
verify
okay.
This
is
the
real
certificate
and
you
can
jam
you
know
any
kind
of
credential
here
you
can
kind
of
jam
as
much
information
as
you
want
into
this.
You
can
add
their
name.
A
You
can
add
some
sort
of
dative
issue,
but
the
last
one
ends
up
being
a
bit
tricky,
because
how
do
you
know
if
this
lawyer
has
done
something?
That
is
bad
lots
of
reasons
this
lawyer
might
be
disbarred
and
if
you're
the
client,
you
know
how
do
you
know
that
this
hasn't
happened
and
your
recourse
really
is?
You
could
maybe
go
to
the
Law
Society
and
say
well:
I've
just
got
the
certificate
from
this
lawyer.
A
Are
they
still
a
valid
lawyer
and
the
Law
Society
says
no
they're
not,
but
now
there's
no
reason
to
use
digital
credentials
at
all.
The
lawyer
can
just
tell
you
I
am
a
lawyer
and
you
can
say
well
what
about
this
person
on
Earth?
Do
they
actually
have
this
license
in
the
Law
Society
just
says
yes
and
digital
credentials
are
kind
of
pointless,
and
this
already
has
its
own
privacy
issues
Society
things
as
soon
as
you
ask
this
that
this
particular
person
needed
a
lawyer
which
is
a
privacy
risk.
A
A
So
what
we
can,
what
these
authorities
can
do
is
they
can
update
their
public
key
event
and,
at
this
point,
I
will
start
calling
it
an
accumulator
and
if
you're
familiar
with
accumulators,
this
will
feel
like
a
very
bizarre
way
to
introduce
and
Define
them.
But
this
is
because,
as
we
worked
on
this,
the
the
function
got
closer
and
closer
to
digital
signatures
and
I
think
a
sensible
way
to
view
them
is
kind
of
a
digital
signature
that
you
just
update
fairly
regularly.
A
So
here
you
know
the
calendar
days
progress
and
they
update
from
one
to
two
to
three
to
four
And,
to
clarify
something
here.
You
can
think
that
revocation
is
handled
in
a
lot
of
cases,
Now
by
say,
expiry
dates.
So
you
issue
the
certificate.
You
say
it
expires
in
2023
and
this
works
in
a
lot
of
cases.
But
let's
say
that
you
have
the
certificate
to
be
valid
for
a
year.
A
Then,
if
it's
a
particular
situation,
where
you
know
a
year,
you
only
have
a
year-long
guarantee
in
which
they
might
have
misbehaved
in
some
way,
and
if
that's
too
infrequent,
then
you
have
a
security
risk
say
your
lawyer
could
be
disbarred
and
they
could
continue
practicing
law
for
another
year
until
their
certificate
expires.
This
is
no
good,
so
you
can
make
that
interval
more
frequent.
A
That
then
your
honest
users
have
to
refresh
their
credentials
quite
a
bit
more
frequently,
so
there's
kind
of
a
trade-off
there
already,
even
just
for
digital
signatures
and
other
methods
of
revocation
such
as
sending
a
list
of
revoke
signatures
kind
of
puts
a
lot
of
work
on
the
verifier.
In
this
case
the
client
verifying
the
lawyer's
credentials
doesn't
want
to
have
to
have
on
their
phone
a
list
of
all
of
the
disbarred
lawyers
ever
so
you
can
the
accumulator
kind
of
helps
with
all
this.
A
You
update
it
every
time
you
make
some
sort
of
change
to
who
has
credentials,
but
it
creates
this
update
problem.
So
in
this
case
the
the
lawyer
has
sent
some
certificate
with
you
before
the
first
accumulator.
The
client
has
the
fourth
accumulator
and
they
think
that's
three
different
accumulators,
in
which
case
this
lawyer
could
have
been
disbarred,
so
they
say:
hey.
A
You
need
to
update
your
license,
and
so
the
lawyer
has
to
interact
with
the
Law
Society
again
and
says:
give
me
an
updated
license
and
the
Life
Society
does
this
and
now
the
lawyer
can
use
their
credential
and
I've
seen
that
finders,
it
should
say
Marge
Simpson,
but
here
you
know,
there's
also
a
bit
of
a
privacy
risk,
which
is
if
the
Law
Society
starts
to
correlate
information
about.
Who
is
verifying
with
these
updates?
A
But
let's
say
that
your
parking
permit
is
anonymized,
so
you
have
your
car
and
you
park
somewhere
and
it
sends
just
a
parking
permit
and
it
tells
you
it's
valid,
but
it's
you
know
it's
completely
untraceable.
The
parking
meter
has
no
idea
who
this
is
great,
but
let's
say
that
the
parking
meter
says.
Actually
you
need
to
update
you
know:
a
bunch
of
people
have
been
driving
badly
and
their
parking
permits
were
revoked,
for
example.
A
So
you
tell
the
police
I
need
an
updated
permit
and
if
you're
not
careful
about
this,
you
kind
of
need
to
send
some
identifying
information
so
that
the
police
know
that
you
actually
what
the
license
is
and
they
can
check
their
database
of
the
licenses
that
have
valid
credentials.
So
they
know
okay.
I
need
to
this.
Is
the
person
to
send
the
parking
permit
to
and
the
the
car
in
this
case
could
still
anonymously
verify
to
the
parking
permit,
but
the
parking
permit.
A
It's
quite
easy
to
imagine
in
this
case
colluding
with
the
police,
because
probably
the
police
are
have
a
pretty
big
say
in
how
they're
run,
and
they
can
simply
tell
them
hey.
Someone
is
updating
a
permit
at
this
parking
meter
at
this
place
at
this
time,
and
since
the
police
have
a
record
of
someone
requesting
an
update
at
exactly
the
same
time,
they
can
say.
Well
almost
certainly
this
license
plate
parked
at
this
place
at
this
time.
A
A
A
If
you
want
to
just
broadcast
data
that
is
not
user
specific
that
users
need
to
update,
you
can
prove
that
it
needs
to
be
proportional
to
the
number
of
changes
since
the
last
update,
and
so
this
is
kind
of
if
your
400
updates
added
400
changes
out
of
date,
it's
going
to
be
100
times
more
data
than
if
you're
four
changes
out
of
date,
and
we
proved
something
even
a
little
bit
stronger,
which
is
an
anonymous
update.
More
generally
has
to
be
equivalent
to
private
information,
retrieval
which
is
generally
hard.
A
The
systems
we
have
now
with
physical
credentials
are
working
fine
and
don't
create
these
privacy
issues
so
lots
of
times
we
don't
the
privacy
issues
that
you
might
be
creating
might
be
worse
for
a
lot
of
people
than
the
maybe
the
convenience
benefits
that
you
would
get,
but
this
is
kind
of
how
I
feel
saying
this
so
I'll
get
into
okay,
you
have
put
your
credentials
on
the
internet.
You
have
made
them
digital.
Can
you
do
this
anonymously?
A
A
The
main
thing
we
want
to
have
is
digital
credentials
with
revocations
they're
at
the
end,
so
that's
kind
of
what
stops
us
from
using
a
digital
signature.
We
want
Anonymous
credentials
and
we
want
the
updates
to
be
oblivious.
We
want
them
to
have
a
low,
client-side,
latency
and
sublinear
Communications.
We
want
to
break
the
communication
lower
bound,
which
we
do
by
simply
requiring
interaction.
A
A
You
have
found
some
Simpsons
characters,
a
business
person
who's
just
in
it
because
they're
being
paid
to
run
this
service,
some
privacy
nerds,
who
are
want
to
make
sure
the
system
is
private.
The
scientist
with
some
spare
server
time,
organized
crime
and
non-disorganized
crime,
so
suppose
there's
some
sort
of
request
to
change
the
accumulator
to
remove
Homer
Simpson.
He
is
not
a
lawyer
should
never
have
been
given
a
license
to
practice
law.
A
A
So
what
are
the
nice
features
about
this?
So
the
secret
sharing
has
this
property
that
not
everyone
needs
to
be
useful
or
honest.
So
if
the
criminals
even
collude
and
they
try
to
figure
out
from
their
sharing
their
their
portions
of
the
data
who
it
is,
it's
not
enough
information
to
break
it.
If
they
decide,
they
don't
want
to
return
any
data
at
all
and
only
the
other
honest
servers
respond.
A
You
know
what
our
system
works.
Everything
is
anonymous,
but
if
you
look
at
the
middle
two,
if
you're
up
updating
from
accumulator
number
two
to
number
four
and
then
someone
else
updates
from
number
four
to
number
six,
that
might
be
the
same
person,
because
we
knew
that
the
first
person
had
an
accumulator
only
up
to
number
four.
So
we
can
imagine
some
malicious
server
starting
to
build
these
pseudonyms
and
pseudonymous
profiles
of
these
updates.
A
A
One
probably
did
this
one
now
this
last
one,
they
can't
actually
completely
de-anonymize,
because
both
user
2
and
user
3
updated
to
the
12th
accumulator,
and
so
then
they're
sort
of,
and
so
this
kind
of
highlights
something
that
needs
to
happen,
which
is,
if
you're
having
these
frequent
updates
and
the
users
are
not
updating
kind
of
in
sync,
then
the
you
can
kind
of
get
this
fine-grained
profile
of
when
their
updates
on
so
our
recommendation
is
basically
scheduled.
Updates
are
critical,
so
here
are
these.
A
So
getting
a
little
bit
more
technical
if
you're
familiar
with
multi-party
computation
at
all,
you
end
up
with
a
lot
of
overheads.
What
we
notice
is
that
accumulators
give
almost
all
of
them
for
free
because
of
this
mathematical
structure
of
it
ensures
the
kind
of
if
let's
say
this
person,
you
know
we
want
to
produce
this
update
this
person
here.
You
know
these
red
arrows
indicate
that
they're
sending
bad
data.
A
You
can
quickly
check.
Was
this
a
valid
update
and
say
no,
and
then
the
parties
can
start
to
look
at
the
communications.
They
had
start
to
break
open
the
the
accumulator
and
figure
out
that
it
was
this
person
who
misbehaved
and
they
can
be
removed
from
the
set
of
servers
that
are
involved.
So
this
is
something
that
we
get
just
from
being
an
accumulator
which
is
nice,
the
actual
technical
details.
So
this
is
derived
mainly
from
Wings
2004
pairing
based
accumulator.
A
These
three
other
works.
Basically,
one
of
them
has
these
update
polynomials
that
we
rely
on
heavily.
Basically,
we
just
evaluate
polynomials,
with
Premier
secret
sharing,
and
that's
how
this
is
done
for
the
update
use
it.
We
use
a
slightly
different
security
assumption
that
we
prove
some
security
Notions,
for
that
also
helps
and
then
sort
of
build
on
multi-party
versions
of
accumulators.
A
We
also
will
have
this
extensive
security
proof
and
also
for
the
user
update.
We
can
save
on
a
lot
of
NPC
overhead,
because
it
only
is
using
these
public
update,
polynomials
and
so
actually
kind
of
the
user
can
act
as
a
trusted
third
party,
and
this
ends
up
still
being
secure
because
the
service
only
ever
interact.
They
only
ever
use
public
data
to
do
the
update.
A
If
you
have
revoked
credentials
with
sparse
Merkle
trees,
you
also
require
update
data
proportional
to
the
number
of
revocations.
Basically,
just
a
nice
efficient
update,
see
impossible.
Digital
signature
is
just
on
their
own
almost
work,
so
you
could
change
the
signature
essentially
with
each
revocation
and
then
everyone
just
gets
a
new
signature
and
the
problem
is:
how
do
you
do
this
anonymously,
so
you
can
even
have
the
server
you
know.
It
knows
all
the
valid
users
to
reissues
the
signature
for
everyone
and
waits
for
them
to
request
it.
How
do
they
do
that
anonymously?
A
Basically,
all
you
could
really
do
with
private
information
retrieval,
but
this
creates
a
server
workload
where
this
Anonymous
user
says
hey.
Give
me
this
credential.
Even
if
the
server
can
do
this
anonymously,
it
requires
a
lot
of
server
computation
and
if
it
has
to
it,
ends
up
being
proportional
to
the
total
number
of
users.
A
It
has
to
do
that
for
every
user
who
requests
an
update,
so
it
ends
up
being
like
potentially
trillions
of
operations,
sort
of
every
change
which
is
untenable,
so
hopefully
I
convinced
you
that
anonymity
and
efficiency,
a
hard
problem
to
compromise
on
protocol,
provides
more
efficiency,
the
main
how
it
accomplishes
this.
It's
basically
multi-party
computation
I,
was
hoping
to
be
able
to
link
to
a
prefront
and
link
to
a
proof
of
concept.
But
we
have
this
massive
UC
style
security
proof
which
is
over
100
pages,
and
it
turns
out.
A
A
No,
so
the
basic
the
thing
is
it's,
so
what
we
end
up
doing
is
so
similar
to
what
was
done
before
you
can
basically
like
it's.
It's
the
same
Olympic
curve
operations,
the
same
finite
field,
operations
and
sort
of
running
the
numbers
should
be
about
a
factor
of
seven
fewer
operations
for
the
user.
If
say,
you're
doing
a
thousand,
you
know
updating
over
a
thousand
updates
and
something
like
a
factor
of
16.
A
A
A
You
could
and
I
suppose
it
depends
on
like
where
this
would
be
useful
is
somewhere
where
you're,
having
kind
of
a
high
flux
of
credentials
like
credentials,
are
frequently
being
issued
and
they're
frequently
being
revoked
so
and
something
where
verifiers
don't
want
to
have
to
keep
a
list
of
all
the
revoked
credentials.
This
is
kind
of
the
thing
we're
trying
to
avoid.
So
my
sense
on
this
is
that,
with
you
know,
internet
certificates.
This
is
not
the
case
that
they're
being
revoked
not
frequently
enough
for
this
to
be
a
computational
problem.