►
From YouTube: IETF103-CFRG-20181105-1120
Description
CFRG meeting session at IETF103
2018/11/05 1120
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
A
C
E
E
So,
let's
so
I'm
alexi
and
my
co-chair
kenny
is
not
here,
so
maybe
he's
present
online.
Let's
do
a
quick
agenda
bashing
just
to
double-check,
so
I'll
talk
about
status
of
documents
and
a
few
other
things
then
we'll
have
three
presentations
on
three
active
working:
two
active
working
group
documents
and
one
potential
research
group
document.
E
E
I'll
quickly
talk
about
document
status,
so
at
the
moment
we
don't
have
any
artsy's
published
since
last
ITF
no
documents
in
RFC
editor
skill,
but
chairs
mostly
clear
the
backlog
of
Shepards
review.
So
far
we
have
two
documents
in
IRS,
G
review,
McGrew
hash
signatures
got
one
IRS
G
review.
The
comments
were
addressed,
so
this
is
now
waiting
for
fully
irst
review
and
the
king
is
waiting
for
initial
irst
review.
E
We
have
three
documents
nearly
done
aspect
to
waiting
for
Shepherd
serve.
You
can
agree
to
review
the
document,
so
hopefully
he
will
do
this.
I
think
you
said
about
a
month,
so
that
should
happen
very
soon.
The
other
two
documents
they're
currently
expired.
We
send
comments
to
document
editors.
They
are
revising
documents
based
on
feedback,
so
hopefully
this
will
be
updated
soon
and
then
we'll
send
them
to
Irish
give
review,
and
at
the
moment
we
have
four
active
documents:
we'll
have
presentations
of
cup
on
a
couple
of
them
on
hash.
The
curve
and
randomness
improvements.
E
E
E
Hopefully
we'll
come
up
with
a
single
back
out
of
this
process.
It
should
follow
our
Etsy
8125
with
which
set
some
requirements
or
requirements
on
documentation.
That
was
already
done
in
this
research
group
suggestions.
How
how
to
go
about
this
process
are
very
welcome.
Please
send
them
directly
to
chairs
what
kind
of
questions
you
think
we
should
ask
when
we're
working
on
elliptic
curves,
we
were
asked
asking
questions
to
help
narrow
down
on
specific
choices.
F
E
E
F
B
B
E
Ii
right,
so
that's
a
good
question,
so
I
haven't
consulted
with
Kenny
my
opinion
that
begs
that
will
already
published
as
RFC.
They
sort
of
you
know.
Obviously,
I
don't
have
a
time
machine.
I
cannot
go
back,
so
they
already
done
whether
we
can
select
one
of
them
and
recommend
it
again
as
the
result
of
the
selection
process.
That
might
be
so
I
I,
don't
know,
I
don't
want
to
prejudge
the
results.
We
don't
know
yet
so
yeah
I
think
it's
a
good
question.
We'll
need
to
think
about
that.
Thank
you
very
well.
Thank
you.
I
Paul
Hoffman,
who
I
think
this
is
the
first
time
I've,
come
to
the
mic
to
agree
with
Steven
Ferrell,
but
going
to
with
what
you
just
said.
If
the
result
of
this
is
going
to
be
a
document
that
simply
says,
we
think
that
thing
is
the
best
one
or
that
one
with
certain
things
or
none
of
them.
That's
just
fine,
but
I
haven't
heard
before
this,
that
this
is
going
to
be
a
separate
document
or
decision
or
whatever
and
I.
Don't
know
how
that
works
in
a
research
group,
but
I
know
that
P
I,
don't.
I
H
Hi,
rich
salsa,
I
I,
know
you.
This
is
more
time
than
you
wanted
to
spend
on
this.
The
parallel
I
draw
is
we
had
lots
of
elliptic
curves
before
and
we
were
able
to
pick
a
few,
a
small
number
that
we're
like
these
are
the
ones
we
want,
and
it
seems
to
me
that
the
pake
situation
exactly
parallel
to
this.
So
there's
a
sort.
That's.
E
J
Good
morning,
everyone,
mrs.
posh,
laughs
crypto
pro,
and
this
is
a
status
update
for
randomness
improvements
for
security
protocols.
Draft
is
a
joint
work
with
SkyScreamer
sluggard,
Nick,
Sullivan,
Christopher
wood.
So
a
quick
reminder
what
what
is
about
the
motivation
has
been
the
following
that,
since
we
may
have
some
problems,
we
Spearin
G
such
bugs
backdoors.
Some
problem
space
hardware
are
energies
that
are
used
to
initialize
the
initial
state
of
Piran
G
and
the
sample
nner
abilities
joint
entropy
pools.
J
So
we
might
want
safety
net
to
avoid
system
compromise,
so
some
backup
for
all
Pyrenees
and
to
propose
some
construction.
That
is
always
better
used
that
not
used
with
the
current
parent
G's.
So
the
idea
here
is
to
base
on
Nexus
trick,
but
since
there
are
some
technical
problems
such
as
in
real
world,
we
usually
don't
have
a
direct
tax
access
to
private
keys.
J
We
only
have
API
is
to
use
them
for
some
purposes
and
since
it's
not
a
good
cryptographic
practice
to
use
long
term
keys
outside
of
their
primary
scope,
we
shoot
pigs
construction
very
carefully,
and
we
should
make
a
lot
of
very
clear
recommendations
here
and
we
should
get
tricked
security
proof
for
the
exact
construction.
So
the
objective
is
to
provide
one
ready-to-use
solution
with
full
security
proof
with
models
that
exactly
addresses
practical
security
security
model
and
so
just
have
one
RC
with
one
construction,
maybe
with
some
agility
own
algorithms
on
basic
algorithms.
J
So
the
construction
has
evolved
a
little
since
we
started
this
work
and
now
it
looks
like
the
following.
So
if
you
have
some
P
R
and
G
G,
then
we
can
define
here
ng
g
prime,
using
expand
and
extract
function,
hash
function,
signature
function
and
two
values
of
tech,
one
and
tech
to
where
tech
one
is
a
value
that
is
needed
to
bind
your
construction
to
the
environment
so
to
specific
device.
The
protocol,
maybe
to
make
address,
or
virtual
machine
user
and
tech
to
is
some
unique
string
that
includes
timestamp
or
counter.
J
So
it
must
be
unique
per
one
call
of
this
G
prime,
so
everyone
who
uses
G
in
his
applications
can
just
change
it
to
G
prime
and
it
should
become
better
and
the
draft
is
why
it
should
become
better.
So
we
have
had
a
lot
of
changes,
and
one
of
most
significant
ones
is
connected
with
the
virtual
machines
issue
it
was
was
was
duration,
why
David
McGrew
on
the
list?
J
It
was
really
important
issue
about
some
problems,
with
usage
of
parent
G's
in
virtual
environments
and
we've
added
two
items
to
the
bibliography
and
edit
several
security
durations
several
recommendations
about
to
use
the
construction
if
virtual
machines
are
in
scope.
So
these
are
two
citations.
So,
first
of
all,
we
strictly
recommend
to
incorporate
all
known
properties
of
an
environment
in
the
tech
one
and
secondly,
that
no
security
guarantees
can
be
if
the
virtual
machine
is
totally
cloned
without
any
differences,
without
any
distinctions.
J
J
A
good
question,
in
fact,
if
you
just
duplicate
Tech
one,
but
you
still
have
some
guarantees
of
ingenious
with
tech
2
as
security
still
remains,
but
in
this
in
this
case
you
should
have
some
some
way
to
provide
uniqueness
of
tech
and,
if
tag
one
and
take
two,
our
boys
are
both
collided.
Then
yes,
there
may
be
a
collision
of
the
whole
G
prime,
because
of
when
we
use
signature
as
a
deterministic
signature,
you
just
have
any
differences
between
two
cases.
Oh
I.
F
J
J
So
that
remains
the
issue.
Then
additional
clarifications
about.
Does
another
motivation
for
the
walk
we
can
initial
entropy
source
about
user
issue
is
HSM.
There
was
some
questions
on
the
list.
What
happens
well,
when
you
use
ethic
instructions
with
some
key
stored
in
HSN's,
some
some
additional
recommendations
about
how
to
use
it
about
procurement,
a
pair
computations
about
requirements
for
tech,
one
and
tech
2.
J
We
have
added
some
recommendations
that
are
really
needed
and
that
are
used
also
in
security
proof
later
some
minor
changes
about
terminology
about
enough
usage
of
swarf,
so
some
minor
changes
and
I
think
that
the
most
significant
walk
since
monreale
is
about
security.
Proofs
I'll
remind
that
they
decided
to
give
the
properties
that
are
declared
in
the
draft,
and
that
must
be
proven
are
the
following.
The
first
two
actually
means
that
the
construction
doesn't
make
anything
worse.
So,
first
of
all
is
if
some
parent
G
works.
J
Maybe
so
it
contains
full
security.
Proof
of
what
and
I'll
make
a
quick
review
of
physics.
So,
to
sum
it
up,
property
number
two
is
quite
trivial
one
if
all
requirements
that
are
mentioned
in
the
draft
are
met
and
we've
had
complete
game,
hoping
proofs
for
properties,
1
and
3,
so
that
parent
e
makes
it
only
better
with
some
assumptions
and
in
really
strong
adverse
remodels.
J
So
in
fact,
we've
proven
ever
sink
in
very
strong
assumptions
about
adverse
sorry,
even
more
strong
keys
and
it's
reasonable
in
practice,
but
we
know
some
things
that
could
be
still
improved,
so
the
versa
model
in
one
slide
is
that
of
course
say.
Your
aim
is
to
distinguish
an
output
from
the
random
from
some
random
output
and
she
can
do
a
lot
of
things.
She
can
choose
that
one
and
take
two
on
her
choice.
She
can
learn
all
values
generated
by
the
inner
says:
parent
G,
except
for
the
value
she's
taken
on.
J
She
can
choose
any
any
number
of
output
which
she
wants
to
italic
and
to
distinguish
it
from
random
and
she
can
ask
to
reveal
either
the
value
generated
by
parent
G
or
with
a
private
key
bus,
of
course,
not
both,
because
in
this
case
we
don't
have
anything
secret,
and
so
we
really
believe
that
the
model
perfectly
reflects
practice
and
even
is
much
stronger
than
needed
for
practical
assumptions.
But
we
try
to
do
this
good.
J
There
are
no
issues
with
the
proof
in
the
random
Oracle
model,
but
we
saw
that
we
can
do
better,
and
so
we
improved
the
proof
add
in
some
additional
assumptions
to
get
rid
of
most
and
obvious
problems
with
random
Oracle's.
So
we,
the
assumption
of
that
extract
function,
is
indistinguishable
from
random.
If
one
or
another
of
its
input
is
known,
it
must
be
said
random.
J
So
we
had
an
objective
of
the
fully
specified
and
construction
that
can
be
secured.
Now
we
have
complete
security
proofs
in
very
strong
case,
our
model
without
any
invisible
assumptions.
The
construction
is
quite
specific,
but
we
have
some
work
to
do.
First
of
all,
if
you
think
which
improvements
should
be
done.
J
First
of
all,
as
I
said
before,
we
have
complete
security
proof
for
a
KDF
in
general,
but
we
want
this
to
be
proven
as
specifically
as
we
can
so,
we
should
address
the
issue
with
hkf
because
it
wasn't
proven
for
one
quite
reasonable,
quite
intuitively
true,
but
it
wasn't
proven
for
one
property.
So
we
should
try
to
do
this
and
we
have
performance
issues
with
edge
graph
here.
So
thanks
to
Christopher
root,
we
have
some
primarily
results
of
experiments.
We
have
some.
J
Numbers
about
reduction,
it
can
be
from
five
to
ten
times
lowers
and
without
this
construction,
and
now
we
are
thinking
about
whether
we
should
do
something
else
or
whether
we
should
leave
it
as
it
is
because,
as
for
example,
case
Kramer's
thinks
that
it's,
it
won't
be
bottleneck
in
most
applications.
So
it's
one
of
the
questions.
We
still
need
to
consider
it.
That
seems
to
be
really
important.
J
So
our
current
state
in
plans
that
overall
principles,
overall
structure,
overalls,
ideas
of
the
proof
and
structural
proof
is
its
completed,
but
we
should
make
new
experiments.
We
need
to
think
about
recommendations
for
specific
protocols.
We
should
improve
the
proof
in
two
ways:
first
of
all
to
weaken
limitations
of
the
set
of
tech
ones
and
to
refine
it
for
hkf,
be
sure.
I
was
talking
about
the
phones
as
a
previous
slide
and
we
hope
to
get
a
version
addressing
these
issues
until
Prague
and
yes,
the
questions
are
very
welcome.
J
Valerie.
So
for
this
plus
on
just
a
clarification,
you
use
a
signature
to
improve
randomness
for
those
systems
that
don't
use
public
key
cryptography
and
use
and
rely
on
a
shared
key.
Is
your
technique
likable?
So
can
you
clarify
thank
Roberto
special?
Yes,
actually
the
same
ideas
are
applicable
but
and
the
signatures
are
can
be
changed
for
any
symmetric
primitives
but,
as
I
said
before,
since
we
really
want
this
to
be
quite
specific
construction,
we
needed
to
go
not
with
many
of
choices
and
many
of
variants
about
one
specific
construction.
J
B
I
Quit
commenting
on
I
mean
it
it's.
It
would
cause
a
laws.
This
long
discussion,
so
I
want
to
do
it
on
the
list.
But
yes,
a
lot
of
people
don't
want
to
use
a
private
key
just
willy-nilly,
but
it's
so
good
here
and
it
wouldn't
hurt
to
throw
it
in
I'm.
Gonna
suggest
later
that
that
you,
you
aren't
so
down
on
mixing
in
the
private,
the
private
key,
if
you
happen
to
have
one
sitting
around
and
two
included
in
something
else,
so
just
wanted
to
bring
that
up,
but
I'll
certainly
bring
it
on
the
list.
K
Yeah,
so
the
initial
experiments
were
just
some
kind
of
a
Dark
One's
that
I
did
to
get
some
sort
of
numbers.
We're
looking
into
other
primitives
like
sea
KDF
like
sea
mac-based
at
Katie,
I
see
mac-based
KDF
to
see
if
we
can
use
things
like
ASM
transfix
to
speed
this
up
recognize
that
that's
not
a
RFC
of
any
particular
form.
K
E
G
So
as
an
overview
for
a
review
of
this,
the
goal
of
this
draft
is
to
Devine
some
algorithms
to
efficiently
map
from
a
string
to
a
point
on
a
curve.
This
is
for
use
in
various
high-level
constructions,
such
as
the
vrf
document.
That's
going
through
CFR
G,
as
well
as
various
Pakes,
require
this
and
different
in
various
places.
You
need
to
be
able
to
map
into
a
curve
and
there's
different
requirements
of
what
type
of
map
it
can
either
be
have
to
be
an
injective
encoding
or
potentially
a
random
Oracle
encoding.
G
So
we're
hoping
to
cover
these
cases-
and
this
draft
is
meant
to
be
a
foundational
piece
to
be
plugged
into
a
lot
of
these
these
constructions
going
forward.
So
the
current
draft
is
at
draft
number
2
I'm
gonna
go
over
the
recent
progress
as
well
as
open
issues,
so
the
first
piece
after
a
lot
of
email
on
the
list
and
some
really
good
feedback
from
the
working
group.
G
We
we
got
the
feedback
that
this
should
be
much
more
concretely
defined
in
terms
of
taking
this
document
and
turning
it
into
an
algorithm
and
and
being
able
to
deploy
it
so
rather
than
being
descriptive
of
the
mathematics.
It
should
be
very
prescriptive
in
terms
of
exactly
what
to
do
the
first
step
in
being
able
to
take
a
string
and
hashing
it
into
an
elliptic
curve.
G
Point
is
often
taking
that
string
in
half
has
to
dashing
it
into
or
mapping
it
into
the
base
field
for
that
elliptic
curve,
and
so
we
defined
this
explicit
formula,
which
is
one
way
hash
from
a
string
to
element
in
the
base
field
of
the
curve.
This
is
deterministic
and
constant
time
are
the
important
pieces.
There
were
some
flexibility
earlier
on
in
terms
of
different
curves
have
different
biases
with
respect
to
how
you
could
take.
However,
large
the
the
input
is
to
mapping
it
into
the
curve
field
itself.
G
The
second
piece
that
was
suggested
was
to
give
a
concrete
list
of
steps
for
various
elliptic,
curves,
and
so
in.
In
this
we
decided
to
go
with
a
cipher
suite
type
of
construction,
so
a
list
of
four
different
pieces
that
put
together
will
kind
of
constitute
a
single
hashing
to
curve
algorithm.
So
this
includes
the
destination
group,
so
whether
it's
P
256
or
some
of
the
CFR
G
standard
curves
a
specific
hash
to
base
algorithm.
G
So
there's
different
ways
of
doing
a
transformation
at
the
end
of
the
construction,
to
make
sure
that
you
get
something
that
does
not
have
a
cofactor
and
also
in
some
situations,
such
as
the
draft
that
I'll
be
talking
about
after
this
vo
PRF
and
as
well
as
the
the
vrf
graph
that's
currently
going
through.
You
need
to
have
this
act
more
like
a
hash
function
and
not
be
reversed,
so
you
should
be
able
to
have
this
look
like
look
like
a
real
hash
function
and
not
be
reversible.
So
there's
there's
various
options.
G
There's
something
called
FF
STV,
which
is
essentially,
you
do
have
to
curve
twice
and
add
it
together,
and
this
gives
you
a
random
element
in
the
curve.
So
this
is
something
that's
optional,
not
neither
in
all
applications.
So
in
terms
of
this
overview,
you
can
we
put
together
a
list
of
these
cipher
suites
that
correspond
to
the
NIST
curves,
there's
only
random,
Oracle
versions
of
that,
as
well
as
the
CF
RG
curves
in
both
the
injective
mode
and
the
random
Oracle
mode.
So
these
are.
These
are
now
in
the
latest
version
of
the
document.
G
So
there
are
some
open
issues.
These
were
raised,
there's
a
question
about
including
pairing
friendly
curves,
so
there's
a
construction
by
fuking
to
bushi
about
how
to
do
this
efficiently
and
there's
an
open
pull
request
on
github
about
a
new
cipher
suite
that
is,
is
meant
for
bien
256,
which
is
a
commonly
used
pairing
friendly
curve.
There
are
some
questions
about
the
security
level
of
the
specific
curve,
but
but
this
is
this
p
RS
is,
is
under
review.
G
So
if
someone
were
to
make
an
implementation
of
this,
they
would
need
to
be
able
to
have
inputs
and
outputs
to
check
them
against,
so
we're
working
on
creating
test
vectors
and
validating
them
with
multiple
implementations
of
each
of
these
cipher
suites
in
various
languages,
as
well
as
sage
so
open
issues,
there's
a
couple
open
issues
that
were
raised
on
the
list,
as
well
as
on
github
about
some
corner
cases
which,
with
respect
to
constant
time
so,
for
example,
in
curve
448
in
the
Montgomery
form.
You
don't
have
a
complete
addition
formula.
G
So
we're
considering
changing
the
cipher
suite
for
cur
4
for
8
to
use
edie
4
for
8
and
because
the
Edwards
formula
has
a
complete
addition
formula.
This
helps
make
sure
that
it's
constant
time
there's
a
situation
in
SW
you
as
currently
written
glare
if
a
equals
zero,
such
as
in
the
Bitcoin
curve,
for
example,
you
there's
a
division
by
a
so
we
have
to
have
to
fix
that
algorithm
slightly.
G
So
there's
a
couple
of
edge
cases
and
corner
cases
with
respect
to
the
algorithm,
and
these
should
all
be
flushed
out
once
we
have
working
implementations
in
multiple
languages,
okay,
so
the
next
steps
are,
as
I
alluded
to
complete
the
test,
vectors
review,
the
pairing
friendly
algorithm
and
also
review
the
other
open
issues
and
make
sure
that
these,
if
necessary,
there's
a
a
constant
time.
Cipher
suite
for
every
single
one
of
these
use
cases
going
forward
and
yeah.
But
that's
that's
the
update
on
the
hash
to
curve
algorithm
drive.
G
Seems
like
enough,
so
next
we'll
move
on
to
something
that
I
alluded
to
earlier,
which
is
this
is
a
proposed
draft.
This
has
not
been
adopted
by
the
the
working
group,
something
that
we
proposed
to
IETF
segoe.
That
builds
upon
some
of
the
work.
That's
going
on
right
now
in
the
ITF,
in
that
C
FRG
around
VR
FS,
as
well
as
hash
to
curves.
So
this
proposal
is
called
verifiable,
oblivious
pseudo-random
functions
so
to
give
some
intuition
around
this
vrf.
This
is
something
we're
standardizing.
G
This
is
somewhat
equivalent
of
a
public
key
version
of
a
cryptographic
hash
function,
so
you
can
hash,
and
then
you
can
verify
that
only
the
the
participant
with
the
private
key
can
have
so
it's
it's.
This
isn't
exactly
it
it's
more
like
a
commitment
to
a
pseudo-random
input,
but
this
can
be
verified
given
a
public
key,
and
this
is
this
is
useful
in
a
lot
of
cases.
This
is
a
foundational
piece
for
say
and
SEC
5
in
the
DNS
world.
There's
another
construction
here
called
oblivious
pseudo-random
functions.
G
This
is
kind
of
like
a
digital
signature,
and
it
works
in
a
two-party
relationship
where
a
someone
who
wants
something
signed
can
give
it
to
the
signer.
They
can
sign
it
and
it
can
come
back
and
that
the
value
that
they
give
to
the
signer
is
blinded,
so
that
the
signer
does
not
have
visibility
into
what
the
the
signature
is
of.
So
they
know
that
they
signed
something
and
then
eventually
even
you
can
verify
that
the
certificate
this
are.
G
These
signature
is
valid
over
the
unblinded
piece,
so
this
is
interesting,
for
this
was
used
in
I,
guess
proposed
in
ecash
systems,
and
it
allows
systems
to
sign
information
with
without
having
the
knowledge
of
what
it
is
and
there's
a
couple
different
places
in
which
this
is
useful.
So
what
is
vo
PRF?
Well,
it's
kind
of
a
combination
of
the
both
of
both
the
RF
and
O
PRF.
So
it's
it's
a
v
RF
for
which
the
signer
is
blind
to
what
they're
computing
the
vrf
over.
G
So
very
specifically,
if
you
recall
some
of
the
definitions
of
vrf
this
this
will.
This
will
make
a
lot
of
sense.
This.
This
reflects
this.
Pretty
pretty
closely
so
it's
several
pieces,
one
is
an
algorithm
to
compute
a
hash
and
then
a
proof
from
an
input
given
a
private
key.
Then
it's
also
an
algorithm.
Given
a
hash
and
a
proof,
you
can
compute
a
verification
that
this
was
generated
by
a
specific
private
key
associated
with
the
public
key
in
the
last
base,
which
is,
which
is
what
makes
this
puts.
G
The
o
PRF
into
the
vo
PRF
is
so
yeah.
Both
those
initial
pieces
are
commonly
known
for
in
VRS,
but
the
ability
to
hash
compute
the
hash
of
an
input
from
a
hash
of
a
blinded
version
of
that
input.
G
So
if
you
take
an
input
and
you
blind
it
and
you
give
it
to
the
signer
or
the
party
who's
computing,
the
vrf,
they
can
compute
a
hash
and
a
proof
that
is
publicly
verifiable
with
the
public
key
and
you
can
take
that
blinded
value
and
unblind
it
and
then
you
will
have
a
hash
that
matches
what
the
vrf
would
be
so
vrf
SAR
deterministic.
So
this
gives
you
the
ability
to
take
that
hash
hand
it
back
to
the
signer
and
they
can
compute
the
the
deterministic
signature
on
it
again
and
make
sure
that
matches.
G
So
in
essence,
this
is
equivalent
to
what
a
no
PRF
does
in
that
you
can
give
back
the
data
to
the
to
the
signer
and
they
can
confirm
that
they
previously
signed
something
that
was
say
the
preimage
of
this.
What
makes
it
different
from
of
a
no
PRF
is
that
it's
only
the
signer
that
can
verify
this
once
you've
unblinded
it
it's.
So
it's
it's
not
publicly
verifiable.
It's
verifiable
by
the
signer
itself.
Yes,
Richard
yeah.
L
G
Correct
one
in
three
involve
a
signer,
and
so
you
can
apply
the
algorithm
one
on
either
a
blinded
or
unblinded
output
if
it's
non
unblinded
out,
but
that's
essentially
a
vrf.
It's
on
the
blinded
out
input.
It's
this.
What
is
the
as
the
does?
The
blinding
mechanism
become
part
of
the
final
output
like
or
is
it
or
is
it
just
as
it
just
a
private
construction
to
the
person
who's
requesting?
The
computation
as
in
are
stabilized
measures,
it's
similar
to
RSA
blind
signatures
and
that's
it
it
does
become.
G
It
does
become
part
of
the
output
from
the
signer,
but
when
you
unblind
it,
it
retains
some
sort
of
verifiable
property
right
right
guys.
What
I
mean
to
say
is
like,
as
I
understand,
our
set
point
signatures
right:
I,
don't
need
to
I
get
back
like
an
RS,
advise
ensure
I,
get
back
a
signature
over
the
input
string
and
I.
Don't
need
to
carry
around
the
blinding
factors
in
order
to
in
order
to
have
validated
drive
an
ordinary,
valid
signatures.
That's
that
same
case
here,
it's
almost
the
same
case.
G
So,
as
you
see
here,
you
get
back
a
hash
and
a
proof
when
you
unblind,
you
only
get
back
the
hash,
so
the
proof
is
something
that
needs
to
be
recomputed
from
the
input
by
the
signer.
In
order
to
confirm
the
value
of
the
hash,
you
lose
the
proof
when
you
unbind,
the
proof
is
really
what
ties
the
original
signature
to
the
public
key
of
the
signer.
G
Okay,
I'm
gonna
make
one
more
stab
at
this,
and
then
this,
if
I,
don't
understand
it
and
sit
down,
it's
kind
of
like
diffie-hellman,
actually
yeah
I
mean
so
imagine
the
following
construction,
where
the
where
I
supply
you
with
a
blinded
I
supply
you
with
a
I
supply,
you
with
a
random
value,
is
right.
I,
said
I,
think
I
want
signed
or
PR,
but
Volvo
preferred
and
I.
G
I
I
do
I,
get
I,
give
it
to
you,
I
blind
it
I
get
an
RSA
blinds
integer
back
that.
That's
that's
the
proof
and
okay,
never
mind.
If
I
see
guys
yeah
so
yeah,
you
know,
say:
Boeing
signature,
it
becomes
a
signal.
Signature,
that's
publicly
verifiable
in
this
case.
That's
not
necessarily
because
the
problem
is
I
need
a
tree
idea,
transform
the
signature
in
order
to
get
that
signature
over
the
actual
value.
And
that's
the
piece.
That's
missing!
That's
right!
Yep!
G
G
The
prover
proves
that
computes
a
signature
of
s
with
M
as
long
M
Prime,
along
with
proof,
and
if
you
remove
the
blind,
so
you
get
back
from
M
Prime
back
to
M,
you
can
send
m
and
the
signature
to
the
prover,
and
then
they
can
then
compute
from
M
another
signature
and
just
check
to
see
that
the
signatures
are
the
are
the
same.
So
the
main
advantage
of
this
is
that
the
original
transaction
and
the
final
transaction
are
not
linkable
together.
G
So
if
you
were
to
do
this
in
bulk-
and
you
would
have
this-
the
prover
compute
a
know,
vo
PRF,
over
over
a
number
of
messages-
you
wouldn't
know
which
one
they
would
correspond
to
so
it
could
be
anything
that
was
sent
as
an
input
could
could
have
been
the
original
signer.
So
if
you
as
this
prove
er,
you
compute,
you
know
a
hundred
million
vo
prfs
with
the
same
key.
You
don't
know
which-
which
input
actually
course
wants
to
that.
G
The
verification-
and
this
gives
you
the
properties
that
you
want,
or
at
least
the
properties
that
that
I
enumerated.
So
what
this
draft
provides.
Well,
specifically,
if
there's
a
generic
construction
to
do
a
vo
PRF
you
can.
What
you
need
is
a
prime
order
group
with
difficult
discrete
logarithm.
You
need
a
one-way
map
from
a
string
to
a
group
element
of
this
group
and
you
need
a
discrete
log
equivalence
proof.
G
This
is
this
is
where
the
proof
comes
into
place
and
you
can
actually
do
a
batch,
discrete
log
equivalence
proof
over
an
arbitrary
group
of
this
of
this
size
using
a
Chow
Peterson
base
proof.
So
the
specific
construction
that
we're
presenting
here
in
this
draft
is
over
a
prime
order
group
P
256,
which
is
the
NIST
curve
and
then
there's
a
potentially
proposal
to
use
CF
RG
curves,
which,
as
I
mentioned
in
the
previous
presentation,
do
not
have
a
prime
order
group.
G
So
you
have
to
make
sure
that
when
you're
hashing
into
this
group
that
you
either
eliminate
the
cofactor
or
use
some
sort
of
encoding
that
ensures
that
you're
on
a
prime
order
subgroup
of
this
of
this
curve,
but
just
for
simplicity,
let's
consider
this
P
256.
Then
you
have
a
hash
to
curve
cipher
suite
something
from
the
previous
draft
I
presented,
and
then
you
can
use
this
construction,
which
is
a
batched,
Sean,
Peterson
proof.
G
This
is
from
Ryan
Henry's
thesis
in
twenty
twenty
fourteen,
but
it
goes
back
to
John
Peterson
proofs
back
in
the
day,
so
this
is
what's
presented
in
the
draft.
What
are
the
use
cases?
Well,
there
are
many
privacy-preserving
applications
you
could
imagine
interacting
with
the
service
and
proving
something
that
you're
a
member
of
a
group
that
you've
performed
a
specific
operation
and
then
returning
to
that
same
service
and
providing
a
proof
that
you
had
done
this
thing
in
the
past,
such
that
it
son
linkable.
G
So
the
main
inspiration
for
this
was
a
application
called
privacy
pass
that
we
developed
at
CloudFlare
privacy
pass
is
a
way
to
solve
one
CAPTCHA
on
one
site
and
get
back
a
bunch
of
via
VOP
RF
outputs
and
then
redeem
them
to
solve
other
CAPTCHAs
on
other
sites,
so
that
your
interaction
with
the
first
site
is
not
known
to
the
second
site.
It's
just
known
that
you
did
a
proof-of-work
of
some
of
some
type,
specifically
solving
a
CAPTCHA.
There
are
other
potential
applications
to
this
privacy-preserving
authentication
or
I,
guess
authorization.
So
you
can
imagine.
G
If
you
have
a
service
set
say
you
have
a
verified,
Twitter
account
or
a
Facebook
account
with
a
certain
parameter.
You
could
use
that
as
a
proof
of
belonging
to
a
authorized
set
to
a
third-party
service,
so
you
could
go
say
to
your
identity
provider
and
do
a
vo,
PRF
and
then
reading
that
ticket
with
with
a
third
party,
and
they
wouldn't
know
exactly
which
account
you
would
correspond
to,
but
but
simply
that
you're
part
of
a
specific
set.
G
There's
applications
we've
looked
into
here
for
checking
for
compromised
passwords.
So
you
can
use
something
like
a
vo
PRF
with
a
database
of
compromised,
passwords
and
kind
of
anonymously
check
to
see
if
your
password
is
in
that
database
without
leaking
it
to
the
the
database
provider
and
there's
there's
also
I've
heard
some
potential
applications
here
in
proof
of
advertising,
for
example
online.
So
you
prove
to
some
service
that
you
viewed
an
ad
and
you
can
do
so
without
leaking,
which
ad
that
you
saw
so
here
are
some
open
questions.
G
I
have
before
we
go
forward
with
this
is
is
a
lot
of
the
constructions
here.
A
lot
of
the
meat
of
this
draft
overlaps
a
lot
with
the
vrf
draft,
but
this
draft
includes
two
specific
things:
on
top
one
is
the
blinding
mechanism,
and
one
is
the
batch
verification
mechanism
that
allows
you
to
do
multiple,
VRS
or
vo
PRS
at
once.
So
maybe
this
is
better
suited
as
an
extension
to
the
vrf
craft,
rather
than
a
second
complete
draft
in
itself.
J
J
Merged
together,
but
I
believe
that
here
you
have
a
lot
of
quite
quite
difficult
questions
to
solve,
and
maybe
it
should
be
done.
The
USS
effort
walk
just
because
of
too
many
questions
that
Sharon
and
learn
it
should
address
in
their
draft,
and
you
should
address
the
draft
in
any
case,
I'll
be
happy
to
help
with
review
in
this
or
original
ease
and
making
some
suggestions.
My
personal
opinion
that
this
draft
should
be
separate
but
in
any
case
I'll
be
happy
to
help
raise
review
in
this.
Thank
you
very
much
great.
Thank
you.
L
G
L
So
so,
depending
on
how
asked
that
is,
I
think
it
may
be
worth
considering
whether
you
know
whether
it
would
be
close
enough
to
merge
the
vrf
into
this,
as
a
special
case
is
kind
of
a
subsection
says.
If
you
specialize
in
this
way,
then
you
then
you
get
this
other
function
that
has
some
different
properties.
G
So,
just
out
of
interest
could
I
see
a
hands
of
people
who
have
read
this
proposed
draft
out
there
just
to
get
a
sense
of
sense
of
the
REB
zone.
Not
too
many.
Oh
I,
don't
know
how
much
we
can
do
here
at
the
mic,
but
eventually
I'd
like
to
ask
the
chairs
to
have
a
call
for
adoption
for
this
draft
or
to
figure
out
exactly
what
the
right
combination
of
this
and
vrf
should
be
to
move
forward.
Yeah
we'll
take
a
take
it
offline.
J
G
J
E
B
I'm
signing
USD
thank
you
for
the
great
presentation
and
I
have
a
one
question
about
the
use
cases
over
Bo
PRF.
You
talk
about
pestle
compromise
pit
checking,
so
could
you
explain
must
agree
how
this
use
case
works?
Do
you
actually
need
vo,
PRF
or
I?
Just
thought
that
Oh
caliper
could
be
in
up
to
this
case
right.
G
E
L
I've
been
chatting
with
Karthik
getting
a
couple
of
other
folks
about
doing
some
work
on
ICI
IES,
because
we
need
this
primitive
for
MLS
for
encrypting
things
to
a
tree,
a
tree
full
of
public
keys.
So
you
know,
there's
obviously
already
a
kind
of
diversity
of
standards
around
ec
IES,
but
nothing
kind
of
wildly
implemented
a
available.look
that
has
been
through
the
rigor
of
this
group.
So
I've
got
a
draft
in
progress
that
I
haven't
posted
yet.