►
From YouTube: IETF100-CFRG-20171115-1520
Description
CFRG meeting session at IETF100
2017/11/15 1520
https://datatracker.ietf.org/meeting/100/proceedings/
A
A
A
A
A
A
And
just
just
reminded
that
we
do
have
a
crypto
review
panel,
which
have
eight
members.
Now
it
started
last
September
we
haven't
done
much
with
it
since
December,
but
since
December
it
was
used
quite
heavily
and
people
seem
to
be
getting
into
reviewing
documents
and
providing
comments,
see
FRG,
chairs
and
I
think
also
security.
It
is
found
this
to
be
quite
useful
group.
C
B
Here
is
a
list
of
all
contributors
and
people
who
helped
with
draft
so
far.
So
as
a
motivation
for
the
document
is
the
following,
when
we
use
symmetric
keys,
we
have
to
limit
their
life
time
somehow,
because
of
several
reasons.
First
of
all
is
because
of
basic
internal
properties
of
used,
ciphers
and
cipher
modes,
just
because
of
short
blocks
and
similar
reasons.
The
good
example
here
is
with
tripodi's,
where,
as
I
was
recent
attacks
which
suited
to
and
a
nice
traction
about
it.
B
Sorry
for
small
letters
here
as
a
nice
recommendation,
which
is
now
it's
being
discussed,
is
about
reducing
the
limit
on
key
usage
for
Triple
DES
for
travel
this
to
to
to
the
20
blocks.
That's
eight
megabytes,
then
standard
methods
of
crypt
analysis,
linear,
etc,
and
if
we
have
some
issues
with
our
sulfur,
we
have
to
limit
our
key
lifetime
so
that
it
will
be
smaller
than
the
material
needed
for
text.
Success
of
methods
and,
most
of
all,
most
important
of
all,
as
a
primary
motivation
for
the
document
is
resistance
against
side-channel
attacks.
B
A
recent
example
here
is
an
example
of
an
attack
against
is
Tempest
attacks
against
AAS
paper
was
published
in
July
and
if
to
estimate
the
material
that
was
used
during
the
attack,
it's
much
smaller
than
160
megabytes,
so
it's
bound
and
very
rough
are
bound.
So
in
some
cases
we
have
to
limit
our
usage
because
of
exposure
in
hostile
environments.
B
If
we
have
addresses
with
side-channel
techniques
and
if
we
are
not
ready
to
make
our
negotiation
or
some
cable
in
techniques
very
frequently,
we
can
use
lighter
techniques,
and
a
good
example
of
such
technique
is
very
keen
in
TLS
1.3
the
cube
did
procedure,
which
is
recommended
to
be
done
every
two
to
the
power
of
24
and
five
and
have
four
sides.
Records
for
GCM
is
a
great
example
of
external
regime,
and
it
is
one
of
examples
with
which
the
walk
started.
B
B
It's
not
about
how
to
define
the
limits
on
usage
regarding
side
channel
attacks,
it's
a
very
important
but
quite
different,
and
quite
a
large
topic.
It's
not
about
how
to
prevent
life
of
ciphers
that
are
already
known
to
be
really
vulnerable,
and
it's
not
about
what
quantum
issues
similar
techniques
using
KDF
or
errors
are
used,
for
example,
in
a
draft
in
equity
from
date,
McGrew
cooler,
weather
isn't
just
loaf
panis
and
it's
not
about
heavy
schemes
over
negotiations.
B
So
it's
like
it's
about
easy
and
transparent
message
to
continue
using
session
keys
without
a
new
exchange
of
data,
etc.
I
gave
a
long
preview
of
techniques
in
Seoul.
After
that
work
started
by
the
in
chief
of
chairs
of
the
research
group,
there
was
a
large
one,
our
side
meeting
of
saffir
G
in
Chicago,
where
we
discussed
the
scope
of
the
document,
the
mechanisms
that
we
use
and
reforms
as
a
structure
of
the
document
itself,
and
we
heard
a
state's
update
in
Prague
in
July,
so
the
from
from
Prague.
B
So
we
didn't
find
any
real
problems
with
the
security,
but
security
proof
positive
result
for
them
is
a
very
difficult
task
that
is
quite
different
from
tasks
for
other
modes
and
during
the
discussion
we
decided
that
the
modes
of
B
and
C
same
or
not
so
important,
to
get
a
lot
of
time
to
get
security
proofs
for
them,
and
the
document
is
quite
large.
Even
now,
now
we
have
many
of
choices
of
external
internal
parallel
and
serial,
based
on
cipher
and
based
on
hash
functions
for
transformation.
B
Instructions
requiring
or
not
equine
master
key
for
all
of
them
is
a
security
proofs
in
the
models
similar
to
the
models
that
were
proposed
by
Abdullah
and
Bellary
in
their
work
on
increasing
the
lifetime
of
seven
keys,
four
of
them
about
quadratical
increase
of
a
lifetime
is
gained
by
using
these
modes.
We
have
a
lot
of
discussions
now.
We've
had
a
lot
of
written
discussions
after
the
document
was
sent
to
click
the
review
panel
for
the
hip
to
review.
B
There
was
a
very
interesting,
very
important
review
from
here
on
Shafer,
and
we
had
a
very
fruitful
discussion
with
him
and
we
had
a
lot
of
discussions
in
list
and
off
list
about
the
connection
of
the
ideas
related
documents,
some
major
considerations
to
be
resolved
now,
first
of
all
and
it's
our
mistakes.
My
mistake
is
that
in
the
document
now
we
don't
have
an
explanation
why
we
need
several
mechanisms.
B
In
fact,
the
short
answer
for
this
is
is
here
that
if
we
talk
in
the
term
softer
lens
one
two
three,
for
example,
if
we
have
serial
mechanism,
then
we
have
an
additional
good
security
property.
If
we
have
full
compromise
of
the
state
secret,
so
application
traffic
security,
the
terms
of
Atilla
is
one
point:
three.
We
don't
have
a
full
compromised
of
all
previous
secrets,
so
several
mechanisms
helps
to
provide
additional
security
property.
B
If
we
are
afraid
of
compromise
of
the
system,
then
we
have
to
widen
a
section
about
similar,
similar
and
related
constructions,
with
more
links,
most
stations
about
applicability
for
data
trust.
It
was
a
very
good
concern
from
your
own
Schaffer
that
we
should
talk
not
not
only
about
applicability
for
protocols,
but
also
for
data
at
rest
and
a
section
about
relationships
with
similar
and
related
mechanisms
that
employee
also
mixed
in
entropy
like
in
equity,
about
this
question.
B
First
of
all,
if
we
talk
about
Dirk
in
itself
and
about
quality
of
keys
that
are
produced
by
in
mechanisms,
if
we
have
a
good
pair
of
based
on
a
fair
basis
offer,
we
don't
need
additional
entropy
for
the
quality
of
keys.
But
if
we
have
more
more
wide
security
models,
if
we
are
afraid
of
a
full
security
breach
of
the
system,
a
full
but
time
limited,
then
aidan
additional
entropy
may
be
useful
in
case
of
two
conditions
resolved.
B
If
long
term
secrets,
like
master
keys
or
private
keys,
are
stored
in
nature
same
or
in
some
protected
environment.
If
we
have
to
do
new
exchanges
to
edge
this
entropy
and
of
course
it
can
be
done
on
the
fly,
but
it
can
provide
additional
security
properties,
and
these
commands-
and
the
section
related
to
this
question
will
be
added
to
the
document.
We
won't
add
any
specific
instructions
because
for.
C
B
Such
a
comment
will
be
added
that
we
must
rely
on
the
additional
entropy
only
if
we
have
full
analysis
of
it,
because
in
some
proprietary
protocols,
I'm
aware
of
their
problems,
when
additional
entropy
were
like
an
additional
safety
margin
were,
while
it
didn't
add
anything
else,
I
did
a
Tennison
good
to
the
security
but
gave
a
false
sense
of
additional
security.
It's
very
good.
It's
ok,
for
example,
for
ikely.
It's
ok
with
security
for
likely,
but
in
some
proprietary
protocols
it
can
be
an
issue
so
we'll
recommend
about
that
and
the
specific
state
in
plans.
B
We
should
add
a
comments
about
not
only
date
and
tressed,
but
also
control
of
work
in
process.
In
the
list,
there
was
a
discussion
with
Peter
Alexander
who
wanted
to
participate
in
that
we'll
add
a
comparison
of
describes,
approaches
with
mechanisms,
including
additional
entropy,
will
add
new
references
and
detect
test
vectors
and,
of
course,
resolve
editorial
commands,
given
it
as
reviews,
and
we
hope
that
we'll
obtain
a
new
version
address
and
all
these
issues
and
all
the
concerns
given
in
the
reviews
by
the
three
panel
members
by
the
end
of
January
2018.
B
You
it's
a
great
question,
in
fact,
maybe
there's
even
two
questions.
First
of
all,
if
we
talk
about
how
to
control
the
change
of
keys
and
now
how
to
deal
with
its
moments
of
when
the
keys
are
dated,
it's
a
very
good
question
and
there
was
a
draft
or
Peter
Alexander
in
the
least
that
were
about
exactly
his
proposals
for
the
SP,
but
I
would
answer
it.
Maybe
a
little
more
widely
I
have
a
good
example
of
usage
of
routine
in
IPSec
in
proprietary
Russian
mechanisms.
B
I
think
there
is
much
loss
could
comment
on
this
if,
if
it's
needed,
if
we
have
a
cipher
with
small
block
size,
the
mechanisms
that
are
already
in
Ike
we
do
for
gel
to
say
and
the
wrecking
of
gel
to
say
can
be
not
enough,
because
if
we
have
a
cipher,
we
is
really
a
small
block.
We
have
to
change
keys
much
more
frequently
and
the
bound
that
was
given
by
nice
of
eight
megabytes
for
a
tripod.
S
was
like
this
for
Russian
Gosai
for
a
previous
go
cipher
for
a
long
time
ago.
B
It
was
not
8
megabytes,
but
4
megabytes,
but
the
same,
and
we
had
to
rekey
very
frequently.
We
had
turkey
either
in
1
kilobyte
if
we
had
suits
for
down
usage
or
each
4
megabytes
if
it
was
for
white
market
and
the
soldier
was
a
transparent
rekeying
inside
ESP,
as
it
was
for
fixed
blocks
of
data
Linux
without
any
negotiation
with
process
with
responder,
and
we
had
the
basic
like
we
or
like
one
techniques
for
changing
the
keys
by
new
entropy
and
by
all
this
good
great,
but
a
little
more
heavy
mechanisms.
B
So
as
a
king,
which
is,
is
currents
a
draft
light
chiquinho,
you
say
so
without
any
additional
exchanges
is
a
method
for
dealing
with
really
tight
limits
on
the
key
usage
like
four
or
maybe
100
megabytes,
not
more.
But
of
course
we
have
to
have
still
to
change
the
keys
using
your
entropy,
maybe
using
your
education
when
we
we
are
thinking
about
process
which
is
made
once
in
an
hour
or
more
early.
So
it's
rate
equations,
but
maybe
not
the
same.
One
and
I'll
be
he'll,
I'll
be
very
and
sinful.
D
You
have
responding
to
Paul
if
we
want
to
change
the
way
ESP
Ricky's,
then
that's
up
to
the
IPSec
of
me.
Working
group
and
I
can
think
of
several
ways
like
a
sentinel
packet
that
says
now,
I'm
changing
the
key
or
pre
agreeing
that
after
so
many
packets
were
automatically
rolling
over
the
key
there's
plenty
of
ways
to
do
this.
B
A
E
F
Presenters
should
stay
in
pink
boxes.
That's
not
working!
So
I'm
gonna
have
to
do
this.
In
the
pink
box.
Oh
hi,
I'm,
Paul
Hoffman,
some
of
you
were
at
the
last
C
FRG
meeting,
saw
a
presentation
on
this
by
kenny
Patterson,
because
I
wasn't
able
to
be
there,
but
now
it's
me
saying
have
with
a
few
more
updates,
but
still
with
sort
of
the
same
basic
question.
F
F
So
this
is
explicitly
not
about
which
algorithm
should
we
use
for
post
quantum
crypto.
This
is
about
once
we
know
an
algorithm
and
you
know,
NIST
is
gonna.
Take
a
few
years,
a
lot
of
laws.
Some
people
already
pick
some.
Some
people
want
to
wait
10
years,
but
at
the
point
where
we
have
an
algorithm,
people
are
gonna
start
to
say:
oh
shouldn't,
we
use
the
new
algorithm,
it's
it's.
F
You
know
newer
and
so
far
all
of
these
algorithms
have
properties
that
are
you
know,
so
they
have
the
good
property
of
that
they
will
last
them
in
a
post
quantum
world.
They
have
the
bad
property
that
either
the
keys
or
the
signatures
are
both
are
huge,
two
ginormous
or
in
the
case
of
like
the
hash
base
signatures
that
we're
talking
about
here.
F
F
I
mean
just
no
matter:
how
long
is
we're
not
gonna
say,
and
we
need
to
worry
about
this
at
a
certain
time,
because
there
is
so
little
data
now
that
would
actually
help
you
make
a
good
prediction
that
doesn't
stop
some
people
from
making
a
prediction,
but
you
know
for
those
of
us
who
are
actually
trying
to
be
honest
about
this.
We,
you
know
there's
so
little
data.
Now
you
just
can't
extrapolate
and
let's
face
it,
even
when
there
is
good
data,
we've
extrapolated
really
badly.
I
mean
the
IETF
has
just
sucked
at
this.
F
So
but
what
it
is
trying
to
do
is
if
someone
says
I
want
to
make
a
prediction:
we
want
to
give
them
as
much
current
data
as
we
can
so
really.
What
we're
trying
to
do
here-
and
this
is
why
it's
sort
of
CFR
G,
it's
actually
sort
of
researchy
in
the
sense
of
we're
trying
to
collect
all
the
best
research
out
there.
F
F
So,
like
I
said
it's
not
about
choosing
the
algorithms
there's
plenty
of
people
working
that
on
that
already
for
those
who
aren't
for
the
two
people
in
the
room
who
aren't
aware
NIST
is
having
a
competition.
They've
they've
just
closed
the
the
the
window
for
people
giving
submissions
and
such
this
isn't
about
that
at
all,
and
the
reason
why
I
have
to
keep
saying
that
is
that
has
garnered
you
know
thousands,
if
not
tens
of
thousands
of
researchers
trying
to
get
their
name
on
the
next
algorithm
stuff.
When
do
you
need?
F
That's
probably
five
years
down
the
line
when
we
have
better
research,
if
we
wait
until
then
it
might
even
be
too
late.
People
are
gonna
start
slamming
in
some
of
these
things
and
then
we'll
realize
we
had
done
it
too
early.
So
we
want
to
say,
if
you're
going
to
do
this,
please
you
know,
try
to
do
it
sensibly
and
we
can't
help
you
to
do
it
sensibly
yet,
but
we
believe
we
will
be
able
to
in
the
future,
and
there
is
some
you
know
reasonable
research
out
there.
F
So
since
Kenny
did
this
at
the
last
IETF
I've
gotten
some
very
good
input
and
including
from
Stanislaw
person
who
spoke
to
you,
we
actually
had
I
wasn't
at
that
crypto
in
Santa
Barbara,
but
Hillary
Orman,
a
cryptographer.
Many
of
you
might
know
because
she's
come
to
the
IETF.
A
bunch
in
the
past
presented
it
at
the
rump
session,
but
we
haven't
got
that
many
people
who
are
contributing,
and
so
those
of
you
who
haven't
read
the
draft.
It
has
some
stuff
and
it
also
has
some
very
brightly,
marked
holes.
F
That
say
we
don't
know
about
this,
but
we
could,
if
you
help
me,
fill
it
in
so
that's
sort
of
what
I
was
hoping,
especially
from
the
folks
at
crypto.
Just
having
had
it
happen.
I'm
hitting
up
some
individuals
and
a
lot
of
them
are
like
yeah
yeah,
but
I'm
I'm.
Much
more
interested
in
the
actual
post,
quantum
algorithms,
so
really
the
question
I
mean
this
is
something
that
I
think
is
like
perfect
for
the
CF,
our
our
G
here.
F
You
know
that
this
is
research,
we're
actually
collecting
research,
but
I'm,
not
hearing
a
lot
yet
from
the
group.
So
I
want
to
know.
Is
this
something
that
you
folks
want
to
do,
and
especially
do
you
know
somebody
who
actually
knows
this
and
many
people
I
mean
everybody
in
the
post
quantum
crypto
world
knows
what
shores
has
heard
of
Shor's
algorithm.
The
number
of
people
who
can
describe
it
is
way
smaller
than
that,
particularly
when
you
ask
them
to
describe
it,
not
just
with
how
many
qubits
are
needed,
but
how
much
other
circuitry
is
needed.
F
Also,
the
physicists
are
a
little
sidetrack
here.
There
are
many
ways
to
supposedly
build
a
post
quantum
computer
different
physics.
You
know
for
trapping
the
ions
and
things
like
that.
There
is
a
buttload
of
money
in
that,
and
so
a
lot
of
the
physicists
are
very
tightly
wedded
to
the
thing
they
got
a
grant
for
or
the
thing
they
got
a
friend
got
a
grant
for.
There
aren't
many
people
who
are
that
good
at
looking
over
the
whole
thing
and
saying
in
five
years.
F
F
F
F
Some
of
you
folks
can
help
fill
in
the
holes
or
you
have
friends
who
can
help
fill
in
the
holes
and
get
it
discussed
again
for
probably
like
a
year
and
then
close
it
and
again
in
a
year.
It's
not
going
to
say
we
need
to
worry
about
post
quantum
in
year
X,
because
we
really
really
don't
know
I
mean
that's
one
thing
that
I've
heard
consistently
from
the
researchers
who
are
really
working
on
this
and
there's
one
researcher
that
the
only
one
I've
actually
seen.
F
Who
actually
has
any
numbers,
who
has
actually
says,
there's
a
20%
chance
in
such-and-such
year,
and
you
know
further
on
than
that.
But
quite
frankly,
most
other
people
are
quoting
each
other
and
even
NIST
fell
into
the
of
quoting
a
researcher
and-
and
it's
just
sort
of
interesting
cuz
there
and
I
say
this
in
the
draft,
but
their
references
actually
to
a
YouTube
video
and
in
the
YouTube
video
in
the
section
about
this.
F
Maybe
we
can
revisit
it'd
be
great
if
we
could
revisit
shorter
than
that,
because
something
has
happened,
but
the
quantum
folks
I
talked
to
are
saying
it's.
It's
gonna
have
to
be
some
magic
that
happens
the
next
10
years
or
we're
really
not
gonna,
know
so.
Anyways
I
think
that's
it
so
I
don't
know.
How
do
you
want
to
well
tell
you
what
I'll?
Let
you
do?
Are
there
any
questions
on
what
I've
said
other
than
like?
Do
we
want
it
in
the
working
right.
A
A
G
A
H
H
F
There
are
actually
multiple
answers
to
that
question.
Multiple
different
answers
to
that
question:
one
is
a
certain
size,
but
so
when
you're
building
a
quantum
computer,
you
need
qubits,
but
you
also
need
circuitry
around
it
I'm.
So,
as
a
little
bit
of
background,
some
of
you've
heard
we
have
quantum
computers.
Now
those
are
generic
quantum
computers.
Where
you
can't
make
an
interesting
circuit,
you
can
do
a
little
bit,
but
not
a
lot.
F
F
Now,
as
it
turns
out,
the
circuitry
is
what
slows
things
down,
not
the
qubits.
So
that's
what
separately,
though,
those
are
pure
ones.
It
turns
out
that
in
the
last
five
years
everyone
has
realized.
You
can't
actually
build
a
qubit
that
will
work.
You
have
to
build
a
qubit
of
about
a
thousand
cubits
that
will
average
into
one
and
so
the
whole
section
in
the
document
about
error
correction.
So
what
I
just
said
multiply
that
by
maybe
a
thousand.
H
F
F
Question
can
you
take
a
bunch
of
smaller
quantum
computers
and
put
them
together
to
make
make
a
question?
The
answer
is
probably
not
like,
very
probably
not,
but
that's
a
very
interesting
area
of
research
I'm,
not
not
using
Shor's
directly.
You
cannot,
however,
because
what
you're
asking
is
we
know
it's
gonna,
take
a
long
time
to
get
to
this.
Is
there
a
baby
step
along
the
way?
There
is
definitely
some
some
research
being
done
on
that,
not
clear
if
it
will
work.
Okay,.
H
F
You
help
me
so
that
a
particular
number
is
one,
that's
very
interesting,
and
there
is
some
contention.
For
example,
just
a
few
months
ago,
dan
Bernstein
came
out
with
a
completely
different
way
to
do
this,
where,
as
where
you
can
do
it
with
a
smaller
number
of
qubits,
but
with
completely
weird
circuitry
that
is
or
isn't
sure
or
whatever
that's
the
kind
of
thing.
F
Why
I'm
saying
I
wouldn't
want
to
finish
the
draft
now
just
to
pick
out
one
number
because
there's
disagreement
and
there
are
people
who
are
doing
really
interesting
research
around
the
idea
of
this
looks
impossible.
Now
you
know
for
a
certain
period
of
time.
Is
there
a
possible
way
of
doing
it?
That's
not
a
straight
linear,
so
yeah.
So
that's
that
I
would
love
to
have
sections
on
that
in
in
the
in
the
paper.
E
I
C
E
F
F
J
Okay,
I
I
just
actually
wanted
to
follow
up
on
that
Brian
Ford,
EPFL,
I,
I
kind
of
want
to
push
back
on
that.
So,
if
this
is
about,
you
know
the
transition
and
how
to
manage
the
transition.
I
would
kind
of
think
that
those
kind
of
questions
maybe
should
be
in
scope.
For
example,
if
you
can,
if
it
turns
out
you
know,
as
we
get
closer,
you
can
get,
you
know,
kind
of
we
know
RSA
and
ECDSA.
Are
you
know,
kind
of
gradually
getting
cracked
effectively
by
quantum
computers?
C
J
F
F
C
K
F
Dan
and
I
have
a
long
history
of
completely
disagreeing
on
threat
models,
but
it
is
he's
correct
and
saying
if
you
know
your
threat
model
your
year
of
a
threat
model,
we
should
be
able
to
help
you
figure
out
when
you,
when
you
either
need
to
in
the
future
or
when
you
should
have
in
the
past
depending
so,
please
do
review
it.
So
do
you
want
me
to
turn
this
into
it.
A
F
So
then
I
will
turn
this
into
a
draft
IRT
of
C.
But
again,
if
you
have
any
friends
who
liked
it,
who
are
either
working
on
this
or
just
people
who
are
doing
it
like
as
a
hobby
which
some
of
them
are,
please
give
them
this,
they
might
say.
Oh
I,
know
the
answer
to
that.
That
would
be
lovely.
Thank
you.
L
All
right,
hi,
everyone,
I'm
Ben,
Caidic
and
I'm
here
to
talk
about
speak
to
I.
Guess
it's
been
a
while,
since
we
really
talk
too
much
about
bakes
and
this
document
has
been
a
research
group
document
actually
for
a
while.
It's
been
expired
for
like
a
a
year,
I
think
so.
The
previous
version
that
was
expired
for
that
long
time
was
the
oh
three
and
it
got
some
comments.
But
then
nothing
happens.
So
just
recently,
I
picked
it
up
again
and
resurrected.
L
It
and
I
have
more
changes
that
I
need
to
make,
but
I
haven't
made
yet
and
in
terms
of
why
I
care
well
I
care,
because
I
want
yous
in
Kerberos
and
you
sort
of
I
see
it
as
a
further
evolution
of
Kerberos.
You
know
original
Kerberos.
You
would
just
ask
the
KDC
for
a
ticket
and
get
one
back
and
that's
like
anyone
can
get
a
cipher
text
to
attack
and
the
ciphertext
is
encrypted
in
a
key
derived
from
your
password
users
pick
bad
passwords.
So
this
is
like
really
bad.
L
L
So
what
I
want
to
do
is
to
make
it
so
you
can't
actually
get
a
ciphertext
and
try
and
brute
force
the
password,
the
password
based
key
by
introducing
the
actual
key
exchange
into
the
process,
and
there
will
be
some
some
other
benefits
as
well,
and
so
you
know,
there's
lots
of
Peaks
out
there.
What
makes
spake
too
good
trusts-
and
this
is
sort
of
cribbed
from
the
actual
document-
that's
in
the
kitten
working
group.
L
So
it's
a
smaller
number
of
creeper
operations
and
only
you
know
one
message
from
each
side
to
actually
do
the
key
exchange.
So
you
know
we
don't
have
to
go
back
and
forth
with
the
Kerberos
pre
authentication.
We
can
get
our
output
relatively
quickly,
so
I've
got
the
kitten
draft
up
there.
I
would
love
to
get
more
review
on
that,
maybe
even
from
the
crypto
review
group.
L
And
then,
after
I
submitted
the
new
version
of
the
C
FRG
document
I
got
some
email
from
people
that
were
interested
in
and
I
guess
they
have
this
thing
that
they
want
to
do
file
transfer
between
devices.
You
know
call
up,
somebody
tell
them
and
password
over
the
phone.
Do
the
pake
get
your
key
and
you
have
secure
file
transfer.
So
that's
pretty
cool,
there's
no
other
interest
in
it
and
then,
in
terms
of
the
actual
outstanding
issues
or
things
that
we
know
about
so
far,.
L
You
know
the
w0w
one.
Is
it
speak
more
speak
to
I?
Guess
maybe
I'm
not
quite
qualified
to
answer
that
myself
so
I'm
looking
to
the
room
to
answer
some
of
these
questions,
you
know
the
second
bullet
point
is
pretty
editorial,
so
we
just
need
to
be
consistent
about
that
and
then
there
was
this
question
about
you
know:
do
we
check
that
we
have
a
point.
That's
in
the
right
right
space.
L
You
know
one
of
the
pseudocode
is
doing
I,
think
the
x
co
factor
and
the
text
is
talking
about
prime
motor
quotient,
or
maybe
the
other
way
around.
So
you
know
we
should
be
consistent
and
make
sure
that
whichever
one
we're
doing
is
actually
reasonable.
So
you
know,
ideally
we
get
help
out
from
additional
reviewers
to
make
sure
things
are
in
good
shape.
L
There's
another
review
from
Alex,
which
was
sort
of
complaining
about
this
PRF
plus,
like
scheme
that
it
turns
out,
is
only
actually
used
when
we're
generating
the
M&M
Vell.
The
M
and
n
values,
which
are
like
the
fixed
constants
for
the
curve,
so
in
some
sense
it
doesn't
really
matter.
We
just
need
something.
That's
nothing
up
my
sleeve
there's
some
other
review
comments
on
your
versions
of
the
draft,
even
before
the
oh
three,
so
some
of
these
have
been
already
addressed.
Some
of
these
have
been
overtaken
by
events.
L
You
know
this,
don't
harkens
point
about
being
clear.
What
we're
actually
doing,
and
you
still
valid
I-
think
the
text
can
be
more
clear.
You
again
make
the
text
more
clear
about.
Are
we
using
a
binary,
OID
and
input
to
the
hash
or
the
ASCII
representation
of
it
again,
similar
just
clarity
about
what
exactly
we're
doing
when
we
generate
the
M
and
n
values?
And
then
this
last
one
was
kind
of
interesting,
because
at
the
time
the
comment
was
made.
L
Assuming
no
one
jumps
up
to
the
microphone
and
complains
I
actually
don't
know
if
I
should
also
do
ETV
448
at
the
same
time
or
not,
and
one
of
the
other
things
that
I
found
when
I
was
going
through
the
mail
archives
from
like
two
years
ago,
I
was
Santos
olives
mail,
which
was
sort
of
wondering
about
general
paik
topics,
and
you
know,
is
there
general
interest
in
Pakes
and
sort
of
abstract
requirements
and
other
things
that
we
could
talk
about?
That
are
not
specific
to
a
single
Paik.
L
I
again
don't
really
have
a
personal
opinion
about
that,
but
I
figured
since
I'm
bringing
aches
back
to
the
attention
of
the
group.
I
should
mention
that
there
was
this
comment
and,
if
we're
starting
to
think
about
pigs
again,
we
might
want
to
start
thinking
about
this
too,
and
so
I
mean,
as
I
said.
My
main
goal
here
is
to
get
this
working
for
kerberos.
So
you
know
I
want
to
move
ahead
with
this
document,
but
I
want
to
make
sure
we
do
it
right.
B
Thank
you
very
much
for
the
talk.
We
had
a
discussion
with
Watson
that
not
only
in
the
mailing
list,
but
also
in
private
medications,
and
there
was
a
good
point
that
aspect
to
the
document
is
maybe
really
needed
together
with
other
excuse,
because
Specter
is
very
lightweight
in
the
sense
that
it's
it
doesn't
define
key
indication
after
they
initiated
it
doesn't
define
a
lot
of
things
that
are
going.
B
We
together
with
a
spec
protocol,
my
opinion
that
was
maybe
in
the
mail
in
the
mail
he
cited
I
didn't
remember
exactly
was
that
we
should
literally
define
which
security
requirements
do
we
do
we
demand
from
the
final
imitations
protocols,
so
we
must
check
that
all
authentication
counts
are
treated
correctly,
that
we
understand
why
and
when.
If
you
have
some
failures
during
the
protocol,
we
we
can
increment
or
decrement
the
counter
so
that
some
attacks
ways,
for
example,
incorrect
elliptic
curve
points
or
something
wouldn't
lead
to
the
possibility
of
adversary
to
brute
force
password.
C
B
Analysis,
I
think
that
if
we
have
like
to
which
is
different
from
suspect,
because
those
two
points
instead
of
one
point
during
exchange,
it
doesn't
define
key
syndication
after
the
process.
If
you
clearly
define
which
difference
do
you
have,
maybe
it
will
be
helpful
for
the
developers
of
the
protocols
to
choose
one
and
one
will
command
now
we
have
a
great
document
by
ill
max
meet
the
requirements
for
Peggy's
schemes.
I,
don't
remember
the
number.
C
B
C
B
B
I
M
N
L
O
M
M
So
if
your
search
papers
in
literature,
I
believe
we're
being
more
than
100
yeah
yeah,
it's
a
new
protocol,
so
probably
at
least
more
than
10
yeah,
because
of
some
may
be
already
compromised
already
have
been
found.
Security
flaws,
so
even
the
survived
one
should
be
more
than
ten.
So
in
that
case,
some
kind
of
comparison
maybe
may
be
necessary
like
to
heal
why
we
selected
this
one,
why
it
is
good
something
like
this
now
into
consideration.
All
the
security
comparison.
L
M
A
P
All
right
that
takes
me
okay,
so
thank
you.
I'm
Dan
Harkins.
So,
as
many
of
you
may
know,
there's
a
lot
of
authenticated
key
exchange
protocols
that
use
raw
public
keys
to
authenticate
the
peers
and
to
a
do
proper
authentication.
You
got
to
trust
the
the
public
key
and
a
lot
of
these
protocols.
Don't
even
mention
how
you
can
trust
one
of
these
exchange
keys,
but
usually
when
they
do,
they
say
something
like
well,
it's
in
a
manner
outside
the
scope
of
the
protocol,
so
that
gives
rise
to
ad
hoc
ways
of
doing
this.
P
That
are
probably
not
secure
and
they
probably
do
not
take
into
account
all
of
the
things
that
they
should,
for
instance,
RFC
72
50,
which
is
how
to
use
raw
public
keys
with
TLS
mentions
that
one
of
the
caveats
is
that
you
have
to
be
able
to
bind
an
identity
to
the
key.
In
addition,
even
if
you
do
figure
out
how
to
bind
identity
to
a
key,
if
you
don't
do
proof
of
possession,
when
you
exchange
the
keys,
you
can
be
susceptible
to
an
unknown
key
share
attack.
P
So
I
think
that
we
need
a
way
to
have
a
standard
programmatic
way
to
exchange
these
raw
public
keys.
That
will
give
you
integrity
in
the
received
key
bind
the
identity,
an
authenticated
entity
into
the
key
like
7250,
says,
and
do
proof
of
possession,
and
also
it
should
be
robust
and
easy
to
use
and
hard
to
misuse,
by
which
I
mean
that
there
shouldn't
be
a
whole
lot
of
configuration
options,
people
who
are
not
sophisticated.
You
should
be
able
to
use
this
easily
and
if
they
use
it
incorrectly,
it
should
just
fail
easily.
P
The
you
know,
your
favorite
authenticated
key
management
protocol
is
so
the
goal
is
then,
of
course,
it's
got
to
be
resistant
to
attack,
active
attack,
passive
attack
and
offline
dictionary
attacks,
because
these
keys
are
most
likely
going
to
be
identity
keys.
We
don't
want
the
protocol
to
fail
if
the
same
key
is
used
with
a
multitude
of
peers.
Right
I
want
to
have
a
minimal
number
of
primitives
used,
because
this
may
be
useful
for
some
kind
of
IOT
applications
and
basically
on
the
completion
of
peak
acts.
We
want
these
properties
that
I
had
mentioned
previously.
P
P
So
this
is
the
first
phase
and
again
this
is
just
spake,
and
we
just
heard
about
spake,
so
I'm
not
going
to
spend
a
whole
lot
of
time
on
this
slide,
but
just
keep
in
mind
that
it
starts
out
with
Alice
and
Bob
have
a
password
and
if
they
have
the
same
password,
then
they'll
have
this
shared
secret
Z
at
the
bottom
here.
So
then
the
second
phase
is
assuming
that
Alice
hasn't
at
MDE
a
or
her
private
identity.
Key
is
lowercase
a
and
uppercase
a
is
a
republic
identity.
P
Key
Bob
is
a
similar
key
B.
So
what
Alice
does
he
takes
her?
Assuming
this
is
elliptic
curve?
We
can
just
talk
about
point
multiplication.
Alice
takes
her
private
identity,
key
multiplies
it
Bob's
ephemeral
share
and
she
gets
a
secret
then
that
she
uses
with
an
H
Mac
to
hash
in
her
identity,
her
public
key
and
the
two
shares
from
the
femorals
bake
to
exchange.
P
She
sends
that
over
to
Bob
with
her
identity
key
encrypted
by
AES
s,
IV
with
key
Z
and
aad
of
a
single
octet
of
the
value
0
Bob
gets
this,
and
the
first
thing
he
does
is
try
and
decrypt
it.
So
if
SIV
decryption
fails,
protocol
fails
if
it
succeeds,
and
that
means
bob
is
authenticated
Alice,
because
Alice
has
been
able
to
generate
a
blob
of
bits
that
properly
is
authenticated
with
Z
and
Z
can
only
be
constructed
by
somebody
who
knew
the
password
and
he
shared
the
password
Alice.
Therefore,
this
is
Alice.
P
He's
authenticated,
Alice
spake
to
who's
benefit
ated.
Here
he
then
takes
the
Alice's
identity,
key
checks.
If
it's
valid,
if
it's
not
protocol
fails,
if
it
is,
then
he
generates
his
copy
of
what
he
thinks
you
should
be
called.
Au
prime,
so
basically
takes
his
private
ephemeral
share,
multiplies
it
by
Alice's
identity
key
and
does
the
H
Mac.
If
the
two
values
are
different
fail,
if
not,
he
generates
his
own
digest
with
his
again
private
identity.
Key
and
Alice's
ephemeral
share.
He
generates
this
digest,
sends
it
off
with
his
public
key
Alice
gets
it.
P
P
She
has
an
assurance
that
this
really
is
Bob's
key
because
it
was
sent
over
this
channel.
It
was
authenticated
by
Bob
or
authenticated
to
Bob
based
one
spake
to,
and
she
know
the
clubs
possesses
his
private
key,
because
the
trick
that
we
did
in
the
exchange
with
the
hmxi,
jest
and
so
Bob
has
the
similar
assurances
to
Alice's
public
key.
That
Alice
has
with
Bob's
public
key.
So
basically
now
these
public
keys
are
trusted
for
use
in
ike
TLS,
ad
hoc,
whatever
your
favorite
authenticated.
P
Key
management
protocol
is,
and
I'd
like
to
note
that,
while
Alice
and
Bob
exposed
their
identities
during
peak
acts,
the
identity
keys
that
they
they
end
up
getting
trusted
are
not
exposed,
so
those
could
be
used
to
provide
a
modicum
of
privacy
and
the
future
use
for
whatever
underlying
key
exchange.
Protocol
you're,
gonna
use
so,
for
instance,
Alice
and
Bob
in
their
office
could
do
peak
X
now
they've
got
these
public
keys.
Now
Alice
can
go
half
while
you're
on
the
world
and
she
can
do
an
IKE
exchange
or
keyless
exchange
with
Bob.
P
Nobody
really
knows
what
it
is,
because
these
are
just
raw
public
he's
going
back
and
forth,
but
of
course
Alice
knows
it's
Bob
Bob
visits,
Alice
voila.
So
the
current
version
of
documents,
for
there
are
three
independent,
interoperable
implementations.
It
has
received
some
crypt
analysis
Stanislav.
Thank
you,
Greg
Rose
also
did
some
review
comments
were
posted
in
the
list.
P
The
difference
between
three
and
four
is
I
added
some
theory.
These
were
all
specific
groups,
so
I
added
some
specific
row,
specific
groups
for
some
popular
ECC
and
and
mod
P
groups
and
I-
think
it's
a
it's
a
I,
don't
say
complete,
but
it's
a
mature,
so
being
it's
somewhat
mature
I
would
like
it
to
be
adopted
as
a
see
if
our
G
work
I,
don't
and
hopefully
we
could
send
it
to
the
crypto
review
panel
or
whatever,
and
let's
just
check
how
many
people
have
read
the
document.
A
O
C
C
C
P
Other
party
is
that
has
the
you
want
to
buy
denied
any
did
that
public?
He
so
you
know
the
public.
He
is
the
identity,
no,
so
as
70
to
50
states
when
you're
doing.
If
you
want
to
use
Rockies
with
TLS
the
challenge
that
they
stated
there
was
that
you
want
to
know
who
that
who
is
bound
to
that?
What
identity
is
bounded
that
public?
P
He
yes
you're,
using
that
that
public,
he
as
you
know
the
proxy
for
the
identity,
but
who
is
behind
that
that
public
key,
if
you
just
dude,
if
he
hum,
there's
no
authentication
yeah,
you
know
that
somebody
out
there,
whoever
he
is,
has
a
private
key
associated
of
the
public
key
that
you
just
got.
But
you
don't
know
who
who.
C
P
P
P
C
P
F
Popping
I
had
a
really
hard
time
in
the
document
figuring
out
what
you
called
identities
I
understand
that
you're
binding
them
in
that
really
what
it
they
sort
of
floated
around
a
bit.
So
I
would
say,
if
you're
having
a
hard
time
getting
people
to
understand
this.
That
was
the
part
that
I
got
caught
and
and
by
the
way,
I'm
still
caught
up
and
I'm,
not
saying
I
understand
it
now,
since
that
is
sort
of
the
extra
sauce
that
you've
got
here,
I
think
you
need
to
be
a
lot
clearer
about
it.
Okay,.
B
Stanislav,
thank
you
again
for
your
document.
I
think
it's
in
a
very
good
condition,
and
maybe
just
a
minor
revision
is
needed
to
be
ready.
One
in
equation:
I
sent
them
to
your
cakes
is
going
to
be
used
in
some
IOT
protocols
and
the
one
question
that
maybe
is
relate
to
all
packets.
What
do
you
think
about
usage
of
pages
in
messengers.
C
B
C
C
L
Paul
did
regarding
the
actual
identities
that
are
going
on,
because
yeah
I
know
I
didn't
really
understand
what
kind
of
identity
was
being
bound
and
what
information
was
in
that,
so
it
sort
of
seemed
like
Alice
and
Bob
are
authenticating
each
other
based
on
the
password
that
they
assumed
only
each
other.
No,
but
then
they
just
have
to
take
on
faith
that
the
person
who
knows
the
paths
were
the
person
who
knows
the
password
is
asserting
some
identity
information
and
they
have
like
their
personal
trust
in
the
other.
Person
is
what's
mental.
P
P
Than
just
the
person
who
knows
the
password?
Yes,
because
there's
the
identity
of
the
person
who
you're
sharing
the
password
with,
but
then
once
you
do
pique
X
now,
there's
an
identity
that
you
is
behind.
I,
guess
that
it
then
he
gets
transferred
into
the
public
key
that
you're
not
going
to
be
using
and
I
I.
Don't
think
that
that
that
might
not
be
explained
very
well.
Yeah.
L
P
I
I
would
imagine
that
you
know
this
is
this
is
kind
of
high
level
and
it
doesn't
define
a
transport
or
anything
like
that.
But
I
would
imagine
that
if
somebody
is
going
to
implement
this
in
some
protocol
that
that
stuff
would
be
instantiated
somehow
they
would
an
identity
would
be.
You
know,
somebody's.
L
Q
Moskowitz
consulting
Dan
III,
thank
you
for
confirming
that
we
simply
do
not
know
how
to
do
any
negotiation
without
some
side
channel.
Your
side
channel
is
here's
a
password
and
then
we
go
from
there.
We
simply
don't
know
how
to
do
this,
which
is
okay.
We
admit
that
there
is
always
some
starting
point,
some
side
channel
off
the
way
exchange
it
gets
it
going.
However,
moving
on
from
that
little
may
be
facetious
comment.
Let.
Q
Q
O
Q
In
your
case,
we
got
this
password
exchange
and
then
from
there
we
can
boot
up
to
something
better
than
passwords.
There's
almost
a
facetious
comment,
the
really
point
I
want
to
to
bring
here
in
terms
of
discussion
identity.
This
is
something
which
has
been
going
on
elsewhere:
an
identity,
oriented
networking
and
a
couple
of
areas,
and
particularly
in
some
of
the
mobility
areas,
and
this
may
factor
very
well
and
with
some
of
the
ever
see
concerns
which
I
have
written
a
draft
begin.
Q
Reading
draft
on
and
begin
to
write
a
draft
on
how
to
address
the
privacy
concerns-
and
this
may
be
a
very
one
of
the
very
important
tools
by
which
we
can
omit
to
a
exposure
of
a
base
identity,
an
initial
set
up
with
some
hands
on
a
truly
private
unrecognizable
identity.
That
Eve
cannot
relate
to
anything
else
that
she
has
observed
or
mal
has
picked
up
on
the
network.
You
know
modulo.
P
Traffic
analysis
playing
like
that,
but
yet,
if
that's,
what
went
away
again?
Don't
don't
don't
don't
bring
it
back,
but
you
know
Allison
bobbin
and
take
to
do
send
their
identities
so
that
you
know
when
Bob
gets
this
message
he
knows
which
password
to
use
right.
But,
as
I
noted
in
the
privacy
note,
the
public
keys
that
end
up
eating
exchanged
are
are
still
secret.
In
fact,
Allison
Bob
could
disclose
the
password
they
used
when
they're
done
and
there's
no
loss
of
security
mm-hmm
and
the
attacker.
P
N
Hi,
Mooji
and
I
want
to
ask
the
question
that
when
we
use
this
raw
public
key
yet
first
we
have
some
the
the
assumption
that
the
public
key
is
bonding
with
some
identities.
And
now
you
want
to
have
I'm
sorry,
Brad
Wilson.
What
I
didn't
do?
Okay,
we
know
the
public
key
is
belong
to
who
and
now
we
want
now
you
want
to
to
transfer
the
public
key
to
the
to
to
the
another
side,
and
so
we
need
some
cement
real
keys,
and
this
symmetric
keys
is
also.
N
That
means
that
the
one
side
is
to
know
the
symmetric
key
belong
it
bond
to
the
other
side.
There
they
identity,
so
I
think
that
is
the
endless
loop,
because
that
we
still
need
to
face
the
problem
that
we,
how
to
transfer
the
this,
the
cemetery
key
to
the
other
side,
and
we
still
need
to
face
these
problems.
Well,.
P
That's
what
this
is
supposedly
trying
to
to
address
is
the
e
or
you're
able
to
take
some
short
password,
passcode
something,
and
you
can
parlay
that
into
a
trusted
public
key,
then
that
trust
of
public
key
is
used
with
Ike
or
TLS,
or
something
to
authenticate
a
symmetric
key
that
you
then
used
to
encrypt
all
your
traffic.
So
I
I,
don't
think
it's
an
endless
loop,
I
think
I've
I
think
I've
closed
a
loop
actually,
but.
N
P
Question
because
just
passing
a
republic,
he
does
not
prove
possession
of
the
private
key
and
it
doesn't
really
bind
an
identity
to
that
key.
That's
one
of
the
ad
hoc
techniques
that
I
was
explaining,
or
probably
they
don't
they're
not
done
cognizant
of,
like
the
security
caveat
in
an
exchange
of
public
key
somebody.
Could
you
think
you're
exchanging
public
key
with
me,
but
actually
rich
stood
up
and
sent
his
key
in
in
my
stead
and
now
he
you
don't
actually
share
a
key
with
me.
P
B
J
The
video
okay
sounds
good
yeah,
pink
box,
hey
yeah,
so
so
thanks
thanks
for
your
time,
I'm,
not
so
this.
This
is
a
you
know
currently
for
information
for
intra
interest.
I'm
not
so
this
talk,
I'm,
not
trying
to
kind
of
immediately
propose
a
working
group
action
but
present
some
recent
research
in
from
my
group
at
EPFL
and
and
get
some
preliminary
feedback
and
and
discussion
as
to
whether
there
might
be
interest
down
the
road.
So
you
know
many
of
you
have
heard
the
you
know
all
the
ruckus
about
block
chains.
J
You
know
my
I'll
admit:
I'm,
not
unbiased.
My
lab
has
been
doing
a
lot
of
work
on
on
block
chain.
You
know
development
of
next-generation
block
chain
software
and
protocols,
and
you
know
so
there's
a
lot
of
interest
a
lot
of
different
things.
People
are
trying
to
do
with
it,
but
of
course
it's
is
still
a
very
early
kind
of
early
stage.
In
most
cases
in
particular,
you
know
kind
of
most
of
the
currently
deployed
blockchain
systems
that
are
out
there
and
protocols
are
out
there
kind
of
stuck.
J
You
know
in
a
lot
of
ways,
especially
Bitcoin
and
aetherium,
as
well
as
many
of
the
permissions
block
chains
which
which
introduce
all
kinds
of
single
points
of
compromise.
You
know
so
so
there's
a
lot
of
this
is
still
very
much.
You
know
kind
of
ongoing
research
activity,
but
this
is
a
crypto
forum,
not
a
blockchain
forum.
I
get
that
so
I
want
to
narrow
down
and
focus
in
on
one
particular
kind
of
narrow
issue
and
they
and
the
cryptographic
abstraction
construction
that
that
I
I'm
hoping
might
be
of
interest
anyway.
J
So
in
general,
there's
a
lot
of
discussion
about
helping
to
secure
things
by
putting
stuff
on
a
blockchain
for
transparency,
for
example.
If
you
might
think
of
it's
been
suggested
that
a
certificate
transparency,
log
server,
is
kind
of
a
blockchain
thing,
and
you
know
it
kind
of,
is
it
kind
of
isn't?
J
But
you
know
that's
a
separate
topic
there's,
but
you
know
people
put
certificates
or
other
things
on
you
know
the
Bitcoin
or
aetherium
or
other
block
chains
in
order
to
try
to
you
know,
get
something
in
the
public
record
and
and
be
and
be
able
to
be
sure
it's
in
a
tamper-evident
lock.
One
of
the
important
issues
with
all
of
these
things,
though,
is
once
you
put
something
on
the
blockchain.
J
How
does
someone
who
wants
to
verify
that
it's
on
the
blockchain
actually
know
that
it's
on
the
blockchain
actually
verify
this,
and
this
this,
you
know,
gets
to
the
efficient
verification
problem
and
I
think
this
is
a
very
general
problem,
especially
for
light
mobile
devices.
For
example,
you
know
you've
received
a
Bitcoin
payment.
How
do
you
know
it's
on
there,
or
somebody
says
they
have
put
a
certificate
on
a
log
server
of
some
kind,
whether
it's
a
certificate,
transparency
or
or
another
blockchain?
J
How
does
how
does
a
potentially
lightly
provisioned
node
that
doesn't
want
to
follow
the
blockchain
all
the
time
securely
and
efficiently
catch
up
on
the
state
figure
out
and
figure
out
if
a
transaction
or
certificate
or
something
of
interest
actually
is
or
is
not
on
the
blockchain?
Well
for
for
systems
like
that,
try
to
use
Bitcoin
or
etherion
like
block
chains,
what
the
client
has
to
do
is
actually
catch
up,
at
least
by
downloading
all
the
block
headers
and
you
know,
Bitcoin-
produces
these.
What
once
every
ten
minutes,
these
theory
introduces
them.
J
That's
a
single
point
of
failure
or
compromise
that
by
which
you
can
be
tricked
into
accepting
a
fake,
blockchain
and,
and
you
can
be
tricked
out
of
out
of
the
losing
the
transparency
property
right
and
this
supply
as
I
as
I've
mentioned
in
the
context
of
a
certificate
transparency.
Quite
a
few
times.
This
reliance
on
gossip
creates
both
complexity,
privacy
issues
where
you
have
to
gossip
with
many
nodes.
All
the
time
in
order
to
you
know
know
to
have
confidence
that
you
have
a
secure
state,
and
so
it's
a
privacy.
J
J
So
in
this
talk,
I'm
taking
kind
of
a
bottom-up
approach,
just
focusing
on
the
cryptographic
thing.
The
actual
paper
is
about
the
the
secure
software
supply
chain
problems.
A
software
and
update
transparency.
I
won't
be
talking
about
that
much
here
for
lack
of
time,
but
I'll
be
giving
a
talk
in
HR
PC.
This
Friday
that'll
that'll
focus
more
on
that
high-level
on
kind
of
the
software
updates
and
transparency
as
a
policy
goal
and
stuff
like
that.
So
I
wanted
to
focus
more
level
on
the
low
level
mechanisms.
J
Now
now
there's
no,
we
haven't
tried
to
create
any
any
internet
draft
for
skip
chains.
Yet
so
that's
the
the
abstraction
I
want
to
talk
about,
but
but
this
builds
on
our
collective
signing
work,
which
does
have
a
very
preliminary
draft
I
presented
it
last
time
and
we
haven't
yet
had
a
chance
to
really
rev
that
draft
it
needs.
It
needs
some
revisions.
J
A
very
compact
bitmap
that
says
who
signed
and
who
did
and
who
didn't
contribute
to
give
different
signature
basically
allows
a
you
know,
distributed
decentralized
group
of
of
nodes
to
collectively
sign
off
on
something
that
they
something
they
verified,
such
as
a
block
in
a
blockchain
right
now,
a
traditional
blockchain,
by
which
I
basically
mean
just
kind
of
any
hash
link
data
structure.
You
know
kind
of
these
existed
long
before
the
blockchain
became
a
buzzword.
Of
course
you
typically
have
a
block.
J
You
know
a
set
of
raw
blocks
or
records
in
which
each
one
is
linked
to
the
previous
one,
with
a
with
a
hash
right,
and
so
this
gives
you,
the
nice
property
that,
if
you
have
agreed
on,
if
two
nodes
have
agreed
on
the
latest
the
correct
value
of
the
latest
thing
they
can,
then
they
can
authenticate
anything
backward
in
history
just
by
kind
of
walking
back
from
the
front.
So
it
gives
you
kind
of
backward
security.
J
If
you're
don't
currently
have
the
latest
history
and
you
want
to
get
the
latest
state,
then
you
need
to
gossip
or
use
some
other
mechanism
to
get
that,
and
so
so
this
so
an
alternative
way
to
do
that
is
to
is
to
use
something
like
a
collective
signature,
a
multi-sig,
a
sign-off
process
in
which
some
number
of
validators
or
consensus
group,
members
and
and
I'm
kind
of
leaving
out
a
scope
is
important
but
different
topic.
How
you
pick
that
group
I'm?
J
You
know
leaving
that
as
a
separate
question
for
now,
but
the
the
basic
idea
here
is
is:
if
you
have
such
a
group
picked
somehow,
then
the
group
members
can
you
know
periodically
when
when
when
they
create
a
new
block,
they
can
create
forward
links.
So
when,
when
the
next
block
appears
in
the
sequence,
the
group
creates
a
forward
link
kind
of
a
link
forward
in
time,
which
obviously
can't
be
a
hash,
because
we
need
time
travel
and
we
need
to
break
the
crypto
cryptographic
properties
of
a
hash,
but
we
can
use
signatures.
J
J
You
know
set
of
public
keys,
a
set
of
private
keys
to
collectively
sign
it
forward
link,
so
this
basically
makes
the
blockchain
cryptographically
trivet
reversible
in
both
directions,
and
so
that's
that's
the
nice
property,
namely,
if
I'm
behind,
if
I'm
a
light
client
that
has
been
offline
for
a
while
and
I
want
to
know,
if
is
that
software
update
or
if
that
new
set
of
root
certificate,
certificate,
authority
keys
or
that
new?
Whatever?
Is
that
valid?
J
That
I
can
just
basically
check
one
or
a
few
collective
signatures
that
might
be
given
by
anyone
else
like
a
peer
I
could
I
could
be
given
a
new
update
from
from
a
peer
or
somebody
else.
Somebody
who
I
don't
trust
and
and
securely
wat
for
forward
on
the
blockchain
right
and
and
validate
anything
going
forward,
as
well
as
back
to
dig
down
a
little
deeper
one
of
the
key.
J
We,
you
know
the
forward
link
says
not
only
okay.
This
is
the
next
block,
but
this
is
also
the
Delta
that
you
know
the
public
keys
you
have
to
add
or
remove
to
the
change
roster
in
order
to
validate
future
collective
signatures.
So
in
this
case
a
roster
change
happened
after
block,
so
the
the
so
once
block
three
appears-
and
you
know
we
know
the
new
roster
and
the
new
block
three.
J
When
we
go
back
to
block
2
and
create
an
addendum,
basically
collectively
signed
using
roster
one
with
the
forward
link
and
the
Delta
and
needed
for
somebody,
you
know
who's
following
the
chain
forward
to
get
from
roster
1
to
roster
2
and
then
from
there
on
you
know
so
use
so
the
point
is
you
can
kind
of
securely
walk
forward?
One
block
at
a
time
right?
Ok,
so
so
that's
the
that's
the
basic
idea.
So
in
in
principle,
this
gives
us.
J
You
know
traversable
reversibility,
arbitrarily
far
forward
or
back
in
history,
with
important
caveats,
one
important
caveat
being
efficiency.
You
know
kind
of
if
you're
getting
producing
new
blocks
very
quickly.
It
might
be.
You
know
it
might
take
a
lot
of
walking
forward
or
back
to
get
to
where
you
want,
or
it
might
take
a
big
proof.
You
might
have
to
hold
a
lot
of
blocks
and
forward
links
in
order
to
prove
something
is
on
the
blockchain
and
that's
what
the
the
skip
part
of
skip
changes
about.
J
Basically,
obviously,
inspired
by
the
well-known
skip
lists,
algorithm
and
basically
you
know
with
that
inspiration.
We
basically
add
longer
forward
links
and
longer
backward
backward
links,
so
the
you
know
long
forward
links
is
nothing
really
new.
The
our
long
backlinks
is
nothing
really
new,
but
but
long
forward
links
is,
is
kind
of
you
know
what's
what's
more
interesting
here,
because
it
provides
the
property
that
for
any
transaction
of
interest,
if
I
have
a
device
and
I
want
to
prove
to
anyone
that
you
know
this.
J
Software
update
this
certificate
or
this
route
see
a
store,
update
or
whatever
is
valid,
and
you
know
persuade
another
device
of
that.
I
only
have
to
keep
a
logarithmic
size
set
of
collectively
signed
forward
links
because
the
long
forward
links
kind
of
compress
and
encapsulate
the
updates,
even
if
they're
there
might
be.
You
know,
multiple
roster
updates
are
along
the
way
the
the
long
forward,
link,
kind
of
compresses
them
all
into
one
hop.
J
So
I
need
to
keep
only
a
logarithmic
size,
small
blob
of
information
in
oratory,
in
order
to
convince
anybody
else
anywhere
regardless
of
how
recent
or
how
old
their
state
is
that
this
is
a
valid
new
new
update,
right
and
so
yeah
now
you
know
it
also.
So
you
know
I
can
convince
any
of
anybody,
however
old,
but
but
it
also
has
the
I
think
desirable
complimentary
property
that,
if
I'm
trying
to
show
this
to
somebody
who's
relatively
up-to-date
who's,
not
that
out-of-date,
they
don't
necessarily.
J
More
recent
signatures
and
this
guarantees
that
I
don't
have
to
rely
on
really
old
signatures
if
I'm
not
not
that
out-of-date,
which
is
an
important
security
property
as
well.
Okay.
So
in
summary,
the
the
reason
we
came
up
with
this
and
I
think
what's
interesting
about
this.
Is
this
structure
just
as
a
cryptographic
structure?
Is
it
allows
anybody
who
wants
to
follow?
J
You
know
what's
what's
on
this
blockchain
gives
it
give
them
an
efficient
way
to
following,
but
either
forward
forward
or
backward
in
time,
keeping
each
other
up-to-date
in
in
a
peer-to-peer
fashion,
if
that's
useful,
and
even
if
the
set
of
signers
and
the
set
of
signing
keys
might
be
rotating
either
either
quickly
or
slowly.
How
am
I
doing
on
time?
Okay,
sorry,
so
yeah,
so
so
yeah
I
wanted
to
kind
of
leave
the
applications
to
the
end.
J
This
is
useful,
but
you
know
for
certificate
type,
applications
and
a
lot
of
people
are
interested
in
and
of
course,
like
I
mentioned,
I'll
be
talking
about
kind
of
the
software
updates
and
software
update
transparency
applications
in
HR
PC.
This
is
all
all
implemented
in
prototype.
You
know
experimental
software,
but
at
any
rate
you
know
kind
of
that's
that's
that
for
now
just
interested
in
hearing.
If
there's
any
comments,
feedback
questions,
Thanks.
I
J
And
longer
hops,
yeah
yeah,
so
the
very
good
question
so
the
so
I
mentioned
so
so.
This
Delta
4
associated
with
a
particular
forward
link
that
when
you
have
a
longer
forward
link
and
this
forward
link,
crossed
several
roster
updates.
Basically
that
Delta
just
needs
to
encode
all
of
the
you
know
kind
of
the
the.
J
So
if,
if
only
one
key
changed
and
that
key
changed
multiple
times,
then
the
Delta
only
needs
to
contain
the
latest
key.
On
the
other
hand,
if
two
different
keys
changed
at
two
different
times
than
the
Delta
will
contain
those
two
key,
those
two
changes
in
one
block,
so
you
get
some
of
some
compression
effect
and
you'll
get
the
proud
and
kind
of
the
nice
worst-case
property
that
you
know
any
Delta,
no
longer,
no
matter
how
long
it
is
will
not
have
more
than
the
total
number
of
keys
in
the
new
roster.
So.
R
J
R
R
J
Yes,
and
no,
the
answer
to
that
is,
is
the
kind
of
separate
and
orthogonal
question
I
mentioned
as
how
you
pick
that
group.
Now
one
of
the
things
that
in
our
research,
we
showed
one
way
to
pick
that
group
is
using
proof-of-work
miners.
So
we
could
have
you
know,
kind
of
the
Bitcoin
miners
or
the
ethier
miners.
J
If
they
agreed
to
do
so
or
you
know,
if
some
subset
of
them
agreed
to
do
so,
they
could
use
the
proof
of
work
based
consensus
group
selection
mechanisms
that
we've
shown
in
in
our
research
like
ARB,
is
going
protocol
and
pick
the
consensus
group
that
way
and
you'd.
Then
you'd
get
exactly
the
same
security
properties.
J
You
know
strengths
and
weaknesses
that
Bitcoin
does,
but
you
could
all
I
think
there
are
perfectly
reasonable
ways
of
other
ways
of
picking
consensus
groups
such
as,
for
example,
the
set
of
certificate
authorities
that
a
given
brown
browser
vendor
has
in
their
root
store.
You
know,
there's
various
decent
answers
to
that
question:
okay,
okay,
thank
you.
Okay,.