►
From YouTube: Embedded cryptography: RustCrypto + Veriform
Description
Historically cryptography in the embedded space has been a disaster, but with the growing pervasiveness of “IoT”, a topic of increasing importance. Rust provides a great language for building secure embedded applications, and with it a great platform for embedded cryptography.
This talk covers two cryptography projects written in pure Rust:
1. RustCrypto (“2.0”): a multi-crate “embedded-first” GitHub organization with trait-based implementations of several cryptographic algorithms including AEAD algorithms (AES-GCM, ChaCha20Poly1305), digest algorithms (SHA-2, SHA-3, BLAKE2), elliptic curves (NIST P-256, secp256k1), MACs (CMAC, HMAC), and signature algorithms (ECDSA, Ed25519)
2. Veriform: cryptographically verifiable and canonicalized message format similar to Protocol Buffers, with an “embedded-first” (heapless) implementation suitable for certificates or other signed objects
Recorded at Oxidize Global 2020
A
B
B
So
I've
been
using
a
rust
for
about
six
years
and
in
2014
I
gave
this
talk
at
kind
of
the
rust
bay
area
meet
up
at
mozilla.
I
talked
about
how
I
thought
rust
was
a
very
promising
language
for
cryptography
at
the
time
and
particularly
talked
about
this
idea
of.
Can
we
just
do
brand
new
green
field?
Cryptography
in
rust?
B
B
There
is
a
c
library
from
bitcoin
core
called
libsec
p256k1,
that
is
probably
the
best
library
for
this
elliptic
curve.
So
so
that's
great.
We
have
all
these
nice
wrappers
for
high
quality
existing
libraries.
You
know
there's
also
many
more
that
are
necessarily
you
know:
they're
wrappers,
for
what
are
necessarily
high
quality
libraries
like
open,
ssl
or
other
native
tls
stocks,
but
the
other
thing,
the
other
side.
B
The
other
prong
to
this
approach
is
what
we're
seeing
is
the
proliferation
of
libraries
that
are
written
in
pure
rusts,
more
or
less
from
the
ground.
Up
you
know:
maybe
they
started
as
like
a
translation
of
a
c
library
or
something
but
have
definitely
earlier
matured.
So
I
will
be
talking
primarily
about
rus
crypto,
which
is
kind
of
a
suite
of
different
cryptographic
crates,
a
couple
other
notable
ones.
I
thought
I
just
mentioned
the
dalek
libraries.
B
These
are
elliptic
curve
fly
libraries
for
curve,
255.19,
there's
also
a
cool
one
called
fiat
rust,
which
is
generated.
It
was
originally
a
project
to
generate
c
libraries,
c
field,
arithmetic
libraries
that
are
formally
verified
using
coke,
and
now
they
have
a
back
end
that
targets
rust
as
well.
So
we've
seen
a
really
cool
proliferation
of
these
pure
rust,
cryptography
libraries,
and
that
is
going
to
be
the
focus
of
my
talk
tonight
tonight
for
me
morning
for
several
of
you.
B
B
It's
also
got
its
keywords:
md5
and
shot
one
which
are
both
cryptographically
broken.
Algorithms,
so
this
this
crate
is
not
what
I'm
talking
about.
You
know
this
was
cool
earlier,
a
cryptography
effort,
the
project
stalled
and
it
hasn't
been
worked
on
and
at
this
point
it's
effectively
a
time
capsule
from
about
2016..
B
B
B
B
We
have
roughly
a
dozen
other
active
contributors
like
people
are
contributing
to
the
project
on
ongoing
basis
and
we
have
approximately
a
hundred
crates.
So
it's
a
very
multi-crate
sort
of
project.
So
you
might
be
using
one
of
our
crates
already
shot.
Two
is
very
popular,
says
digest,
but
we
have
the
names
of
kind
of
you
know.
We
have
the
short
names
of
many
cryptographic
algorithms,
so
hopefully
our
crates
are
pretty
easy
to
find.
B
So
the
project
got
started
off
in
2016
is
kind
of
rethinking
rus
crypto
from
a
single
monolithic
crate,
including
one
that
had
kind
of
you
know
a
lot
of
algorithms
that
were
either
broken
like
md5
or
just
about
to
be
broken
like
shot
one
right.
So
the
idea
was
kind
of
how
do
you
unpack
res
crypto
into
something
where
you
can
just
grab
only
the
crates
for
the
algorithms?
B
Don't
you
see,
everything
is
pressed.
We
also
know
stood
as
a
baseline,
so
this
was
kind
of
a
big
hold
up
for
the
original
rust
dash
crypto
crate.
It
was
not
new
student
friendly,
so
we
are
every
single
one
of
our
crates,
except
for
one
I'll
talk
about
a
bit
later,
works,
understood
and
all
of
them,
except
for
two
work
in
a
heapless
environment
and
do
not
need
outlook
so
they're,
basically
of
these
hundred
crates
are
only
to
you
that
will
not
work
in
a
heapless
nested
environment.
B
So
you
also
write
portable
implementations
they're
effectively
designed
to
run
anywhere,
so
we
don't
at
a
baseline,
make
any
sort
of
architectural
assumptions,
except
for
a
few
about
security.
I
will
highlight
later
we
don't
block
you
from
compiling
on
those
platforms,
but
there
are
some
things
you
need
to
be
aware
of.
We
do
allow
optional
assembly,
so
there
are
a
few
crates
that
have
an
asm
feature
that
you
can
turn
on.
B
B
And
finally,
we
have
a
trait
based
architecture
where
every
single
algorithm
and
algorithm
family
has
a
trait
that
describes
it,
and
we
made
kind
of
architected
things
in
such
a
way
that
anybody
can
implement
these.
So
you
don't
have
to
be
like
locked
into
our
ecosystem
to
implement
our
traits
and
kind
of
interrupt
and
combine
with
the
rest
of
our
algorithms.
B
B
This
is
high
level
encryption
that
is
designed
to
detect
things
like
forgeries.
It
significantly
mitigates
things
that
attacker
can
do
to
you,
so
if
you're
trying
to
do
symmetrical
cryptography,
this
is
basically
what
you
want
to
use.
So
this
algorithm
family
authenticated
encryption
with
associated
data.
The
traits
are
described
in
the
aead
crate,
and
then
we
have
several
algorithm
crates.
Hopefully,
you've
heard
of
some
of
these,
but
aes
gcm
is
a
popular
cipher.
B
B
B
B
B
B
B
If
you
use
this,
it
will
use
a
software
implementation
that
is
constant
time
using
a
technique
called
bit
slicing
on
embedded
platforms.
It
also
has
a
special
back
end
for
intel
platforms
for
esi,
also
as
far
as
legacy
block
cypress
go.
We
also
have
desks.
This
also
implements
triple
desks
and
more
so.
There
are
plenty
of
other
block
ciphers.
We
don't
really.
B
So
moving
on
to
your
hashes
or
digest
algorithms
chances.
Are
you
probably
have
the
digest
crates
in
your
project
somewhere
already
name,
some
of
the
crates
that
use
it
blake2?
This
is
a
cool,
fast,
new
hash
function
on
software,
there's
also
your
ibm
d160,
this
kind
of
legacy
one,
but
it's
somewhat
popular
in
the
cryptocurrency
world
and
a
good
old
shot
too
providing
shot,
256,
384
and
512.
B
and
more.
There
are
tons
of
cryptographic,
algorithms
message:
authentication
codes.
We
have
the
crypto
mac
crate
that
defines
the
traits
for
them.
As
far
as
algorithms
go
c-max,
cipher-based
mac,
you
might
see
this
in
the
embedded
space.
One
of
my
first
interactions
with
russ
crypto
as
a
project,
was
implementing
a
secure,
embedded,
secure
channel
protocol
called
the
global
platform
secure
channel
protocol
u3,
which
builds
on
this.
B
Probably
a
bit
familiar
more
familiar
to
everyone's
hvac
pmac
is
a
cool
parallelizable,
cypher-based
mac
as
well,
and
more
they're,
still
more
max
so
stream,
savers
again
he's
kind
of
fallen
to
that
hazmat
category.
Where,
if
they're
misused,
you
can
fail
catastrophically.
So
again,
I
have
a
warning
sign.
B
B
B
So
you
have
elliptic
curve
cryptography
crates.
They
have
traits
to
find
in
the
elliptic
curve
crate.
We
have
three
curves
implemented
right
now
we
have
a
k256
providing
the
secp
256k1
curve.
This
is
popular
in
cryptocurrency,
the
other
three.
There
are
nist
curves,
so
these
are
the
nsp
curves
that
are
used
in
things
like
tls
bluetooth.
B
B
B
And
finally,
here
we
have
digital
signatures,
so
the
traits
for
these
are
defined
in
the
signature
crates
and
we
have
algorithm
crates
for
both
ecdsa
the
olympic
curve.
Digital
signature
algorithm,
as
well
as
ed
255.19
ccdsa,
are
in
the
process
of
implementing
the
algorithm
I'll
talk
more
about
that
later
and
255.19
just
defines
a
set
of
interoperable
signature
formats,
we're
not
trying
to
compete
with
the
dalek
libraries
or
anything,
but
notably
the
ed
255.
B
B
So
first,
as
I
mentioned
earlier,
all
our
crates
are
sea,
I'd
and
routinely
tested
in
nosted
environments,
including
heapless
environments,
that
in
and
of
itself,
probably
isn't
that
interesting
right,
like
that's
kind
of
like
table
stakes.
So
when
we
talk
about
embedded,
what
are
we
talking
about
so
kind
of
our
tier
one?
Embedded
targets
are
really
going
to
be
arm.
B
Cortex,
a
and
rm
cortex
m
I
feel
like
this-
is
kind
of
par
for
the
course
for
rust,
embedded
in
general
right
when
people
say
rust
and
betta
they're,
usually
talking
arm.
You
want
to
support
other
environments,
you
know
the
effectively.
Everything
else
to
us
is
like
tier
three,
but
it's
a
little
bit
tricky.
So
you
know
our
code
will
compile
on
these
targets.
B
B
You
know,
like
constant
time,
is
effectively
like
a
hardware,
a
property
of
a
combined
hardware
and
software
system
right.
So
there
are
plenty
of
cpus
and
microcontrollers
out
there,
for
example,
that
don't
have
constant
time
multiplication
like
some
cpu
designer
thought.
They
were
really
clever
and
if
you
tried
to
multiply
it
by
zero
or
one,
they
short
circuit,
the
aou
or
something
right,
so
they
thought
they
were
clever,
but
that
kind
of
destroys
cryptography
on
that
entire
platform.
B
B
So
the
latest
versions
of
all
these
traits,
which
were
released
a
few
months
ago,
completely
splits
initialization
from
the
core
algorithm
itself,
but
you
might
see
in
this
trade
right.
We
have
this
par
blocks,
we're
trying
to
encode
ways
to
do
things
like
cindy
and
that
kind
of
thing-
and
you
know
like
that-
that
really
helps
intel
on
things
like
esi
and
that
kind
of
thing
it's
not
necessarily
very
embedded
friendly.
B
B
Normally
a
block
cipher
is
just
doing
a
permutation,
it
doesn't
have
any
state,
so
we
didn't
have
a
meat
reference
before
on
that
previous
block
cipher
trace
this
one
has
a
meat
reference
which
we
think
is
very
nice
for
getting
to
a
hardware
peripheral,
and
this
is
effectively
our.
I
think,
our
trait-
that
we
will
focus
on
using
draft
things
like
cryptographic
accelerators.
B
I
think
it
might
be
pretty
interesting
to
play
with
things
like
parallel
pipelining,
that
kind
of
thing
with
this
retreat,
but
we
would
love
feedback
on
this
sort
of
thing
and
whether
or
not
our
traits
are
mapping
well
or
aren't
mapping.
Well
the
cryptographic
accelerators
if
they
aren't
mapping
well,
we
would
like
to
figure
out
how
to
solve
that
so
giving
an
example
of
how
a
trait
like
this
is
kind
of
useful
here's,
an
example
of
how
you
can
combine
this
block,
cipher
trait
with
the
asgcm
crate.
B
So
one
interesting
thing
we've
done
is
make
the
aes
crate
a
optional
dependency
of
this
aesgcm
authenticated
encryption
crate.
So
if
you
want
to
use
a
hardware
accelerator
instead
of
the
software
implementation,
you
can
completely
shut
that
aes
dependency
off,
so
you're
not
even
pulling
in
any
of
that
code.
B
And
then,
if
you
implement
this
block,
cipher
trait
for
your
cryptographic
accelerator
using
generics,
you
can
instantiate
aes
gcm
using
the
hardware
accelerator
instead
of
the
software
implementation.
So
I
think
that's
pretty
cool.
So
speaking
of
aes
gcm,
we
have
probably
one
of
the
best
embedded
optimized
implementations
of
this
algorithm
available.
B
Today,
specifically
targeting
32-bit
cortex-m
devices
and
specifically
even
I
think,
having
devices
like
cortex
m0
in
mind,
so
I
say
this-
you
might
be
thinking
or
I've
heard
that
asgcm
performs
poorly
on
embedded
platforms
and
in
general
you'd
be
right.
The
funny
thing
is,
you
know
what,
if
people
have
just
been
implementing
it
badly
all
along,
so
this
is
kind
of
funny.
So
the
main
way
people
implement
asgcm
using
these
sort
of
like
bit
slicing
techniques.
B
B
It
uses
this
very
clever
technique,
so
the
core
of
this
g
hash
function
is
effectively
a
carrier-less
multiplication,
operation
or
a
finite
field.
So
this
is
normally
done
using
very
complicated
techniques
to
kind
of
get
rid
of
that
carry
spelling
rate
to
kind
of
get
rid
of
those
carries.
So
what
bear
ssl
does
is
it
takes
integers
and
kind
of
splits
them
up
into
chunks,
and
then,
whenever
these
carriers
occur,
they
fall
into
one
of
these.
B
B
So
just
to
give
you
an
idea
here
is
the
entire
effectively
g
hash
multiplication
operation
on
a
single
slide.
You
probably
can't
read
it,
but
yeah,
I'm
just
trying
to
get
the
point
across
that
it
isn't
very
much
code.
So
here's
the
heart
of
it
is
bmol32u,
so
everything
you're
seeing
this
is
the
only
part
with
any
multiplications.
B
B
So
I
saw
this
like
it
kind
of
blew
my
mind,
because
g
hash
is
just
notoriously
slow,
otherwise
right.
So
I
think
we
have
a
very
nice
implementation
of
g
ash.
That's
intended
to
be
embedded
friendly,
so
one
more
interesting
thing
is
how
to
do
lightweight
symmetric
cryptography
that
we
support
through
the
chat,
20,
poly
1305
crates.
B
B
So
this
sounds
a
little
scary,
but
there's
a
pretty
interesting
paper
that
came
out
last
year
called
too
much
crypto
that
really
analyze
the
number
of
rounds
that
are
being
used
in
various
cryptographic
constructions,
including
cha-cha
20.,
so
chacha
20
is
a
stream
cipher.
Specifically,
this
thing
called
an
arc
cipher
where
arcs's
add
rotator
xor.
B
It's
a
improvement
over
this
previous
cipher
called
salsa
20..
So
these
are
block
diagrams
of
what's
called
the
quarter
round
function
which
is
kind
of
the
heart
of
the
cipher.
It
takes
some
input
and
effectively
blends
it
up
until
it
looks
uniformly
random,
so
salsa,
20
or
cha-cha
20
can
be
combined
with
this
universal
hash
function
called
poly1305,
which
acts
as
a
message
authentication
code
and
provides
you
this
nice
authenticated
encryption.
B
So
you
might
be
wondering
why
20
rounds
right
like
where
did
where
is
this
number
20
come
from?
So
the
answer
that
we
gotta
get
back
to
1949.
This
paper
called
communication
theory
of
secrecy
systems
by
claude
shannon
in
this
paper.
He
talks
about
this
notion
of
diffusion,
so
diffusion
is
having
this
very
complicated
structure,
to
where
statistical
analysis
of
the
cipher
text
becomes
incredibly
difficult.
B
So
comparing
cha-cha
20
to
salsa
20,
really
quick,
20
improved
per
round
of
fusion,
so
it
has
even
better
diffusions,
also
20.,
simultaneously
improved
performance
right
so
win-win.
So
this
is
really
cool.
Then,
notably
salsa
20
already
had
these
reduced
round
variants.
They
have
these
weird
names
where
it's
also
20
8..
It's
the
eight
round
version
and
it
had
12
round
version
two,
so
I'm
looking
at
both
of
these
and
what
the
best
known
attacks
are.
B
This
is
one
of
the
papers
that
came
out
that
did
most
of
the
security
analysis
around
them.
It
was
in
2007,
new
features,
latin
dances
and
then
in
2019
we
got
this
too
much
crypto
paper
you
might
notice.
The
same
guy's
name
is
on
both
of
them.
Jean-Philippe
anderson,
mr
jean-philippe,
knows
what
he's
talking
about
because
he
did
the
initial
attack
some
of
the
best
attacks
against
both
of
these
algorithms
and
what
they
saw.
B
Salsa
20,
it
was
broken
quote
unquote,
as
in
it
was
reduced
below
its
promise
security
margin
of
256
bits.
The
seven
round
version
of
salsa
20
was
broken,
as
well
as
the
eight
round
version,
so
you
need
at
least
nine
rounds.
It's
also
20
to
get
the
full
full
security
promise
security
level.
Trout
7
was
broken.
B
So
in
conclusion,
chacha
20
is
overkill.
Probably
should
have
been
standardized
with
20
rounds
like
12
would
have
been
sufficient.
It's
kind
of
a
mistake,
and
it's
kind
of
unfortunate
that
was
standardized
for
20
rounds,
but
eight
rounds
still
beats
the
best
known
attack
and
gives
you
a
256-bit
security
level.
B
So
if
you
want
to
get
more
performance
out
of
this,
you
can
get
effectively
a
two
and
a
half
x,
speed
up
by
using
one
of
these
reducer
or
using
the
cha-cha
eight
reduced
round
variants,
and
if
you,
you
know,
want
to
take,
maybe
a
little
bit
less
potential
risk,
but
not
really.
You
could
use
cha
cha
12
instead,
so
you
offer
this
cha
cha
each
pulley
1305
variant
in
the
charge
of
20
poly,
1305
crate.
B
So
if
you're
looking
for
a
very
fast
software
in
software
that
doesn't
need
a
cryptographic
accelerator,
this
is
the
one
I'd
recommend.
So
finally,
the
this
is
the
end
of
the
euros
crypto
section.
We
have
elliptic
curve
cryptography,
which
I'm
very
excited
about,
and
I
think
it
might
be
very
useful
for
rust
embedded.
B
So
some
quick
highlights
on
what
we're
doing
so.
We
support
the
legacy.
Elliptic
curves.
These
are
the
ones
these
are
actually
the
I
say
legacy,
but
they're
the
ones
you're,
probably
going
to
care
about
they're
wire
straws
curves,
either
the
nest
curves
or
sec-p.
This
cryptocurrency
curve
we've
implemented
the
modern
formula,
so
the
older
formulas
had
all
sorts
of
security
vulnerabilities.
If
you
ever
saw
djb's
like
safe
curve
site,
he
made
fun
of
them.
B
This
is
kind
of
the
things
djv
was
complaining
about
have
been
addressed
through
the
use
of
these
modern
formulas,
so
optimizing
for
correctness,
first
performance,
second
and
providing
constant
time
implementations
based
on
the
subtle
crates,
perhaps
most
notably
we're
not
using
any
lookup
tables.
These
are
usually
the
killer,
a
thing
for
doing
elliptic
curve,
cryptography
and
embedded.
So
we
have
compared
to
most
other
implementations
very
small
code
size,
so
here's
a
kind
of
at
a
glance
table
of
the
status
of
all
these
things.
B
B
B
We
intend
to
mitigate
our
random
number
generators
they're
using
deterministic
ecdsa.
This
rfc6979
technique.
Funny
thing,
though,
when
you
do
that
you
open
yourself
up
to
fault
attacks,
so
there's
an
even
more
interesting
technique
we
might
explore
which
allows
you
to
combine
both
the
determinism
and
the
randomness.
In
addition
to
this
random
finding
and
mitigate
fault
attacks
as
well,
by
adding
even
more
randomness
to
the
signature
generation
process.
B
B
So
the
problem
is,
you
know,
even
if
we
have
these
nice
cryptographic,
implementations
like
as
adi
shamir
said
cryptography
isn't
penetrated
it's
circumvented,
so
usually
the
crypto
isn't
the
part
that
breaks
it's.
The
tldr
of
this
is
things
like
x509
and
asn
1,
and
all
that
devices
are
routinely
compromised
by
failing
to
parse
x,
509
certificates,
correctly
failing
to
validate
the
signatures.
B
Unfortunately,
this
sort
of
process
is
often
instrumental
in
things
like
code
updates,
boot,
loaders,
secure
boot
processes.
That
kind
of
thing,
so
this
paper
I
have
up
is
a
very
scary
paper
about
how
pretty
much
nothing
besides
browsers
implements
x.
509
correctly,
you
know
all
all
these
things
have
like
horrible
security
vulnerabilities,
see
quick
overview
of
veriform,
so
provides
a
canonical
encoding
using
a
taglink
value
structure,
which
is
very
common.
B
We've
taken
ideas
from
both
asn.1
a
few
of
its
different
encodings
as
well
as
google
protocol
buffers.
I've
done
a
heap
list
new
did
first
implementation.
This
is
all
we
support
right
now,
so
this
is
what
we're
targeting
via
armistice.
So
it
will
work
out
of
the
box.
You
don't
need
a
heap
cool
thing
that
really
makes
it
unique.
Is
this
concept
of
structured
hashing?
B
So
we
automatically
compute
digest
for
all
parts
of
a
message
in
as
part
of
the
message
decoder,
so
it's
extensible.
This
is
kind
of
a
big
important
thing
in
x509
and
tls.
This
is
capable
of
supporting
unknown
fields
in
security
contacts.
You
may
not
want
to
have
fields,
you
don't
recognize,
so
it
also
supports
this
idea
from
x509
of
being
able
to
mark
certain
fields
is
critical,
so
if
you're,
the
decoders
these
are,
these
fields
doesn't
know
what
it
is,
but
it
has
this
critical
bit.
B
It
will
fail
to
parse
the
message
if
it's
security,
critical
and
finally,
it's
got
these
cool
product
macro
derived
encoders
and
decoders
that
were
inspired
by
prost.
So
here's
a
really
quick
syntax
example
showing
the
product
macros.
If
you've
ever
seen,
pros
drive
it's
very
similar
to
that
you
drive
message:
you
tag
each
of
the
fields
with
these
attributes
and
it
will
automatically
generate
a
parser
and
serializer.
B
Yeah,
I
can
wrap
it
up
quickly,
so
you
see
there
yeah.
This
would
be.
This
is
good
for
certificates,
we're
using
it
for
our
pc
and
finally
for
having
cryptographically,
authenticated
and
signed
logs.
That's
it
thanks
for
watching
everyone,
and
there
are
some
final
links
and
I
will
take
questions
in
the.