►
From YouTube: Building Secure Protocols Using Ursa - Mike Lodder, Sovrin Foundation & Brent Zundel, Evernym
Description
Building Secure Protocols Using Ursa - Mike Lodder, Sovrin Foundation & Brent Zundel, Evernym
It's notoriously difficult to properly implement blockchain protocols that use cryptographic algorithms.In this talk, Mike and Brent will explain some of the features in Hyperledger Ursa and how to use them to solve some of the most common problems faced by people looking to build private and secure protocols on blockchains.
They will start by explaining some of the cryptographic primitives in Ursa and what they do from a functional perspective.Then, they will illustrate how to use them through their own work in Indy and Aries.They will offer advice to others and other tricks on how to develop blockchains with specific security, privacy, and confidentiality requirements.This will include things like designing a security model, picking the right cryptographic tools, and then implementing the blockchain project in a way that minimizes bugs and security vulnerabilities during development.
Mike and Brent will also discuss some of the common mistakes that they have seen people make when using cryptographic algorithms and how to develop in a way that avoids these mistakes.
This talk is targeted at developers with some experience in working with cryptography or security-related code.It is not necessary to be an expert cryptographer or experienced security professional, but some basic knowledge of cryptographic protocols will be needed to get the most out of this talk.
----
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
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 #HyperledgerGlobalForum2020 #Blockchain
A
A
So
that's
a
little
bit
about
me
and
how
I
got
involved
with
ursa
was
I
was
with
hyper
ledger
in
D
and
then
ares
and
then,
when
those
ursa
got
spun
off
I
kind
of
went
with
that
route,
because
I
was
working
with
all
of
the
security
layers
in
Indy
and
nurses
start
off
with
a
lot
of
the
original
code
from
Indy,
and
now
it's
an
Ursa
for
everybody
else
to
use
so
I'm
a
maintainer
in
Ursa,
but
I
also
contribute
to
Indy
and
Ares
quite
regularly.
My.
B
Name
is
Brent
I
work
for
Evernham
I
do
cryptographic
protocols,
privacy
is
my
main
interest
and
my
main
concerns
I
do
some
software
architecture
and
they
also
shoved
me
into
standards.
Development,
I,
don't
know
what
that
says
about
how
much
they
like
me,
but
in
addition
to
doing
some
Ursa,
maintaining
and
hyper
ledger
contributing
they've
got
me
working
at
the
w3c,
we're
working
on
decentralized
identifiers
and
verifiable
credentials
and
all
sorts
of
fun
things.
B
Alright,
we're
gonna
talk
about
a
few
things,
mostly
we're
gonna,
be
plugging
Ursa
and
why
you
should
be
using
it
and
why
you
shouldn't
be
using
some
other
things
to
start
off.
Ursa
is
a
common
crypto
library.
It's.
It
was
spun
out
of
Indy,
but
it
is
common
code
and
it's
intended
to
be
used
by
any
hyper
ledger
project
that
can
and
any
project
outs
have
a
hyper
ledger
that
wants
to
it's.
It's
open
source.
It's
public
Ursa,
is
a
combination.
B
The
collection
of
well
vetted
algorithms,
we're
not
inventing
new
crypto
we're
taking
papers
that
have
been
well
reviewed
and
analyzed
and
implementing
them
so
that
people
can
use
the
techniques
that
are
too
bribed
there.
They
were
implemented
by
people
who
have
been
trained
to
implement
cryptographic,
algorithms
and
protocols.
B
B
Right
some
of
the
things
you
can
do
with
ursa.
You
can
encrypt
things.
We
can
do
integrity
protection,
you
can
do
digital
signatures,
we
can
do
really
fun
stuff
like
verifiable
and
anonymous
credentials.
We
have
zero
knowledge,
proof
stuff
that
we're
building
in
there
ZK
snarks
and
bulletproof
sand,
all
sorts
of
really
fun
cool,
cutting-edge
leading-edge
cryptographic,
things.
A
Okay,
so
first
rule
of
crypto
is
don't
roll
your
own
crypto
I,
don't
know
if
you've
heard
that
a
lot,
but
we'll
be
preaching
that
you
should
never
try
and
do
this
yourself
I
like
to
think
of
it
as
you're
doing
surgery
at
your
house
and
how
many
of
you
would
ever
try
to
attempt
that
it's
very
dangerous.
Even
for
those
that
know
what
they're
doing
so,
don't
try
and
do
it
yourself
and
given
how
many
security
attacks
and
things
happen.
A
You
know
that
it's
just
plain
hard
to
do
it
right
in
the
first
place,
and
so
one
of
the
great
things
about
nurses,
we
try
to
aggregate
all
of
that
one
place.
These
are
some
common
things
that
typically
happen.
If
you're
trying
to
roll
your
own
crypto
libraries,
you
can
just
implement
it
completely
wrong
or
you
accidentally
expose
your
the
private
keys
in
some
side.
Channel
attack
or
the
crypto
analysts
find
something
wrong
with
the
math
that
you've
written
your
yourself.
It's
just
weak
at
the
math
layer.
A
So
don't
ever
try
and
do
it
yourself
always
do
it
under
trained
professionals,
and
the
thing
is,
if
you're
designing
crypto.
We
hope
that
you
have
a
PhD
in
cryptography
or
you
are,
or
you
consider
yourself
a
cryptographer
and,
if
you're
implementing
it
and
don't
consider
it
production
ready
until
it
has
been
peer
reviewed
by
many
other,
especially
with
the
cryptographer
that
rode
it
or
invented
it.
A
That's
very
important
to
know-
and
things
still
can
go
very
wrong
when
you
know
what
you're
doing
so,
I
mean
Apple,
for
example,
had
two
known
attacks
and
they
think
of
the
resources
that
Apple
does
when
its
employing
and
writing
cryptography.
So
it
had
an
attack
with
iMessage,
where,
even
though
they
were
employing
state-of-the-art
crypto,
an
attacker
could
still
insert
himself
and
decrypt
all
of
your
AI
messages
or
with
their
file
decryption
encryption
library
call
Aaron
krypter,
which
they
have
now
fixed,
even
though
they
were
encrypting
it
using
a
secure
algorithm.
A
An
attacker
could
still
just
safely
decrypt
the
file,
even
though
it
was
safely
protected
right.
So
the
thing
is
yeah.
What
did
I
skip
we'll
slide?
Yeah
there
we
go.
So
if
you
look
at
these
other
libraries,
some
of
them
they've
tried
to
invent
their
own
crypto
and
others.
They're,
just
they've
been
widely
used
and
they
still
have
things
that
have
gone
wrong.
So
a
real
crypto.
A
This
year
they
were
really
harping
on
the
Moscow
internet
voting
system,
which
they
just
deployed
where
cryptographers
were
advising
them,
there's
insecurities
in
what
you've
designed
don't
do
it
and
they
went
forward
with
it
anyway,
hoping
that
their
votes
can't
be
tampered
with.
But
anyway,
things
happen.
You,
the
u2f,
phyto
version
one
had
a
bug
where
it
allowed
backdoors,
even
though
it
was
reviewed
and
extensive
leave
reviewed
by
those
in
the
security
space
I
mean
you
can
look
at
Intel
as
hard
as
they've
tried
things
happen
so
iota
and
their.
A
Is
that
there's
a
lot
of
resources
devoted
to
this
space?
We've
got
cryptographers.
We've
got
people
that
have
just
been
working
in
it
for
a
long
time,
so
we
always
state
the
IRS's
trying
to
do
cryptography
the
correct
way
in
that
we're
not
rolling
anything
new.
We
are
taking,
what's
been
well
vetted
and
we
are
implementing
it
with
trained
professionals
under
a
train
system
that
hopefully
should
limit
badness.
B
Ursa
is
very
visible:
it's
an
open
source
library.
Anybody
can
look
at
the
code.
Anybody
can
read
the
papers
of
that.
The
codes
based
on
we
invite
this
visibility,
because
visibility,
equals
security
and
and
we're
aiming
for
us
would
be
as
secure
as
possible,
discovering
vulnerabilities
in
libraries
a
good
thing.
That
means
people
are
looking
at
it.
B
That
means
people
are
using
it
as
long
as
those
vulnerabilities
are
then
addressed,
every
crypto
library
is
going
to
have
some
vulnerability
somewhere
and
Ursa
is
set
up
so
that,
on
the
first
hand,
where
we're
trying
to
you
know
avoid
those
and,
on
the
other
hand,
when
they
come
up,
we
have
the
infrastructure
in
place
to
deal
with
them
process.
Projects
that
use
Ursa
can
benefit
from
this.
You
don't
have
to
create
a
signing
algorithm.
You
can
use
the
one,
that's
already
been
implemented
and
vetted.
B
All
right,
so,
if
you
use
Ursa
and
you're
hyper
larger
projects,
you're
going
to
have
a
higher
level
of
trust
and
security,
one
of
the
reasons
is
because
Ursa
is
written
in
rust.
For
those
of
you,
who's
used
rust
before
right,
rust.
It's
awesome.
One
thing
that's
nice
about
rust
is
that
it
is
secure.
It
was
designed
from
inception
to
be
memory
secure.
All
of
those
horrible
problems
that
are
still
happening
today,
because
of
C
code
are
impossible
to
do
in
rust.
The
language
won't,
let
you
buffer
overflow
and
it
won't.
B
Let
you
leave
memory
just
hanging
out
there
for
anybody
to
read
it's
also
portable.
You
can
compile
it
so
that
all
of
these
programs
that
rely
on
legacy
C
code
could
just
swap
out
and
use
use
something
written
in
rust,
servers,
desktops,
mobile
and
rust,
because
it's
a
lower
level
language
allows
it
to
run
very
quickly.
B
When
you're
vetting,
crypto
I
love
that
we
used
crypto
this
entire
time
and
everybody
just
knows
we're
not
talking
about
money,
sorry
or
other
things,
yeah
pseudo
money.
What
algorithms
does
it
support
who
wrote
it?
Has
it
been
audited
who's
using
it?
If
you
want
to
grill
someone
who
claims
that
these
things
are
safe,
ask
them
things
about.
Is
it
constant
time?
Does
it
side
channel
resistant?
B
Are
all
things
that
we
have
done
our
best
to
ensure
are
in
place
in
ursa
I?
There's
an
analogy
to
this.
A
friend
of
mine
is
a
tattoo
artist
and
she
is
often
asked
how
long
she
has
been
tattooing
people
and
every
time
she's
asked
this.
She
says:
that's
the
wrong
question,
because
there's
a
guy
down
the
street
he's
been
open
for
15
years,
but
he
only
does
one
tattoo.
Every
six
months,
she's
I've
been
open
for
four
and
I've
done
more
than
a
thousand
tattoos.
So
there
are.
B
There
are
important
questions
you
need
to
ask
if
you
are
using
ursa.
Does
that
mean
you're
secure?
This
depends
on
how
you
think
about
security.
It's
important
as
you
develop
your
protocol
and
determine
what
cryptographic
tools
you
might
make
use
of
that.
You
change
your
mental
model,
away
from
what
the
tools
guarantee
to
what
your
protocols
can
guarantee
so
saying
things
like
hey
we're
good,
because
everything
is
encrypted
with
128-bit
security
from
Ursa.
Okay,
that's
great!
But
if
you're
not
using
it
correctly,
you're
still
not
going
to
have
a
secure
system
as.
B
B
You
can
send
their
private
information
fully
encrypted
and
only
the
person
that
you're
sharing
their
private
data
with
can
get
it.
That's
not
that's
not
either.
One
of
these
is
not
a
full
answer,
so
you
need
to
design
a
system
that
meets
your
definition
of
what
privacy
and
security
you're
aiming
for
and
then
do
your
best
to
prove
that
you've
met
that
threat
model.
One
example
we
are
often
asked
is
Ursa
fips-compliant
and
we
have
to
say
what
do
you
mean
by
fits
compliant
because
there's
different
levels
as
it
compliance?
Is
it
validated?
B
Have
the
components
been
validated?
Is
it
using
computed
validated
components
and
practices?
Is
it
using
only
the
approved
algorithms?
Has
it
been
NIST
certified,
at
which
level
these
are
all
concerns,
and
when
most
people
like
well
I,
don't
know
we're
like
well.
Phipps
validation
is
something
that
well
no
hyper
leger
project
is
Phipps
validated.
That
way.
No
of
that
we're
aware
of
there
are
movements
toward
that,
and
Phipps
certification
is
certainly
a
good
thing,
but
they're
asking
this
question
isn't
possibly
the
most
useful
of
questions
you
need
to
do
some
threat
modeling.
B
This
is
just
an
example
here
you
say:
okay,
here
are
the
possible
threats
that
we're
concerned
with
here's
the
damage
that
we
estimate
they
could
do
and
the
probability
of
those
those
attacks
actually
happening
so
ransomware,
potentially
very
damaging.
You
know
25
percent
probability.
We
pulled
these
numbers
out
of
nowhere,
so
this
does
not
represent
reality
in
any
way,
because
every
project
has
its
own
threat
model,
for
example,
something
like
a
smash-and-grab.
B
They
come
in,
they
steal
some
stuff,
they've
done
a
lot
of
damage.
It's
pretty
unlikely
that
that's
going
to
happen,
so
you
multiply
the
possible
damage
by
the
assumed
probability
and
you
get
this
risk
score.
This
helps
you
to
know
what
to
focus
on.
It
also
helps
you
to
if
the
threat
modeling
is
also
kind
of
an
interactive
process,
because,
depending
on
the
library
that
you
use
and
the
capabilities
that
enables
some
of
these,
things
might
not
be
as
damaging
and
we're
actually
going
to
talk
about
that.
A
little
bit.
Okay,.
A
So
the
idea
of
when
you're
designing
protocols
is
to
limit
the
risk
that
you
are
willing
to
take
so
there's
different
things.
You
can
do
most
people
just
want
to
mitigate
the
risk
right.
You
don't
want
to
pass
off
to
somebody
else
unless,
unless
you
can
afford
it,
that's
usually
an
insurance
thing,
so
you
either
have
to
say
I'm,
not
gonna,
be
in
this
space
at
all
or
I've
got
to
mitigate
it
or
I'll,
just
assume
the
risk.
So
most
people
don't
want
to
just
assume
the
risk
they
want
to
reduce
it.
A
So
one
of
the
things
you
can
do
with
hersa
is
this
idea
of
anonymous
credentials.
Where
and
I'll
show
you
some
examples
later,
where
you
can
push
the
data
out
to
the
clients
or
the
end-users,
and
you
don't
have
to
assume
that
liability
yourself
and
the
protocols
that
you
can
design
with
it
and
they
believe
privacy.
They
enhance
privacy
by
reducing
correlation.
So
just
because
I'm,
an
anonymous
person
that
shows
up
at
the
gym
every
day
it
doesn't
mean
that
they
know
hey.
It's
the
same
person
every
single
time
right
because
of
my
behavior
patterns.
A
A
I
absolutely
need
to
do
my
business
if
I
could
push
the
rest
of
it
out
to
the
edge
or
somewhere
else,
and
it
would
still
be
trusted
well
and
high-quality.
Then
that
helps
limit
my
liabilities
if
this
data
were
to
be
stolen.
So
one
way
we
do,
that
is
using
anonymous
credentials
and
zero
knowledge
proof
which
is
verifiable
credential.
You
can
think
of
it
as
in
your
driver's
license
or
in
your
wallet.
You
have
different
credentials
that
do
different
things
and
you
use
them
in
a
specific
way.
A
Okay,
so
in
today's
world
this
is
kind
of
how
credential
systems
flow
right,
I
go
to
a
bank
or
some
business,
and
they
asked
me
to
create
an
account
which
is
a
pain
in
the
butt,
because
now
I
have
to
keep
track
of
yet
another
username
and
password,
and
also
give
my
data
to
yet
another
company
another
copy.
And
then
they
store
that
information
and
then
there's
the
two
types
of
people
that
can
actually
access
it.
You
have
a
curious
but
honest
person,
maybe
it's
their
part
of
their
job,
but
maybe
they're.
A
Just
in
the
business
they're,
a
system
administrator
and
they're.
Just
looking
at
the
data,
they
can
see
it,
regardless
of
how
it's
being
encrypted
right.
The
the
security
is
there,
but
the
privacy
may
not
be,
and
then
there's
the
malicious
person
who
hacks
in
and
steals
that
information,
even
though
it
was
protected.
He
happened
to
get
in
through
a
secure
channel
vulnerability
that
may
have
been
there
and.
B
A
Yeah
I
mean
you
rarely
see
that
attacker
breaks
in
to
mom
and
pops
flower
shop
because
they
have
very
very
few
accounts.
They
go
for
the
big,
high-value
targets
that
have
millions
upon
millions
of
information
that
can
be
stolen,
okay,
so
here's
one
example
of
how
Earths
is
being
applied
in
India
Nerys
here
at
a
hyper
ledger,
so
we've
kind
of
talked
about
anonymous
credentials.
But
in
this
scenario
the
main
thing
that
they're
interested
in
when
you
log
in
is
they
wanna
know.
A
Are
you
the
same
person
that
visited
me
last
time
and
then,
if
you
are
I
need
to
know
which
data
belongs
to
you,
so
that
I
don't
accidentally
share
somebody
else's
and
violate
their
privacy?
That
would
be
bad.
So,
in
order
to
do
that,
we
need
to
know
who
you
are
and
what
you
need
from
us.
What
services
are
you
gonna
be
asking
for
right
when
you're
logged
in
okay,
so
an
anonymous
credential
system?
Here's
what
you
would
do
you
would
typically
create
an
account.
You
would
give
them
their
you.
This
is
one
example.
A
You
don't
have
to
do
it
this
way,
but
there's
some
information.
That
is
exchanged
so
in
this
case
I
just
said:
ok,
the
person's
creating
account
they're
gonna,
give
them
their
first
name,
the
last
name
and
all
the
other
information
they
did
before.
But
now
the
company
instead
just
stores
a
unique
identifier
and
signs
a
credential
that
they
then
give
back
to
that
person.
So
you
notice
they
didn't
store
anything
about
the
person.
All
of
that
got
pushed
to
the
edge
in
this
simple
scenario
and
a
unique
identifier
is
how
this
person
shows
up
again.
A
They
know
who
it
is,
and
you
might
say
well
how
does
that
work
when
they
go
to
present
so,
for
example,
maybe
after
they
issued
the
credential,
the
company
says:
hey,
we
could
do
a
lot
more
business
with
you
if
you
would
share
your
phone
number
and
give
us
consent
to
store
that,
and
so
they
say
great
I'll
just
share
it.
In
this
case,
let's
say
it
happens.
Sometime
later,
they
say
I'm
going
to
share
a
proof.
A
This
is
the
credential
you
gave
me,
but
the
only
thing
you
get
to
see
is
the
unique
identifier
and
a
phone
number
and
they
can
verify
it
because
they
signed
it,
but
the
honest
but
a
curious
system
administrator
now.
The
only
thing
he
sees
is
there's
a
unique
identifier
and
some
phone
number
and
that's
all
the
thief
can
get
at.
Is
this
limited
subset
of
data?
But
then,
let's
say
the
person
wants
to
now
go
use
this
service.
A
They
just
need
to
sign
in
and
in
order
to
do
their
transactions
or
whatever
the
case
may
be.
I
want
look
at
my
bank
account
or
my
data
analytics,
and
in
this
simple
scenario,
the
only
thing
they
have
to
prove
is
that
they
have
one
of
these
credentials
that
the
company
gave
them
and
nothing
else
is
disclosed,
even
though
they
signed
a
whole
bunch
of
other
information
in
there
they're
just
saying:
I
am
XYZ,
CABC
and
they're
in
and
that's
how
it
works.
So.
B
First,
it
makes
that
possible.
Aires
makes
it
a
little
easier
to
use
us
to
differentiate
between
these
different
projects.
So
India
is
the
the
backbone.
Each
of
them
has
an
Ursa
component
in
there,
so
the
full
system,
so
the
in
the
Indian
areas,
portions,
are
running
Ursa.
The
companies
rely
on
Indy
as
the
blockchain
backbone
to
store
the
public
keys
and
then
Aires
packages
up
the
communication
so
that
it's
private
and
allows
for
an
interoperable
wallet
to
store
the
keys
and
the
credentials
that
both
the
company
and
the
end
users
can
make
use
of.
A
Okay,
so
if
I
had
to
say
this
is
what
you
should
learn
from
this
talk
is
don't
design,
for
these
are
the
encryption
algorithms
I'm
using
and
we're
going
to
be
secure.
You
need
to
think
about
what
are
my
guarantees
that
I
absolutely
need
for
my
system
and
then
pick
the
tools
and
the
processes
to
help
you
implement
that
system
in
your
protocols,
so
the
tools
that
you're
picking
should
definitely
be
peer
reviewed.
A
They
should
be
standard
ones
that,
hopefully
others
are
using
and
not
homegrown
in
your
own
companies
and
then
definitely
ask
help
from
people
that
have
been
in
the
space
and
they're
considered
experts
and
by
all
means
please
use
ursa
so
that
you
already
know
one
library
that's
been
doing
that.
So
any.
A
Nurses
API,
it
was
designed
to
be
a
user
friendly.
That
being
said,
whoever
is
going
to
be
using.
It
needs
to
have
some
security
experience
right.
They
need
to
know
this
is
an
encryption
algorithm,
that's
protecting
my
stuff
and
not
assigning
algorithm,
so
they
will
need
some
security,
but
as
far
as,
if
I
pick
it
with
this
and
this
and
this
and
these
combinations
is
that
going
to
be
secure.
A
lot
of
that's
been
taken
care
of,
so
it's
just
easy
to
use
and
misuse
resistant
and.
B
D
B
B
A
If
you're
returning
keys
back
from
rust
into
your
go
code,
that's
that's
a
different
story,
for
example
you're
in
charge
of
that,
but
one
of
the
word
to
pick
language
to
develop,
or
so
the
reason
we
chose
rust
was
one.
There
was
all
those
things
that
Brent
mentioned
earlier,
but
to
the
portability
rust
does
compile
to
a
C,
callable
library
and
most
lot
most
other
languages
can
use
that.
So
we
would
write
once
and
everybody
else
could
use
it
without
having
to
implement
at
10
or
20
different
times.
But.
E
E
A
D
B
I,
don't
think
we
have
any
plans
at
this
point,
but
if
people
want
to
jump
in
and
propose
that
as
a
way
forward,
we
have
a
call
once
a
week
where
we
talk
about
the
direction
that
erse
is
gonna,
go
the
joy
of
being
an
open
source
project.
Is
that
if
there's
interest
for
enough
for
people
to
do
that
and
build
that
I
mean
one.
A
Thing
we
are
working
on
is
secured
keys
like
a
common
API.
If
you
wanted
to
interact
with
multiple
different
Hardware
enclaves,
or
did
we
wouldn't
be
abstracting
away
the
hardware
enclaves
themselves
in
the
sense
that
you
know
what
you
don't
know,
what
you're
getting
under
the
hood,
it's
more
like
if
I
want
to
design
for
an
Intel,
SGX
or
arm,
then
I
can
use
the
same
code
because
the
API
looks
the
same
and
then
I
can
get
the
attestations
and
the
guarantees
outside
a
vs..
A
Somehow,
but
at
least
there's
some
common
libraries,
so
I
mean
it's
that's
probably
about,
as
close
as
you
would
think,
a
lot
of
the
security
protocols,
those
will
those
are
in
the
Ursa
in
terms
of
for
step,
one
to
talk,
somebody.
How
do
I
do
that
and
how
they
tell
me.
What
are
they
supposed
to
send
back
and
those
kinds
of
things.
D
B
Openssl
have
you
ever
seen
the
Swiss
Army
knife?
That's
like
that
big
and
doesn't
actually
fit
in
your
pocket
anymore.
That's
the
esses!
That's
the
OpenSSL
model!
We
want
to
be
able
to
do
everything
in
every
way
and
allow
people
to
configure
things.
However,
they
want
and
ursa
attempts
to
be
much
more
constrained,
so
there
is
less
of
an
opportunity
to
shoot
yourself
in
the
foot
when
you
use
it.
A
Thing
is:
there
are
certain
things
that
s
OpenSSL
does
not
do
like.
It
does
not
do
the
verifiable
credentials,
it
doesn't
do
zero
knowledge
proof
and
it's
written
in
C,
and
if
you
want
to
compile
it,
you
have
to
have
a
Perl
interpreter.
So
if
you
don't
want
a
Perl
interpreter
and
a
C
compiler,
then.
A
So
we
do
attempt
to
document
what
those
features
are
and
the
guarantees
around
them
so,
for
example,
anonymous
credential
signatures.
Some
of
them
have
been
around
since
2001
and
they've
been
well
vetted.
Some
of
them
are
a
little
newer
like
2012,
and
we
do
reference
those
and
rfcs
and
the
papers
about
kind
of
the
guarantees
you
get
using.
If
you
want
to
use
these,
does
that
help?
Okay,
yeah
I
just.
B
A
D
A
We're
very
we're
very
aware
of
those
so
Hart
Montgomery
back.
There
is
a
cryptographer
that
he
attends
he's
part
of
the
air
sick
committee.
He
specializes
in
post
quantum.
Is
that
correct
to
say
heart
or
might
just
throwing
you
on
the
spot?
Yeah?
Okay.
So
that
being
said,
we
do,
we
probably
have
talked
about
it
at
least
half
a
dozen
times.
A
So,
if
you're
concerned
about
quantum
security
post
quantum
security,
you
can
definitely
try
to
figure
out
what's
the
best,
but
the
thing
is:
there's
still
the
competition
about
what
should
be
approved
and
what
isn't
I
mean?
Even
this
doesn't
know,
what's
the
best
way
to
protect
against
that
yet,
and
so
when
they
decide
what's
best,
then
that's
when
we
were
gonna
take
another
stab,
and
that
should
finish
sometime
this
summer
right
Hart.
C
A
Yeah
so
I
mean,
if
you're,
if
you're,
that
nervous
about
it.
One
thing
I
we've
suggested
to
people
is
use.
The
current
crypto
system
that
you
know
is
tried-and-true
and
then
pick
a
quantum
one
that
some
security
experts
recommend
use
them
both
at
the
same
time
and
then,
if
a
quantum
computer
actually
becomes
feasible,
then
you
know
even
dating
back
to
whenever
this
was
done,
there's
the
quantum
way
which
was
safe
and
a
lot
of
the
algorithms
we
used.
Some
of
them
could
be
broken
when
quantum
comes
out.
A
Some
of
them,
probably
won't
be
so
like,
for
example,
is
ear
knowledge
proofs.
If
a
quantum
computer
out,
they
would
not
be
able
to
reverse
the
proofs
that
have
already
been
generated,
so
those
are
considered
quantum
resistant
unless
an
algorithm
was
invented
that
could
reverse
those
but
new.
What
new
proofs?
You
would
not
be
able
to
trust
because
they
could
be
forged.
I
guess.
B
To
sum
up,
we're
doing
the
research
to
try
to
figure
out
which
direction
to
head
as
far
as
post
quantum
goes.
The
goal
with
Ursa
is
that
when
it
becomes
a
problem,
implementers
should
be
able
to
seamlessly
swap
it
out
because
you're
you
should
have
written
it
to
the
same
interface.
So
you
use
the
same
front-end
interface.
On
the
back
end,
you
can
use
the
new
fancy
post
quantum
stuff
that
isn't
we've.
A
So
the
zero
knows
proofs
would
currently
support
is
doing
zero
knowledge
proof
for
set
memberships
is
something
in
a
set,
is
something
not
in
a
set?
Is
something
in
a
range
between
an
x
and
a
y
selective
disclosure
which
is
what's
used
by
anonymous
credentials
in
terms
of
adding
new
ones
for
like
nimble,
Wimble,
probably
not
minimal.
Wimble
we've
definitely
been
looking
at
snarks
and
smart.
A
A
What's
the
purpose
of
it,
so
we
are
still
evaluating,
which
snarks
makes
sense
to
do
bullet
proofs
are
already
in
their
bulletproof.
Four
four
set
memberships
and
ranges
are
already
in
there
and
part
of
the
reason
we
went.
That
route
is
there's
no,
if
you're
ever
familiar
with
snarks,
they
have
what
we
call
a
trusted
setup
problem,
which
means
you
have
to
trust.
Whoever
created
this,
it's
the
same
issue
with
some
of
other
crypto
primitives,
but
with
bulletproof.
We
don't
have
that
yeah.
B
So,
with
the
zero
knowledge
proof
technology,
especially
the
circuit,
based
technologies,
where
we're
aiming
for
that
middle
ground
of
cool
and
functional,
but
also
still
useable,
you
know
it
was
as
awesome
as
Z
caches.
It's
one
of
my
favorite
projects.
It
it
took
years
it's
taken
years
for
their
zero
knowledge,
proof,
ZK,
snarks
library
to
actually
be
efficient
enough
to
be
usable
regularly.
D
A
A
B
And
communication,
because
a
lot
of
the
projects
haven't
jumped
in
and
said,
hey:
if
Ursa
did
this,
then
we
would
did
we
would
use
it.
You
know
it's
that
did
this
answer
that
we
would
love
to
implement.
We
would
love
it
for
it
to
be
the
primary
cryptographic
capability
of
all
of
the
hyper
little
projects
that
it's
kind
of
the
goal
of
it.
I.
A
Mean
like,
for
example,
Indy
hasn't
been
100%
owner,
so
it's
using
a
lot
of
versa,
but
there
are
some
features.
It
says:
hey.
If
you
just
added
this,
then
we
could
use
it
for
everything
they're,
the
only
ones
that
have
openly
said
that
none
of
the
other
projects
have
said
hey
if
it
supported
this
I
would
use
it
it's
more
like
what
do
I
need
to
do
to
get
it
in
there,
so
the
API
is
are
pretty
stable
and
the
tool
is
pretty
stable
in
terms
of
using
it.
A
They
just
need
to
take
the
time
to
do
it.
So,
like
I
said
there,
there
have
been
a
few
others
that
are
using
it
already,
but
part
of
the
reason
we
moved
a
lot
of
the
crypto
code
into
Ursa
was
so
it
could
be
broadly
adopted.
The
zero
knowledge
proof
stuff
is
probably
the
most
value.
Add
that
people
want.
A
That
would
probably
help
because
none
of
us
are
go
experts,
I've
coded
and
go
in
the
past,
but
I
haven't
touched
it
in
a
while
and
I'm
sure
the
language
has
moved
on
since
I
last
touched
it
because
most
languages
don't
say
stable
or
stay
static,
so
go
binding
would
be
another
one.
I
know:
Python
is
a
big
popular
one,
but
usually
those
that
already
see
callable
like
the
dynamic
languages
like
Ruby
and
Python.
It
just
works
and
node.js,
but
yeah
Sego
is
a
little
more
I.
Think
involved.
D
A
To
get
it
audited
in
terms
of
what
just
an
outsider,
to
like
another
firm
to
just
look
at
the
algorithms
to
say:
hey
everything
looks
good,
so
we
have
had
quite
a
few
cryptographers.
So
a
lot
of
zero
knowledge
proof
in
terms
of
credentialing
was
the
cryptographer.
His
name
is
Yan
commish.
He
currently
works
at
de
fin
de
used
to
be
at
IBM.
His
team
has
looked
at
those
algorithms
and
found
very
little
like
low-risk
things
that
we've
already
fixed
net
it.
A
Is
it
an
attitude
or
net
I
can't
remember
it
has
looked
at
it
and
audited
some
things
and
we've
fixed
those
so
and
then
some
of
the
other
cryptographers
dmitriyevich
is
as
vetted
it
heart
frequently.
Whenever
we
write
the
crypto
code,
we'll
sit
down
and
review
it
with
us
to
make
sure
we
haven't
done
anything
stupid.
So
in
terms
of
that
yeah
in
terms
of
a
formal
review,
it
depends
on
what
you're
looking
for
to
just
say:
there's
nothing
insecure
in
it.
Well,
it
depends
on
what
model
are
you
trying
to
design
against
so
is?
A
Are
all
the
libraries
secure
against
backdoors?
Great
yeah?
That's
you
know
we
can
audit
that
right
now,
if
you
wanted
a
lot
of
security
reviews
are
quite
expensive
and
so
any
company
that
wants
to
pony
up
a
couple
thousand-
you
know
ten
thousand
dollars
or
thirty
thousand
dollars
to
do.
The
audit
great
we'd
be
totally
involved
with
that,
but
they
are
quite
expensive
and
time-consuming
to
do
so.