►
From YouTube: IETF94-OPENPGP-20151103-1710.webm
Description
OPENPGP meeting session at IETF94
2015/11/03 1710
C
B
C
I
disagree:
this
is
a
good
animal,
so
I
think
we
should
I
think
we
should
get
started
yeah
we're
at
about
ten
past
welcome.
This
is
the
open,
PGP
working
group
meeting
at
the
IETF
94,
if
you're
not
here,
for
a
BGP
you're
in
the
wrong
room
so
but
you're
welcome
to
stay
yeah,
we're
your
chairs,
dkg
and
christopher
buildings
dope.
So
if
you
haven't
already
seen
the
note
well,
this
is
the
note
well
we're
well
into
the
conference.
We
should
have
seen
this
multiple
times.
It's
also
cure
here.
C
C
Have
a
brief
discussion
of
that
talk
about
algorithm
deprecation,
the
fingerprint
issue
which
we
kicked
around
quite
a
bit
and
I
think
we
need
to
try
to
come
to
some
sort
of
conclusions
on
the
symmetric
encryption
upgrade,
which
brian
will
talk
about
brian
also,
I
think
we'll
talk
about
questions
about
how
much
metadata
we
are
leaking
string.
Two
key
conversions
and
policies
about
the
different
registries
that
are
involved,
so
we've
got
an
hour
and
a
half
might
be
a
bit
of
a
sprint
to
get
through
it
all
so
we'll
try
to
keep
it
moving.
C
C
C
If
you
are
in
your
own
XMPP
say
yes,
I
can
hear
you,
let's
see
whether
they
say
that
okay,
we
got
at
least
one
person
saying
yes
cool,
so
some
folks
are
hearing
us
on
IRC
T,
that's
good,
so
we
have
a
volunteer
to
draft
a
first
stab
at
the
48
abyss,
which
is
verner
who's.
The
lead
developer
for
group
EG
well
situated
to
understand
the
problems
with
the
protocol.
C
D
So
yeah
at
this
point
you
know
the
first
of
all
quick
question:
everyone
here
who
would
be
contributing
to
the
document
and
I
hope
it's
a
lot
of
people
here,
comfortable
with
mark
down
and
get
the
workflow
anyone
not
comfortable
with
it.
D
Okay,
you
have
questions,
come
and
talk
to
us
after
myself,
for
our
dkg
and
there's
also
supposed
to
be
some
wiki's
coming
out
fairly
soon
about
this
kind
of
workflow.
For
for
for
IDs
right
now
we
are
debating
whether
the
patches
only
get
distributed
via
get
fine
via
email
or
if
we
also
use
something
like
get
lab
or
something.
But
you
know
anybody
who
has
any
feelings
on
that
one
way
or
another
feel
free
to
speak
up
either
here
on
the
email
list.
D
D
So
I
get
actually
quick
show
of
hands
how
many
people
would
prefer
an
email
path
to
serving
patches
raise
your
hands
if
you
want
to
distribute
patches
via
email,
a
few,
how
many
people
would
prefer
this
to
redo
do
and
one
raised
on
ok
how
many
people
be
interested
in
using
get
lab,
which
you
haven't
used
it
a
little
bit
like
github,
except
it's
open
source
and
friendlier
anyone
in
favor
of
using
get
lab
and
workflows?
Ok.
So
it's
about.
C
E
C
E
So
you
might
be
useful
to
talk
a
little
bit
that,
particularly
if
people
are
implementing
and
releasing
yeah,
so
that
you
know
so
that
they
at
least
maybe
ask
people.
Are
they?
You
know,
because
you
don't
necessarily
want
people
releasing
stuff
ahead,
or
you
really
nice
to
kind
of
have
some
kind
of
coordination
between
when
this
document
hopes
to
be
finished
versus
when
people
will
have
code
may
be
there,
maybe
they're
releasing
very
frequently,
maybe
I,
don't
know.
I.
D
Mean
early
on,
we
charted
this
group.
We
talked
about
trying
to
make
this
a
fairly
short
process.
You
know
in
game
the
document
done
in
a
year
year
and
a
half
were
lingering
a
bit
here.
So
I
guess
one
thing
I
was
contemplating
and
it's
again
it's
up
to
the
group.
D
If
we
get
this
into
get
fairly
quickly
and
actually
have
people
start
contributing
what
they
think
is
important
in
to
that
document
live
rather
than
going
through
fairly
long
cycles,
training
us
into
a
more
of
an
iterative
approach,
but
would
be
really
nice
I
think
if
we
could
still
try
and
adhere
to
that.
E
Yeah
and
I'm
not
trying
to
rush
it
I
mean
I'm
just
trying
to
say.
Maybe
you
know
we
really
nice
if,
whenever
the
or
LC
issues
that
the
code
people
are
releasing
actually
matches
that
yeah
and
sometimes
it's
easy
to
kind
of
412
kind
of
overtake
or
like,
and
so
you
know,
maybe
they
may
be.
People
do
a
whole
bunch
of
stuff
on
making
it
a
try
up
and
release
the
code
and
nobody
finishes
the
RSC
I
think
so
yeah.
So.
D
Eyeing
is
what's
the
sense
of
the
room
here:
do
we
want
to
try
and
make
a
sprint
and
get
this
thing
done,
and
you
know
wrapped
up
by
this
time
next
year,
people
think
that's
unachievable
or
to
feel
think,
that's
achievable.
A
C
So
I
think
that
we
need
to
get
this
draft
done
before
Cesar
completes,
and
that
may
mean
that
when
Cesar
completes
we
end
up.
If
we're
still
chartered
as
a
working
group,
we
can
add
a
an
algorithm
to
it,
but
we
know
that
there
are
existing
better
mechanisms.
Then
then,
what
was
currently
at
openpgp
that
are
long
overdue,
and
so
I'm
not
sure
that.
Well,
I'm
sure
that
we
don't
want
to
have
to
wait
on
Cesar
in
order
to
get
this
completed.
F
D
E
C
C
If
we
don't
integrity,
protect
this,
somebody
can
go
and
fiddle
with
the
cipher
text
and
it'll
change
the
plaintext
in
the
same
way
right.
You
flip
bit
7
and
it
flips
bit
7,
and
so
they
added
that
there
was
an
integrity
protection
added.
That's
called
the
message
to
MDC
mess
modification
detection
code
and
that
basically,
is
just
to
check
some
over
the
clear
text.
C
C
So
what
do
you
do
if
you
encounter
one
of
these
non
reproductive
encrypted
packets?
What
should
we
like?
What
do
we
tell
the
spec
go
to
tell
that
the
implementers?
What
do
you
do-
and
this
is
more
of
an
issue
because
we
are
dealing
with
stored
formats,
then
for
with
online
formats
right,
you
might
have
something.
That's
been
sitting
on
disk
for
25
years
before
the
invention
of
the
integrity,
protection
or
20
years.
F
Ford
EPFL
I,
don't
know
the
answer
to
that,
but
for
people
who,
for
those
who
know
more
about
PGP
history,
historical
behavior
than
I
do,
can
we
are
there
a
certain
kind
of
ciphers
or
certain
kind
of
easily
discernible?
Are
you
know
it
are
there
ciphers
that
are
that
have
to
our
knowledge,
never
been
used
by
implementations
without
integrity
protection
right?
So
some
of
the
not
so
old
ciphers
that
maybe
are
you
know
that
were
added
after
the
integrity
protection
was
there
and
we
believe
you
know
no
one
has
ever
generated
a
good.
F
C
C
So
I
would
just
threw
a
bunch
of
algorithms
up
here
as
things
that
we
could
consider.
Deprecating
I
put
question
marks
next
to
the
ones
that
I
thought
would
be
likely
to
be
more
controversial
and
no
question
marks
next
to
the
ones
that
I
think
are
less
controversial,
but
there's
still
no
question
of
what
do?
What
do
we
tell
an
implementer?
Maybe
we
can
tell,
and
the
answer
is
different,
I
think
for
for
symmetric
for
signature.
C
You
know
asymmetric
signatures
than
it
is
for
it's
different
for
verifying
signatures
than
it
is
for
decryption
right
I
mean
you
could
say,
never
accept
signatures
using
one
of
these.
We
Cal
guerrillas
and
just
it
doesn't
matter
that
you
have
a
stored
signature.
You
just
never
accept
it
in
a
modern
implementation
and
we
certainly,
we
can
say,
never
generate
these
things.
But
what
do
you
do
about
the
the
receiving
side?
C
So
I
want
to
ask
two
questions
and
anybody
who
want
who
has
comments
on
them?
Like
please
come
up.
One
question
is:
do
you
have
a
concrete
proposal
for
how
to
deprecate
dealing
with
stored
data?
How
did
every
algorithm
is
given
stored
data
and,
secondly,
are
there
specific
algorithms
that
you
feel
strongly?
We
should
deprecated
and
get
rid
of
and.
B
I
think
that
full
stole
data
when
there's
one
plus
week
is
to
advocate
of
debt.
I'm.
Sorry
I
didn't
understand
that
one
possibility
Christian
with
Emma
one
possibility
to
deal
with
store
data
is
to
have
a
bit
of
debt.
And
if
the
message
is
urgent
after
some
debt,
then
it
must
comply
with
the
latest
and
greatest.
D
Christopher
loading
stopping
my
hat
my
hat
off,
but
this
is
something
I
was
thinking
about
her
the
last
couple
days,
maybe
by
deprecation
we
might
consider
that
we
deprecate
the
ability
to
encrypt
with
that
algorithm,
but
leave
the
ability
to
decrypt.
With
that
algorithm
such
that
sort
data
you
can
still
get
at
in
your
channel.
I've
got
email
archives
going
back
longer
than
I'd
care
to
admit
and
there's
no
way
I'm
going
to
I'll
be
able
to
find
all
the
encrypted
messages
and
that
and
so
that's
one
possibility
as
well
just
deprecated
the
encryption
capability.
C
A
Rick
Saul's
also
I,
guess
in
me
this
is
what
mr.
said
before
decryption
after
a
date.
Sorry
decryption.
If
you
know
that
the
content
is
old,
is
one
thing:
the
decryption
of
content
you
you
can
tell
or
surmises
new,
should
also
be
deprecated
or
at
least
have
significant
warnings
right.
If
someone
someone
generates
a
of
some
inject
purports
to
give
you
a
set
of
log
files
that
are
encrypted
with
512
are
a
safe.
Last
week
you
probably
want
to
be
skeptical
yep.
C
C
C
Yeah,
I
think,
there's
there's
just
a
huge
nest
of
usability
issues
with
both
of
those
scenarios
and
users
already
don't
understand
what
we're
talking
about.
So
I
think
we
need
to
be
careful
about
any
guidance
that
we
give.
That
says
you
you
know
you
should
inform
the
user,
that
frog
nets
plural
bottle,
which
is
what
they
read
when
they
see
it
so
yeah.
So
I
don't
need
to
think
of
clearly
about
how
to
do
that,
but
but
I
it
sounds
like.
C
Is
there
anyone
in
the
room
who
opposes
creating
new
signatures
or
in
ciphering
using
deprecated,
using
things
that
we
choose
a
deprecated?
That
seems
like
that's
a
universal
consensus,
but
that's
that
that
side
at
least
is
easy,
and
so
the
hard
part,
then
is
just
what
do
you
do
about
the
consuming
side
of
these
mechanisms?
So.
C
If
people
have
is
for
what
to
do
with
consuming
sighs,
I
hope,
they'll
post
them
to
the
list
and
I
want
to
turn
the
question
to
the
question
of
which
of
these
things
can
we
actually
strike
with
with
the
deprecation
hammer?
So
I'll
ask
for
sort
of
a
sense
of
the
room?
I
guess
we
can?
We
can
walk
through
the
algorithms
one
by
one
Steven.
E
A
E
C
Yeah
I
I
think
that's
a
reasonable
way
to
approach
things,
particularly
if
I
mean
I
wonder
what
that
would
do
to
signature
verification,
for
example
right.
If
we're
talking
about
verification,
producing
warnings
or
failing
on
the
basis
of
stored
signatures
that
have
say
Shealeigh
deprecated,
shot
to
24
right
I,
don't
actually
believe
that
shot
to
24
is
currently
broken,
that
anyone
can
forge
signatures
across
it.
G
They're,
giving
in
but
I
everybody
has
an
old
signatures,
because
your
email
archives
are
are,
you
know,
are
there
I
have
them
for
ages
and
they
are
using
know
whatever
and
I
would
actually
want
to
be
able
to.
You
know
check
out
that
the
signature
is
still.
You
know
valid
at
some
point
that
there
is
oh,
of
course,
there's
a
problem
that
funny
the
public
key
at
some
point.
You
know
ten
years
laughter,
essentially
or
so,
would
it
be
difficult
because
they
2262
that
was
used
to
generate
there?
B
B
You
might
want
to
not
have
the
option,
but
even
not
of
it,
for
values
within
the
minute
attack
surface
whatever
so,
I
think
we
have
to
separate
those
two
problems.
We
have
to
have
to
do
the
running
letters
code
and
we
have
maybe
to
have
some
thing
that
is
specifically
used
when
we
are
accessing
archives.
A
G
Turkey
me
again,
I
I,
think
you
should
say
you
know
you
must
not
generate
any
of
those.
That's
that's
I,
think
it's
clear
me
when
she
must
not
create
any
of
those
old
stuff
and
I
actually
would
be
okay
to
say
that
okay,
you
shouldn't
you
know,
verify
them
without
any.
Without
certain
you
know
things
you.
Could
you
actually
say
that?
Okay,
if
you
want
to
verify
this
old
ones,
it
would
be
actually
or
processed
or
or
decrypt
them,
because
I
have
an
encrypted
email
from
you
know,
97.
G
That
would
actually
be
useful
to
read
some
point
and
I
would
actually
like
to
have
a
preacher
feature,
and
I
know
I'm
not
going
to
be
able
to
know
find
them
in
my
email,
archives
and-
and
you
know,
re
encrypt-
all
of
those
now
I
when
when
I
happen,
to
be
needed.
I
might
not
want
to
do
that,
but
of
course
it
would
be
also.
It
would
be
actually
be
very
unlikely
that
somebody
accident
hack
into
my
machine
and
modify
my
email
archive
to
modify
that
email.
G
It
is
possible
and
take
if
they
could
fake
the
cheezer's,
and
you
know
encryption.
They
can
do
that,
but
I
don't
keep
it
very
likely
it's
also.
So
it
could
be
something
that
you
have
to
give
you
know
some
common
line.
Option
use
the
old
format.
If
you
try
to
it
says:
oh
sorry,
this
is
old
format,
use
force
in
enforce
old
for
or
use
the
old
format
before
you
can.
Actually,
you
know
booth
anything
with
that,
so
you
have
to
do
some
user
action.
Something
like
that.
G
So
it's
actually
it's
clear
that
you
actually
want
to
process
so
in
any
automatic
system
phone
process
any
of
those.
But
you
know
you
can
still
do
that
and
that's
some
something
that
I
think
it's
actually
very
important
to
keep
the
old
email
archives
and
all
that
that
kind
of
thing
so
that
you
can
still
process
it
would
be
really
annoying
to
loose.
You
know
all
of
your
old,
you
know
encrypted
emails
because
universes
can
process
them
anymore.
A
E
So
Steve
Brown,
just
I
mean
I
agree
with
terror,
there's
own
stuff
that
you
have
to
deal
with,
there's
probably
in
the
combinations
of
all
the
algorithms
that
are
about
to
find
there
there's
probably
old
stuff
that
you
don't
have
to
deal
with
so
I.
Think
if
you,
if
you
set
the
bar
and
say
you
know
that
you
assuming
the
working
group
liked
it
I
mean
you
say
that
by
default,
they're
all
gone.
G
Most
of
the
people
who
are
interested
in
this
or
who
would
be
actually
using
those
they
are
not
here
and
they
are
not
going
through
the
email
archives
to
see
if
they
have
an
old.
You
know
if
somebody
has
ever
sent
an
email
using
subtle
24,
because
they
might,
they
have
never
used
that,
but
somebody
mug
had
sent
an
email
to
them.
That
is
using
that
they
don't
know
so.
Two
people
actually
don't
know.
I
have
no
idea
what
signature,
algorithms
or
hassle
where
these
people
have
used
to
send
to
the
emails
to
move
me.
F
Brian
Ford
I,
so
I
don't
think
we're
going
to
find
an
ideal
answer
to
this
question.
Personally,
I'm
kind
of
in
favor
of
just
you
know,
warn
the
user
on
the
you
know
decryption
or
verification
side.
You
know
maybe
allowed
a
warning
for
more.
You
know
more
for
more
known
week
schemes,
but
okay
in
the
longer
term,
I
think
you
know
we
can
try
it
so
I
wanted
to
ask.
Have
any
open
pgp
implement,
do
any
open,
pgp
implementations
come
with
a
search
and
upgrade
tool
either
you
know
kind
of
for
hard
drives.
F
You
know,
search
your
hard
drive
for
old
things
and
re-encrypt
to
re-sign.
You
know
with
this
new
key.
You
know
stuff
like
that
or
even
you
know,
go
through
my
email
archive
and
you
know,
search
an
upgrade.
You
know
openpgp,
you
know
it
seems
like
well,
you
know
it
wouldn't
be
totally
trivial.
It
would
be
something
really
nice
to
have.
We
could
try
to
you
Oh
encourage
implementers
to
provide
something
like
that
suggest.
Whatever
you,
we
can't
guarantee
it'll
happen,
but
you
know
I
mean
just
I.
F
C
Just
want
to
observe
that
for
signature,
verification
in
particular,
this
is
dkg
no
hats
for
signature
verification
in
particular.
All
signatures
have
a
date
stamp
in
them,
so
we
could,
in
the
new
spec,
say
any
signature
generated
after
time.
T
with
any
of
these
algorithms
should
be
considered
invalid.
A
Rick's
also
does
add
a
question
Steven
you're,
not
talking
about
you
weren't,
suggesting
defining
a
redefining
the
deprecated
behavior.
You
were
just
saying
make
the
default
set
of
things.
Deprecated
be
everything
until
somebody
shows
there's
a
need
to
generate
these
new.
These
things
are
currently
over
the
in
the
deprecated
set
yeah.
D
So
we've
talked
quite
a
bit
or
some
at
some
length
here
anyway
about.
We
need
to
warn
the
users
when
they
use
something
that
is
potentially
risky
and,
and
some
points
have
been
made
as
well.
Users
are
a
confused
about
crypto
I.
Also,
don't
think
that
necessarily
there
is
something
any
protocol
spec
that
says
this
is
how
you
go
about
warning.
A
user
on.
One
of
the
things
we've
talked
about
is
having
appendix
to
4880
bits,
that's
sort
of
a
helpful
guidance
to
implementers.
D
You
know
it's
not
part
of
the
spec
per
se,
but
you
know
it
might
be
that
when
we
start
thing
about
do
we
think
that
the
user
should
be
warned
to
me.
That's
almost
sort
of
a
note
to
the
implementers
thing
rather
than
something
in
the
protocol
and
how
people
feel
about
having
taking
that
approach.
If,
if
we
as
a
working
group
feel-
but
you
know
there
are
things
that
maybe
aren't
protocol
spec
but
should
be
considered
by
someone
who's
implementing
that
the
protocol
Steven.
E
A
G
Their
argument-
I,
was
just
about
to
change
anything
that
there
is.
We
have,
a
lots
of
you
know
are
obscene,
say
that
must
do.
This
must
must
oddities
events
must,
you
know,
complain
about
this
and
we
have
also
implemented.
You
know
guidance
to
say
that
okay
much,
this
thing
must
be
configurable.
That's
for
Excel
ipsec.
We
have
reports
of
cases.
Okay,
you
must
be
able
to
do
that
by
configuration
which
most
of
the
people
implement.
This
actually
don't
do,
but.
A
Robin
Wilson
there's
there's
a
slight
element
of
social
engineering
here
and
I.
Don't
say
that
in
a
bad
way,
but
I
don't
I,
don't
see
any
reason
why
we
shouldn't
use
the
specification
process
to
set
out
what
we
would
like
the
behaviors
to
be
oh
and
yeah,
and
then
some
of
these
decisions
can
actually,
for
example,
Dan's
point
about.
Is
anyone
using
this
or
other
people
who
are
using
this
or
dependent
on
it
in
the
room
with
us?
C
D
D
If
we
should
go
through
and
strike
the
hammer
on
things
that
we
think
are
bad,
is
that
the
approach
we
should
take?
Okay,
we
have
no
algorithms
in
4480
4880
books
until
we
start
adding
them
in.
A
C
I,
correct,
sorry,
I
think,
I.
I
think
that
the
room
people
have
already
raised
issues
in
the
room
that
they
still
need
access
to
their
old
male
archives.
So
I
don't
think
we're.
Realistically,
I
don't
think
anyone
here
is
realistically
proposing
that
new
tools
should
not
be
able
to
say
decrypt
an
old
message.
That's
okay,.
C
About
talking
about,
there's
going
to
be
a
cut
right,
there's
going
to
kind
of
things
that
you
that
you
must
not
generate
and
must
warn
if
you
process
or
and
maybe
there's
two
maybe
there's
two
cuts-
that's
must
not.
There's
must
not
generate
and
must
not
process,
and
then
there's
no.
You
must
not
generate,
and
mayo
must
warn
a
few
process
and
then
there's
you
can
use,
but
but
I
don't
think
anyone
saying
that,
like
oh
you've
got
something.
A
Question
is
just
do
we
want
to
keep
open
PGP
as
a
encryption,
decryption
library
that
you
can
use
even
for
for
week
ciphers,
but
it
will
just
say:
warning:
md5
deprecated,
don't
use
or
do
we
will
we
be
using
other
libraries
for
doing
some
research
and
old
stuff.
That
was
also
a
bit
of
question.
So
if
you
really
kick
out,
definitely
md5,
so
we
say
we
don't
create
any
md5
anymore.
We
just
check
whether
it's
an
md5,
because
we
want
to
be
able
to
to
verify
our
old
messages
so.
C
There
are
already
open
PGP
implementations
that
reject
signatures
that
claim
to
be
made
with
md5,
regardless
of
whether
they
validate
okay.
So
I
don't.
I
don't
think
that
those
signature
me
and
that's
put
because
the
spec
says
that
md5
is
deprecated.
Okay,
so
you
know
they'll
they'll
reject
the
return,
does
not
validate
with
a
error
message
that
says
this
did
actually
validate,
but
in
fact
it
only
validated
using
week
a
week
digest
right.
So
the
answer
is
this
is
not
a
signature.
You
should
rely
on
okay.
Thank
you.
The.
D
C
Sorry
so
I
want
to
move
on
to
the
fingerprint
question.
I
haven't
sort
of
a
series
of
questions
that
are
up
here.
We've
added
a
lot
of
stuff
back
and
forth
on
the
list
without
coming
to
any
conclusion,
which
is
a
little
dismaying,
so
I'm
going
to
read
through
the
list
of
questions
that
I
have
up
here
and
see
if
people
have
a
specific
choice.
F
D
C
A
C
C
C
So
I
don't
know
that
we
need
to
settle
whether
we
have
different
formats
for
different
key
types.
At
the
moment
it
seems
simplest
right
now
to
think
about
11
format,
with
one
cryptographic
digest
for
all
key
types
and
if
the
new
key
type
is
defined
that
needs
to
be
fingerprinted
differently.
We
can
do
that,
but
I
haven't
heard
any
proposals
for
something
they
would
split
it
out.
That
way,.
F
For
it
again,
I
guess
the
you
know
I'm
not
going
to
argue
that
we
should,
you
know
specifically
come
up
with
multiple
formats.
I
think
I
would
also
be
happy
with
basically
just
one
reasonable
one,
but
I
guess
where
it
where
it
occurred
to
me
that
it
might
be
worth
considering
as
if,
if
we
want
to
use
a
you
know
bigger,
you
know,
stronger
hash
function
for
keys
in
you
know
much
higher
security
parameter
format,
or
you
know
something
like
that.
F
C
B
What
suppose
that,
for
example,
you
require
that
you
compute
the
hash
on
assault?
I
mean
the
hash
of
the
key
on
the
salt
and
you
choose
the
soul
so
that
the
resulting
hash
as
some
particle
Carter
is
the
exact
meets
the
first
seven
letters
of
your
name
or
start
with
some
known
pattern
or
whatever,
and
then
you
when
they
are
the
possibilities.
You
include
that
and
the
advantage
there
is
that
you
can
keep
the
harsh.
You
can
keep
a
finger
pitch
small
while
increasing
we're
decreasing
the
chance
that
it
be
forged.
I.
B
F
Brian
Ford
I
I,
like
that
idea,
intuitively
I,
think
I
feel
like
it's
worth.
Exploring
and
I
would
totally
entertain
it
as
long
as
it
preserves
the
invariant
that
for
a
given
key,
there
will
only
be
one
fingerprint
and
I
think
what
you're
proposing
probably
can
and
preserve
that
invariant.
But
I
guess
I'd
like
to
see
kind
of
a
specific
design
for
that
and-
and
it
might
be
interesting,
but
I
guess
there's
a
bunch
of
questions.
C
F
A
B
The
idea
is
in
us
in
as
much
as
you
can
qualify
your
key
with
an
arbitrary
part
that
you
can
walk
out
to
all
certain
properties.
Then
you
can
make
sure
that
the
harsh
say
starts
with
32
zeroes
yeah
and
wish
you
don't
put
in
the
signature,
because
you
don't
need
them,
but
then
it's
equivalent
to
adding
your
your
signature.
Your
finger
prick
be
32
bits
longer
and
increases
the
steer
resistance
to
various
attacks.
Ok,
ok,.
C
So
I
think
we
need
to
move
forward.
We've
got
not
a
whole
lot
of
time
left
and
there's
several
other
points
that
we
want
to
get
to
so
I'm,
going
to
ask
people
to
come
back
to
the
mailing
list
with.
If
you
have
any
clear
thoughts
about
these
questions,
I
want
to
highlight,
specifically:
maybe
we
don't
choose
the
digest
here
or
in
the
next.
C
You
know
week
on
the
mailing
list,
but
specifically,
the
things
that
have
come
up
on
the
mailing
list
are
what
is
going
to
be
digested,
should
it
include
just
the
key
material
or
should
it
include
Christian
just
mentioned,
including
possibly
part
of
that
a
user
identity?
We've
taught
currently
includes
a
creation
time,
which
has
some
potential
advantages
in
some
potential
drawbacks.
C
C
C
That
is,
that
the
certifications
that
people
make
over
your
key
would
not
be
valid
if
you
move,
if
you
take
the
same
key
material
and
moved
it
from
a
v4
key
to
a
v5
key.
An
advantage
to
that
is
that
it's
quite
clear
what
the
capabilities
of
a
key
is
that
the
key
has
come
out
in
v5.
A
disadvantage
is
that
people
might
want
to
keep
the
same
rocky
material
around,
because
they
like
the
certifications
that
they've
accumulated
on
their
key
or
something
like
that.
C
So
I'm
going
to
move
on
from
fingerprints
here
we
have
no
other
feedback
from
the
room.
If
you've
got
specifics,
I
would
love
to
have
someone
volunteer
to
write
a
proposal
for
what
we
should
do
for
fingerprints?
Even
if
it's
a
straw,
man
that
you
don't
feel
like
you
can
get
fully
behind
to
have
a
concrete
thing
that
people
can
argue
against
or
for
would
be
really
useful.
Is
there
anybody
who's
willing
to
volunteer
to
write
a
proposal
for
you
just
step
back
from
the
mic
Steven?
It's.
C
F
Brian
Ford,
why
not
just
upgrade
to
shot
a
shot
of
512,
so
I
I
would
I
would
take
that
as
kind
of
the
natural
that
you
know
just
go
with
the
stronger
since
it's
only
ever
going
to
be
used
for
for
showing
a
you
know
very
small
amount
of
data
and
there's
at
least
a
slight
security
argument.
That's
better!
If
and
when
we
adopt,
you
know
kind
of
high
security
keys
like
you
know
ad
for
48,
or
something
like
that,
and
it's
not
going
to
make
a
difference
one
way
or
another
for
other
keys
from.
F
C
So
yeah
I
really
would
love
it.
If
someone
would
volunteer
to
write
server.
Nurse
has
to
slow
and
embedded
platforms,
I'm,
not
clear
to
me
what
that's
what
is
too
slow,
512,
ok,
so
I
think
it
would
be
great
if
someone
would
propose
a
concrete
thing,
but
I'm
not
getting
any
volunteers.
Yet
I
might
stalk
you
later
in
the
meeting
and
asked
you
to
do
it
all
right.
F
B
F
So,
oh
so
I
put
out
the
draft,
but
you
know
he
is
before
he
and
then
draft
another
day
like
having
people
afraid,
but
basically
just
discussing
some
of
the
issues.
All
right
your
mind.
G
F
F
Sorry
for
those
of
you
who
read
my
draft
that
you
said
identity
protection
when
it
should
have
said
integrity,
protection,
that's
delirious,
typing
at
the
last
minute
effects,
but
so-
and
it's
kind
of
it
seemed
obvious
to
me
anyway-
that
the
best
way
to
do
that
is
basically
to
to
migrate
the
standard
toward
using
authenticated
encryption
schemes
providing
kind
of
a
framework
for
hopefully
supporting
multiple
authenticated
encryption,
algorithms,
yet
so
go
ahead,
yeah!
So
so,
actually
this
was
a
set
of
possible
things
to
discuss.
F
I
also
added
the
the
topic
that
EKG
brought
up,
but
you
know
that
could
be
dealt
with
whenever
so
right
now,
I'm
just
talking
about
the
first
bullet
up
there
so
go
ahead
and
go
to
the
next
slide.
So
there's
things
that
I
assume
it's
obvious
we
want
to
do
is
to
at
least
deprecated.
You
know
shall
one
based
integrity,
protection
and
deprecated
the
you
know
the
way
the
modoch
the
broken
vulnerable
way
that
the
modification
detection
packet
is
used
and
exists
now
now
there
there
are
basically
two
classes
of
questions
we
need
to.
F
You
know,
discuss
and
we
don't
necessarily
have
to
discuss.
I,
don't
expect
to
be
able
to
decide
that
here
we
don't
even
really
need
to
discuss
them
here,
necessarily,
but
first
of
all
which
schemes
should
we,
you
know,
should
we
plan
to
include
from
the
start
on
some
three
options
that
seemed
likely
choices
to
me
to
at
least
consider
would
be
a
CES
GCM.
F
It's
not
the
latest
shiniest
screen
scheme,
but
it's
you
know
as
far
as
I
know,
it's
not
broken
up
and
it's
popular
and
then
kind
of
for
a
maybe
something
like
chacha
poly
1305
as
a
very
contrasting
contrasting
lee
alternative.
You
know,
scheme
that
seems
to
have
considerable
popularity
and
it's
very
fast
in
software
and
stuff
arm,
and,
of
course
you
know
in
the
future.
F
We
definitely
want
to
be
looking
at
the
caesar
competition,
although
I
agree
that
we
shouldn't
way
for
that
to
be
over
before
we
do
something
and
actually
ignore
the
last
thing.
It
was
it's
on
your
list,
so
that'll
be
dealt
with.
That's
an
important
issue
to
deal
with
separately.
Okay
next
slide
now
orthogonal
to
the
which
scheme
or
which
schemes
question.
F
We
need
to
answer
a
few
kind
of
technical
internal
data
format,
questions
I,
don't
I,
don't
perceive
these
to
be
extremely
difficult,
but
you
know
they
just
need
a
little
attention
and
review
at
the
very
least
in
some
some
a
neat
discussion.
So
one
is,
you
know:
do
we
repurpose
the
existing
packet
tags
tag?
18
is
the
you
know,
symmetric
key
protected
data
and
tag.
F
19
is
the
the
integrity
check
which
are
currently
separate
in
my
draft
I
propose
that
we
basically
deprecated
you
know
for
these
new
encrypted
schemes
we
just
not
use
either
of
those.
Instead,
we
add
a
new,
possibly
tag.
24
an
you
know
authenticated
an
AE
ad
protected
packet
in
which
the
the
Mac,
the
authenticity
check,
would
just
be
a
fixed
length.
Trailer
added.
You
know
within
that
packet.
This
assumes
that
that
the
mac
is
always
a
fixed
length.
That's
you
know,
kind
of
known
based
on
the
cipher
suite.
F
F
Do
we
treat
it
as
an
IV
and
kind
of
always
have
the
the
sender
include
an
explicit
nonce
as
a
kind
of
as
a
header
to
to
each
encrypted
chunk,
or
do
we
implicitly
define
it,
for
example,
by
counting
chunks
from
the
beginning
of
the
file?
So
the
important
property
of
the
nonce
in
a
EAD
schemes
is
usually
that
it's
unique
within
the
context
of
a
given
session
key,
so
we
had
better.
You
know.
F
We've
got
to
be
absolutely
sure
that,
however
we
designed
this,
you
know
we
never
reuse
the
knots
with
the
given
session
key,
but
generally
you
know,
since
PGP
and
cryptos
create
a
new
session
key
I.
This
is
universally
true.
As
far
as
I
know
right.
You
know
if,
if
that's
the
case,
pgp
encrypter
always
create
a
fresh
session
key.
You
know.
F
When
they
create
a
file,
we
can
decide
how
we
want
the
Nazis
to
be
generated
either
explicitly
or
implicitly
within
the
file,
but
we
just
you
know,
need
to
decide
that
and
then
the
then
another
question
I,
don't
know
these
Steve's
allow
for
additional
data
that
is
identity
protected,
but
not
encrypted.
Does
openpgp
have
any
use
for
that,
or
do
we
just
say
that
you
know?
That's
always
a
zero-length.
You
know
input
in
this
case
so
anyway,
just
just
questions
for
consideration.
F
C
C
So
I'd
like
to
actually
ask
for
a
home
on
the
first
bullet
point
that
we
have
here,
which
is
about
whether
we
should
reuse
existing
packet
formats
or
whether
it
and
just
define
a
new
cipher
or
whether
we
should
define
a
new,
a
new
packet
format
for
encrypted
using
authenticated
encryption
so
who,
in
the
room,
so
the
two
questions
are
going
to
be.
Do
you
think
we
should
reuse
existing
packet
formats
or
do
you
think
we
should
make
a
new
one?
So
do
you
think
we
should
really
use
existing
packet
formats
Thanks.
E
C
E
F
F
You
know
a
high
20
packet,
you
ever
see
is
going
to
be
authenticated
encryption
and
you
know
so
basically
clean
break
and
add,
coupled
with
to
me
anyway,
the
absence
of
an
obvious
downside
to
that
in
terms
of
compatibility,
because
you
know
any
new
screen
theme
that
we
throw
in
a
tag,
20
packet
is
going
to
be
complete,
a
completely
different
increase
encryption
scheme
than
anything
literacy
and
at
a
gay
teen
packet
anyway.
So
it
doesn't
seem
like
it
makes
compatibility
problems
any
worse,
so
that
that's
those
are
my
thoughts
but
good
total.
G
Communion
I
don't
know
anything
about
a
beach
openpgp
pocket
format,
but
I
remember
in
this
has
to
be
a
problem
in
couple
of
other
places.
Lykke
necessary.
Very
you
know
some
of
these
things.
Some
of
the
crypto
libraries
wants
to
do
this
combined
mode
ciphers
in
a
way
that
they
get
the
whole
thing
in
as
a
one
blob,
and
you
can't
give
you
know
this
is
the
encrypted
pattern.
This
is
the
tag,
that's
a
separate
thing,
so
that
might
actually
I
would
say
that
they
probably
having
a
separate.
C
C
That
means
my
decryption
mechanism
gives
me
0
bytes
until
it
gives
me
all
four
gigabytes,
and
so,
if
we,
if
we
put
the
put
signatures
aside
for
the
moment-
and
you
just
think
about,
I
would
like
to
be
able
to
get
some
of
those
bites
out
at
first.
You
could
do
authenticated
encryption
in
pieces
within
within
the
file
format,
and
that's
there's
a
so
I've,
actually
gotten
a
bunch
of
feedback,
because
I
asked
him
to
see
frg
about
this
and
there
are
papers.
People
have
written,
raga,
Waypoint
images
and
papers
that
he
wrote
there.
C
Several
other
folks
who
are
they're
calling
this
oae,
which
is
online,
authenticated
encryption
and
there
are
explicit
constructs
and
there
there's
cryptographic
analysis
about
it.
I
haven't
read
them
all
yet,
but
I
think.
If
we're
going
to
be
doing
AE
wee
I
think
we
would
want
to
be
able
to
do
oae
because
of
the
traditional
history
of
streamed,
decryption
yeah.
F
F
F
G
The
young
discussion-
that's
actually
one
of
the
reasons
you
might
want
to
put
the
additional
data
there.
You
know
the
protector,
you
know
the
ice,
a
fragmentation
ordering
stuff
by
saying,
okay,
this
is
taken
okay
index
of
the
thing
that
is
always
added
additional
data
it
there,
and
this
piece
is
called
the
bait.
This
piece
of
that
yeah.
E
E
F
E
C
C
E
C
Specific
questions
to
ask
here:
I
think
that
that
first
question
it's
good
to
have
that
resolve,
because
I
think
that
means
that
implementers
can
experiment
now
can
we
do
we
get
a
new
allocation
point
or
we
just
tell
people
that
we're
going
to
reserve
20
registry
rule
I,
don't
remember,
I,
don't
know
drop
just
morning
when
I
suggested.
E
C
E
So
you
went
when
you're
when
the
chairs
are
happy
that
this
seems
like
what
this
is
working
group
consensus
and
you
have
what
you
think
is
this.
You
know
it
stable
enough
specification.
Then
we
can
do
the
early
allocation
scheme
that
oversee
17
22
hours,
and
then
that
expires
after
a
year
or
something
okay,
but
you're
not
sure
to
tag
numbers
here
anyway.
So
you
could
bread
so
we'll.
D
Take
that
to
the
list
next
week.
Actually,
let's
take
a
I
guess
suppose
we
should
do
a
home.
Should
we
do
this,
we've
got
to
pluses
before
they
act
kicked
off
out
of
the
room.
So
if
we
think
that
this
one,
you
know
that
this
approach
is
the
consensus
is
what
we
should
be
shooting
for
vs,
no,
we'll
take
it
to
the
list.
But
if
we
don't
hear
any
squawking
we'll
we'll
make
that
request
next
week
is
a
consensus.
Working
group.
A
C
E
C
C
C
C
Sorry
verner
also
mentioned
we
talked
about
ocb
in
Prague,
so
I
got
and
I
actually
mailed.
Some
folks
about
that
and
I
got
a
commitment
from
raga
way
that
he
would
be
fine
using
it
within
pgp
Morocco
is
issued
a
clearance.
The
the
usual
complain
about
OC
b
is
IPR.
Complaint
rockaway
has
issued
a
waiver
for
OC
b
when
it's
used
in
TLS
implementations,
there's
already
a
free
software
waiver
for
OC
b,
he's
willing
to
issue
the
same
waiver
for
pgp
to
the
room.
Just
for
the
room
knows
about
that.
So.
E
C
E
C
F
Yeah
I,
so
this
was
not
in
I,
was
not
intended
intending
to
even
suggest
this.
As
an
exhaustive
list
I
want
to
see.
Other
people
propose,
you
know,
hey
I,
think
scheme
scheme
Jackson.
Why,
which
aren't
listed
here
would
be
better.
You
know
to
either
replace
these
or
to
augment
them
right.
So
please
send
suggestions
for
specific
schemes
that
you
think
would
would
be
really
good
to
have.
C
F
C
F
Yeah,
so
back
to
kind
of
the
highlighter,
so
the
high-level
map
are,
you
know
one
of
the
high-level
questions
we
need
to
ask
us.
What
is
the
feature
set?
We
want
what
what
is?
What
are
the?
What
should
the
goals
of
the
next?
You
know,
data
format
be
armed,
and
so
you
know
this
is
within
the
context
of
that
higher
higher
level
question.
What
potentially
more
ambitious
changes
might
we
want
to
make,
and
so
what
I'm
proposing
is?
F
Well,
you
know
kind
of
PGP
and
many
encrypted
formats
have
generally
just
been
designed
along
the
assumption
that
it's
kind
of
ok
to
have
some
unencrypted
metadata
that
say,
helps
the
decoder
figure
out
how
it's
encrypted,
what
what
type
file
format
it
is
what
version
it
is.
You
know
stuff
like
that.
This
is
convenient
for
the
legitimate
decrypter,
of
course,
that's
undeniable,
but
it
also
kind
of
leaks,
a
lot
that
can
be
useful
to
attackers
and
we've
seen
more
and
more
kind
of
attacks,
actually
using
some
of
this
meta
do
so.
F
This
is
just
an
illustration
of
kind
of
all
the
things
that
that
the
encryption
of
the
quick
brown
fox
jumps
over
the
lazy
dog
you
know
tells
an
attacker
without
who
can't
otherwise
decrypt
the
content
so
go
ahead,
and
next
next
slide.
So
so
you
know
just
some
examples
are
the
magic
itself.
The
first
two
bytes
say
announced
this
is
an
open
to
PDP
file.
Ought
to
you
know
anyone
who's.
You
know
any
authorities
who
are
snooping
over
my
hard
drive.
This
looks
suspicious.
Maybe
this
guy's
hiding
something
right.
F
This
never
happens
to
real
people,
I
know,
but
so
or
you
know,
of
course
it
announces.
What
cipher
is
you
it's
using?
Well,
unfortunately,
I
believe
openpgp
had
never
has
never
used.
Rc4.
Is
that
hopefully
true,
that's
correct,
okay,
but
if
it
had,
then
you
know
having
a
flag
saying
this:
is
our
c4
is
kind
of
a
crack
me
flag?
Look,
you
know,
invest
your
resources
in
trying
to
crack
this
open
PG
file.
F
Instead
of
that
one-
and
you
know
exactly
what
algorithm
to
apply
to
it-
we're
right
arm
passphrase,
you
know
it
announces.
You
know
whether
it's
passphrase
encrypted
or
not-
and
you
know-
maybe
if
it
is
maybe
it's
worth
bringing
out
the
password
cracker
it
depends.
So
you
know
it
tells
I
think
in
the
default
mode
it
yet
it
these
kind
of
identifies
who
the
recipient,
who
can
decrypt
the
file
and
at
least
how
can
decrypt
it
an
interesting.
F
A
message
was
posted
to
the
mailing
list
so
that
that
can
be
those
can
be
blinded,
but
blinding
them
create
usability
issues.
So
that's
that's
an
important
relevant
comment
on
current
implementations,
but
the
general
point
is
you
know:
kind
of
the
metadata
reveals
a
lot
of
information.
Should
we
try
to
protect
it
better?
So
next
next
slide
so
I
would
like
to
suggest
maybe
the
South
slightly
radical
Gulf.
F
Can
we
can
we
design
the
next
file
format
so
that
encrypts
every
every
single
bite
so
that
so
that
nothing
is
left
unencrypted
and
to
anyone
who
doesn't
have
a
relevant
key,
a
relevant
passphrase
or
our
key
pair
will
only
see
a
uniform
random
blob.
You
know
a
uniformly
random
sequence
of
gifts.
Of
course,
you
know
the
name
of
the
file
or
other
get
out
surrounding
metadata
could
still
give
it
away,
but
that's
I
would
you
know
say
that
that's
a
second
order
problem,
but
we
don't
need
to
attack.
F
F
It
sounds
like
the
current
implementation,
when
it's
trying
different
keys,
creates
a
lot
of
scary
messages,
and
you
know
we
want
to
make
sure
that
those
kind
of
usability
issues
wouldn't
happen,
but
so
I'm
just
going
to
throw
out
the
completely
unsubstantiated
claim
that
I
think
these
technical
challenges
can
be
resolved
and
I.
You
know
I
think
I
have
a
bunch
of
ideas
how
we
can
resolve
them.
I,
don't
expect
anyone
to
believe
me
just
yet,
but
you
know
until
until
I
or
you
know
other
inter
interested
people
can
substantiate
that
claim.
F
But
I
just
want
to
propose
ask
the
question:
if
this
claim
can
be
substantiated
at
some
point
reasonably
soon,
how
would
this
be
of
interest?
Does
you
know?
Do
you
think
this
should
be
a
goal?
We
should
work
for
out
so
okay,
so
that
that's
the
first
half
of
the
men
data
thing
that
maybe
I
should
open
them.
F
Let
me
let
me
just
go:
go
right
forward
to
kind
of
the
other.
Half
is
the
length,
of
course
you
know,
can
leak
information
as
well.
We
can
protect
that
right.
We
could,
you
know
kind
of
you
having
having
padding
as
a
very
old
suggestion.
You
know
how
much
do
we
gain
I'm,
not
sure
you
know,
there's
never
been
kind
of
a
comprehensive
theory,
and
I
I'm
not
going
to
claim
that
we
can
immediately
create
one,
but
I
think,
there's
I
think
there's
things
we
can
do
that
that
can
improve
the
situation.
F
So
I
have
a
proposal.
That's
partly
written
up,
I'm
happy!
It's
not
in
a
draft
form,
it's
a
draft
of
a
draft
that
I'm
happy
to
share,
but
basically
a
scheme
that
somewhat
intelligently
add
padding
with
to
produce.
You
know
a
fairly
low
low
maximum
waist
twelve
percent
for
for
the
absolute
worst
case
and
decreasing
with
file
size,
so
six,
a
six
percent
worst
worst
case
for
files,
greater
than
256
bytes
and
three
percent
worst
case
for
files,
greater
than
64
k,
I
think
so
gradually
tightening,
but
achieving
a
certain.
F
I
believe
important
kind
of
asymptotic
characteristic
of
asymptotically
reducing
the
maximum
possible
leakage
from
order
log
ill
to
order
log
log.
L,
where
l
is
the
number
of
bits
of
the
file,
so
that's
kind
of
the
theoretical.
You
know.
Why
should
we
consider
this
so
so
that's
kind
of
the
second
half
of
the
you
know
can
and
should
we
product
protect
metadata
proposal.
A
Robin
Wilson,
just
a
quick
thought
about
the
last
one
really
I
mean
all
encryption
is
an
exercise
in
increasing
the
work
factor
for
an
adversary
to
read
your
text.
So
why
would
I
not
like
something
that
increases
the
work
factor
for
an
adversary,
so
in
any
world
where
there
is
more
than
one
possible
encryption
algorithm,
you
increase
the
work
vote
of
the
adversary
by
not
telling
them
which
algorithm
you've
used.
Why
would
I
not
like
that?
Thank
you.
C
F
C
F
F
C
Verner
says
that
trial
decryptions
are
annoying.
If
your
private
keys
are
passphrase
protected,
you
can't
do
trial
depictions
without
forcing
the
user
to
unlock
their
secret
key
material.
So
that's
another
potential,
yes
yeah
and
then
Neal
points
out.
The
trying
keys
is
a
pain
if
the
keys
are
on
a
smart
card,
because
smart
cards
seem
to
be
slow
and
then
Verner
says
and
then
again
we
are
sending
fully
randomized
stuffed
by
mail.
F
Yeah
Thank
You
burner
those
are
all
they're,
very
important
considerations,
I
a
very,
very
good
points.
So
for
one
thing
actually
one
thing
I
should
point
out:
I'm
I'm,
not
necessarily
suggesting
that
we
should
force
users
to
use
the
uniform
Agathe,
the
uniform,
random
format,
all
the
time
you
know
we
we
have
to
you
know.
Maybe
it
should
be
selectable,
maybe
for
you
know
some
uses
like
smart
cards.
It's
just
not
practical,
and
you
know
we
have
to
have,
but.
F
Yeah
yeah
so
we'll
just
thinking
out
loud,
so
these
you
know
we
need
to
think
about
these
more
issues.
Thinking
out
loud,
one
could
conceivably
include
include
metadata
in
a
public.
In
a
key
pair
saying,
this
key
pair
is
owned
by
someone
who
uses
a
who
uses
an
smart
card,
or
that
kind
of
thing.
So
please
don't
send
me
anything
that
requires
trial
decryption,
so
that
could
conceivably
be
embedded
in
a
public
key
and
then
the
encrypter
has
to
decide.
F
G
List
their
community
to
go
back.
One
slide,
I
think
if
that
was
the
one
that
had
a
what
do
you
actually
won
because
they
slide
it
had
that
one
yet
so
I,
don't
think
you
actually
worth
trying
to
protect
that
saying
that
this
is
a
pgp
that
great
triptych
file,
I
mean
that's
quite
clearly,
you
know
visible
when
you
have
a
completely
random
file
is
encrypted
by
some
how
to
cook
yeah.
So
it's.
G
Get
a
big
GP
or
something
else
that
doesn't
you
know
really
opportunity
great
having
the
information
there
in
the
file.
Accent
makes
very
useful
in
some
other
cases
to
have.
You
know
know
that
okay,
this
is
this
is
I,
should
use
PGP,
not
you
know
some
other
program
to
decrypt
it
for
you,
myself
and
I'm.
You
know
how
many
discs
crashes
and
I
had
lost
all
the
file
names.
So
I,
don't
know
it
is
PT.
Pp
GP
fall
it's
something
else.
There
is.
You
know
the
algorithms
and
so
on.
G
That's
something
that
usually
doesn't
care,
because
there
is
usually
very
especially
if
you
think
about
the
earlier,
had
one
algorithms
inspector
or
very
few
there's
going
to
be
no
very
small
amount
of
those
in
use,
so
you
know
protecting.
That
is
also
a
little
bit.
You
know
not
that
useful
protect.
The
number
of
you
know.
G
G
F
C
C
A
C
It
is
timing,
independent
it
works
again.
It
avoids
timing
based
side
channels,
whereas
2d
allows
you
allows
you
potentially
some
faster
approaches.
I
believe
so
argon
to.
I
would
be
the
thing
that
does
key
derivation
and
nils
has
provided
a
patch
to
the
40
80
bits
that
verner
has
been
working
on
it's
on
the
mailing
list.
The
only
issue
is
argon
is
not
currently
specified
by
the
ittf
I
actually
asked
on
list
and
peter
goodwynn
said
he
was
meaning
to
even
mean
to
write
up
are
gone
for.
E
C
Wasn't
that
wasn't
there
this
morning?
Ok
great!
So
this,
like
the
crew
of
folks
who
looked
at
password
hashing
in
this
competition,
are
pretty
hardcore.
Cryptographers,
who
know
what
they're
doing
and
I
think
it
would
be
a
shame
for
us
to
not
use
this
so
I'm,
leaning
towards
doing
the
same
approach
that
we've
been
that
we
just
talked
about
for
the
new
packet
idea
about
early
allocation
for
s2k.
E
C
E
C
So
our
time
is
up
here.
I
believe
I
had
mentioned
that
we
wanted
to
cover
registry
policies
like
what
are
the
policies
for
updating
these
registries.
I.
Don't
think
we
have
time
to
get
into
this
discussion
now,
but
we
had
talked
last
time
in
Prague
about
making
notations
easier
for
people
to
register
within
the
IETF
space.
There's
an
open
question
about
whether
we
tightly
we
want
to
control
these
other
ones.
C
Given
that
the
group
suggested
that
we
want
to
have
no
nothing
valid,
except
for
the
few
things
that
we
choose
I'm
going
to
interpret
that
as
meaning
that
we
don't
want
to
open
these
up
for
easy
registration.
So
I
will
think
about
that
and
I'll
try
to
write
something
up
to
the
list
about
what
to
do
there.
So.
D
On
that
topic,
I
also
had
a
discussion
with
ayanna
this
morning
about
changing
the
existing
registry.
If
we
wanted
to
to
have
specific
ranges
of
the
registry
having
different
having
different
allocation
procedures-
and
they
said
we
could
do
that
off
of
the
existing
registries,
we
wouldn't
have
to
go
back
and
redo
the
registry,
so
that
option
is
open
to
us.
If
we
want
to.