Dear viewer, these subtitles were generated by a machine via the service YouTube and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/2566 Thanks!
[Music]
I'm very happy to announce to you um a
speaker who has a very long experience
with pen testing who's been doing crypto
since he was a kid after he uh read a
book that inspired him when he was a
teenager but um he also told me that he
doesn't want to talk about himself he's
here to talk about projects but I even
would recommend to check out his bio
because Steph had really interesting
projects done in his live and I'm really
really happy that he's here today to
show us uh in his words cinematic
version of a talk that was already um
published on YouTube where he's going to
show the link afterwards where you can
see like the director's cut later if you
feel like your appetite was wed um we
are not most likely not going to have a
Q&A afterwards but um Steph will be
available from 400 p.m. on in the house
of tea to do the
Q&A um so um without further Ado please
um Applause for
Steph hello hello can you hear me great
hello welcome this is going to be my
little rabbit Hall and uh maybe some of
you will also follow me down this rabbit
Hall um I don't have much time
um there's a lot of really awesome stuff
to be shown so so um there's two parts
of this talk first of all I'm going to
tell you a bit about how opfs work what
they can do and uh this is based on a
very awesome paper by kazak Kua Hessa
and lemman which is called uh
systemization of knowledge which I can
warmly recommend to all of you the
reference is always in the footer you
can download the slides and then if you
are interested in this whole topic this
is a really good starting point this
paper it has references to a lot of very
exciting and very accessible um papers
academic crypto papers the second part
is going to be some practical examples
of um software and deployments where
opfs are deployed in the real world or
where you could think of deploying opfs
yourself okay first of all just uh
little to vet your appetite what you can
do with opfs opfs are essentially a
building block for privacy it's not
about so much about encryption or
decryption or signing stuff of course
you can do those things as well but um
here um oblivious keyword search is when
you have a database which knows all the
the the details in the database but you
don't want to disclose the queries to
the database so you have a client and
you don't want the database to know what
you are looking for and so keyword
search is like a key value store where
you go with a key and you get some value
back without the if it's oblivious
without the database actually learning
what your query was what the keyword was
you were looking for private information
retrieval is something similar but here
you don't go with a keyword or the key
but you know the index of the record in
the database that you're quering really
secure pattern matching is when a server
has like a string or something and
you're looking for a substring and the
position of the substring and you don't
want the server to know um what you're
actually looking for while you actually
learn the answer to your query private
set intersection is also very exciting
um topic that I'm going to come later in
the Practical examples so we're going to
skip that also uh p password key
exchange and Cloud management and
password storage are topics I'm going to
come back later to and the last four
points I'm leaving up as an exercise for
you to follow up either reading the
papers or something these are also quite
exciting topics that you can for example
this is of course a non-exhaustive list
of Awesomeness that you can build from
Ops so first let's have a look what a
prf is before we go into what an
oblivious prf is so a pseudo random
functions basically a key
function with a with a second input that
generates some uh output that is
non-distinguishable from random
output um so if you if you want to
imagine this it's really like a hash
with a key and a message and the output
is some hash value that is
indistinguishable from a random
output um so it's like hash key key key
hashing or calculating a a Mac something
happened with my
slides um so it's like a key uh uh
message authentication code for example
or something like that uh that's a
pseudo random function very simplified
there will be people who do crypto who
will be screaming right now um but uh I
think for this audience this might be
enough
um okay so this is a pseudo random
function and if you do the same so
basically you have two inputs you have a
key and a message and you have some
output that is some random value really
so and if you do this in an oblivious
setting then you have two parties you
have a party that holds the key and
another party that holds the message and
you computate compute a prf together but
only the party who holds the message
learns actually the output of of the
computation so in this example here you
have a you don't see anything of my
corser you you see the cursor okay so
Alis has a message and Bob has the has
the key and that they contribute the key
and the message to the to this function
the oprf function and only Alis
oh okay
so so only Alice learns the output of of
this
oprf this is like an interactive key
hash really or a multi party computation
uh if you if you want to consider it
like that so there's a bunch of
techniques how you can create an
OPF uh the first basically U you have a
prf and with some kind of um uh
conversion you can uh create an
oblivious version of a prf the first
that was uh possible to do so was in
2004 the now A Rang God and there you
apply
um oblivious transfer or uh homomorphic
encryption and then you have an oprf uh
then you have these others um but I'm
not going to spend much time this is
something that you should either look in
my uh uh director's cut
um [ __ ] ah it's back so uh these these
three constructions I'm not going to go
into much detail later I'm going to
refer to some of them but the most
exciting and most important one is the
hhdh or two hhdh uh construction and um
that basically just calculates this uh
very simple
uh formula if you see the one I don't
know how much you see the red part that
is like the inner one you have a a
special hash function that hashes your
message to to a point on a group uh most
of the time this is uh we are always
working here with elliptic curves so
whatever you hash the message is going
to be after the hash a point on on an
elliptic curves uh on on on a specific
elliptic curve so this is not a normal
hash this is something we call Hash to
curve and this just came out with the
irtf cfrg a specification just uh this
last week so after 21 years of trying to
Define one that applies to all uh
elliptic curves also the NIS curves not
only the
25519 derivates so um this is a very
simple uh thing you hash to a curve and
then you just raise to a to the to to
the secret key and then there's a second
variant of this this is the two has DH
where we hash the message again with the
result of the hashd uh construct this is
also very nice um because the second
hash destroys this algebraic structure
that's the that the hash DH has which
allows us to do some Nifty stuff but uh
with the second hash we actually get to
a construct that is Avail that can be
proven in the uh Universal composability
framework which is a very strong way to
actually argue about
protocols and constructs yes there's a
question so H Prime and H are both uh no
uh only H is a hash to curve the second
is just a normal hash and can be really
any hash if you want it good very good
question the question was if those both
are for elliptic curves not just the
inner one is for the elliptic curve or
hash to the group really question uh one
thing so the outer hash can also be a
memory hard or cach hard or any other uh
hash function like argon to uh for
example there's a follow-up question so
how do you convert the curve something
you can well if you uh well it's the
elliptic curve uh in their um um
serialized format usually if we we we
consider we usually use restr 225 uh 255
and that is 32 bytes really and it's
just 32 bytes um that's it um that's the
most common uh way of actually doing
that okay so and how do you instantiate
this so in uh the client has the message
and uh generates random uh scalar R and
that is what we call the blinding factor
and it just hashes to the curve their
message and then blinds this point by
raising it to this blinding Factor R
this we call alpha alpha is being sent
over to the server the server just
raises this Alpha value to K and then
sends this beta value back and then in
the end this is the I don't know how
many of you people see this but this
beta value is then risen to one under R
and then the r eliminates uh the
blinding uh uh the raising to R here and
then raising to one under R here
eliminates the whole blinding factor and
what you are left with in the end is
actually exactly what hash uh DH was
supposed to
do
um it's uh it's a very simple thing if
you if you look at this I think it's uh
the Brilliance is also in the
Simplicity okay
so this is the base from which we are
going to start and we are going to look
at a bunch of really exciting properties
that you can build on top of this or
that are actually inherent in this
construction already so the thir thing
that you can build from an oprf is
something we call a verifiable oprf and
which is uh useful if you have some kind
of iterated oprf uh uh um calculation
and you want to make sure that the
server always uses the same k key
correctly and for that the server
publishes a zero knowledge proof that
they actually used key correctly uh this
can be done uh for any oprf really but
uh there are some OPF constructions that
are uh lend themselves to more efficient
uh proofs um so why is this useful for
example imagine you want to have uh an
oprf calculation in which you provide
privacy for yourself and you the server
cannot identify you later on so imagine
the case when the server is actually
malicious and uh knows that you are you
but doesn't know who you will be in the
future if it operates with this protocol
correctly so now that it knows that you
are you and you want he wants to
re-identify you instead of using K the
it's using for everyone else it uses a
specific K value only for you and then
next time you come and use this
calculated oprf value to the server the
server will see oh I'm not using the K
value that I use for everyone but I use
this K value that I only use for you and
so this is how the server can later on
the uh anonymize you and so for um
defending against this you want to have
a zero knowledge proof uh that K has
been used and verify op opfs actually
provide that okay the next one uh as a
property is a partially oblivious uh
pseudo random function this is exactly
the same as the the one that I showed
you earlier there's just one extra value
this is this tag T this is a public
value that also needs to go into the
calculation of the
oprf um this might be known by the
client and the server this might be
public it might be sent over in any of
that direction but the thing is this is
a public value that is known by the
server this is not a secret
value and uh here you can see this is a
very generic uh construction uh the um
this public value tag T is actually sent
by the client to the server together
with Alpha and then the server in this
generic construction actually calculates
a
prf uh so this is the non oblivious
version it's just a key attach
really um and uh it it takes the input
uh the tag as the input for this prf and
that generates a new key that is
depending only on the on the tag and the
the key it helds and then uh that is
being used instead of the key so why is
this useful this might be useful for
example if you have a username and the
server wants to have uh distinct key for
each user so in this case the username
would be the tagt uh this also helps the
server for example to identify Brute
Force attacks or or to to uh enable rate
limiting so if you if the server sees
that uh user Bob has thousands of uh OPF
evaluations per second then it might say
hey slow down mate uh and so that allows
a rate limiting or or any other um
security measure yes there's another
question St question but is biger or
fin question how do
[Music]
you so the so the question was uh what R
is I yes I a bit sloppy and and writing
this down I was uh it is a uh it is a
scolar on the field of um of
yes so okay so um that's the the
blinding Factor yes indeed okay so um
that is a partially oblivious you can
combine these two with the verifiable
and the partially oblivious one but with
hhdh this is especially in this way of
its construction is very um uh difficult
and not very efficient because for every
key you need to publish a public key for
the zero knowledge proof uh this other
construction this dois Yos key is
actually one where this is efficiently
uh
possible this construction is not very
nice to combine with a very to to create
a verifiable
oprf yes yes so there there is more
efficient constructions if you want to
have a verifiable and partial
oprf okay then you can have also the
case when you want to do batching which
means you want to calculate an oprf over
multiple Keys like with the same message
but with multiple keys and you want to
or the other way around when you have
multiple messages and you want to
calculate them with the with the same
key and of course if they if they can do
batching then that really means that
this is more efficient than if you would
do individual OPF calculations so this
this uh batching really is a is a
performance uh uh property that is uh
actually possible to achieve in some uh
constructions okay then uh really Nifty
one is an updatable
oprf um in this case you already have
the result so Ellis has the result of a
previous calculation of an oprf and then
Bob says [ __ ] my key uh needs updating
because it got compromised or uh because
I'm just uh ratcheting my key I need to
like you know regularly update my key
and so I uh Alis doesn't want to
recalculate a full oprf with Bob with
the new key so uh with an updatable oprf
uh Bob can send an update token so that
Alice can update the previous
calculation of the oprf to be valid with
the new key of
Bob and uh this is really simple
actually
so when Bob generates a new key which is
just a random number K Prime and then
the update token which we call data is
simply just K Prime divided by
K uh and uh this update token doesn't
disclose anything about neither the
previous or the new key and this uh data
is then sent to Alice and she can apply
this Delta value to the previous result
by just raising the previous result to
Delta and and the result will be as if
she calculated the oprf with K Prime and
I think this is a very elegant uh way
and this is also a way where you can
actually the update of the previous uh
uh value can be done in a completely
untrusted
environment which we will be in the
Practical uh part we will be seeing an
example of then you have disted opfs
where you don't have one key but you
have a bunch of keys and all of them
have to contribute to the calculation of
the op RF this is really nice because uh
an attacker in this case has to actually
compromise all the key sh uh key holders
uh to actually have any uh security
impact on this thing so all of them need
to be and it's very simple because you
just calculate opfs with each of the key
holders and then you just sore the
values together and that's the output of
your oprf this is a distributed oprf
it's very simple uh can be easily
instantiated from just uh any other
oprf and then
uh the most sexiest of all of them is a
threshold oprf where you have uh the
value key is shared among uh a bunch of
uh shareholders and you need T
shareholders to actually operate on this
key and T is of course less than the
total value of all shares that are
existing this is something like uh
shamia secret sharing if you know that
uh where the key is distributed among
the people and indeed uh you never
reconstruct the key at all but you do
the operation each uh party operates on
their share and in the end uh the client
is doing the com recombination in a way
that the value key is actually never
recalculate it never uh uh manifest
itself in Ram or on disk or anywhere on
the network at all and this is a really
Nifty thing and the only thing it's uh
if and if you if you uh combine it with
a distributed key generation then this
is especially true and uh it's really
really awesome the only thing that you
need to do for actually making this
happen is this lrange interpolation in
the exponent uh which is uh something
that took me quite some time to
understand but um basically you need to
understand how lrange interpolation
works and then for that you need the
lrange coefficient and this uh in uh
mathematics that looks like this uh
horrible uh form but
um it uh it it boils down that you need
to know the indexes of the shares when
you split your key into shares then each
share has an index like this is the
first share second share and so on and
you need to know the indexes of the
shares that are used in this
calculation and so this es variable is
just the set of the indexes that are
contributing to this uh calculation and
then then you can calculate
lrange coefficient for each of the
participants and uh this is the python
code that implements the horrible
formula above there and on the right
side you see this is a a a real world
example of actually the the numbers that
that you're working with because the
indexes of the shares are zero or are
one two three maybe if you have set up
uh with five shares in total then the
highest number you have in this formula
is five and the result are something
like 3 1 and minus three so this is this
is not even high school math right but
the formula looks really really scary
but in the end these are all public
values this is not even Secrets or
anything you just need to know the
indexes of the shares that are
contributing so that you can calculate
the lug Ranch uh coefficients yes sir
shares is like a trusted deer no there's
no trusted the question was if the
shares is a trusted no the shares is
like the the shares that uh the value
key is split into but the you don't TR
don't there the the question is is
there's a trusted person who splits this
you can do that but if you use a
distributed key generation then there's
no trusted
leader um so there's no trusted this is
a completely every node is if you use it
with a distributed key generation
there's no trusted leader every node is
a
equal okay so um and this this is how it
looks uh if you do this there's two ways
if you know in advance which Shares are
contributing then Alice can actually she
knows es this is the set of uh of the
indexes she knows that and she can send
that along so as you can see this is
still the same thing as with a hhdh u
and uh Ellis sends over this um
es um set of indexes that we know in
advance that are going to contribute and
all she all the server does is actually
does two exponentiations here first to
their own key share and then to their
own lrange coefficient which the server
can calculate using this formula or this
python code uh and then that send it
back and then all this the client has to
do is actually just
multiply all the results that are coming
back together and then unblind the whole
thing and then the client has exactly
the same result as if the client would
have done this in a non- threshold
setting
where the value K is not split among all
those people but is in one and it's
exactly the same
result okay but uh most of the time you
don't notice in advance which servers
are going to answer because some is
dossed some is in a safe because for
offline backup purposes so or some is
slow so you just send your request to
all of them and then in the end you do
the L Ranch interpolation so in this
case actually the first two steps are
completely the same as in a uh non-res
hard setting so the client is doing the
same as in a non trold setting the
server doesn't even have to know this is
a trold setting and then uh the only
thing uh that is different do the client
has to do this lrange
interpolation uh in the uh [ __ ] in the
exponent down here before the
multiplication of all the results so and
this is a bit more inefficient this
means that the client has to do a lot of
computation whereas in the case when it
knows in advance what is going to happen
then all the servers can do a lot of
extra computation the client doesn't
have to do so uh these are the two uh
kinds of implementations or
instantiations of how to do this okay
there's some other properties uh I don't
think I'm going to waste the time on
this the only I'm going to mention is
the three-party one which is exciting
it's an OPF where you have a message as
an input you have a key as an input and
the output is learned by a third party
so this is nice for pseudonymization or
something for example you have a
database you want to anonymize it so one
has a database one has the key that is
doing the anonymization and the third
party learns the output and uh so this
is really nice compartmentalization the
rest is also exciting but uh we're
running out of time post Quantum
opfs um not uh not a good it's not a
success story sadly um one thing that is
really nice that uh with hhdh and two
hhdh based uh opfs the message is
actually uh unconditionally cure this is
like uh with onetime pads the onetime
pad is also unbreakable as long as you
don't use the same pad twice or more
times and so um an attacker can have
unlimited uh computing power or
unlimited postquantum computers and they
will not be able to learn anything about
the message that is the input to the
oprf function which is super cool the
problem is that the value key however is
computationa um so it's like it's not
postquantum and that sucks so there is
uh attempts at making all kinds of
postquantum opfs some of them uh that I
listed here I think one of them is
already broken uh most of them are not
very efficient and there's uh there's
one that does actually a verifiable and
partial oprf which I showed earlier
which is not so easy to do with uh 2dh
so but there are all not very efficient
still uh like all postquantum things
have huge keys and lots of
computation um there is however a way if
you don't need any of the special
properties that I showed you before you
can just construct a a post Quantum oprf
by combining oblivious transfer or
multiart computation with i as the
Primitive that you do as a multiparty uh
computation and the result will be post
Quantum and if you use it with an
oblivious transfer um um conversion then
this is actually going to be very very
efficient even uh but it has no special
properties but it's post Quantum in in
all
ways okay so which to use of all of
these um there's I I didn't show you
earlier this Lis yski construction is
the one that you want to use if you want
to do partial oblivious and verifiable
opfs if you want to do something really
really quick then you just combine
oblivious transfer with I and for
everything else you should be really
using uh two hhdh
unless you need updatability because an
updatable oprf needs the uh algebraic
structure that is being destroyed by the
the
autohash so that's um my first part of
the talk and now let's see some
practical examples so the first one is a
private set intersection this is
basically when two parties have two sets
of values and they one of them wants to
learn which are the shared values in the
two sets
and um here what you can do is that uh
one of the parties takes all of their
values and calculates an oprf over each
of those values kind of like encrypting
in a non decryptable way all of those
values and then creates a new set that
uh is anonymized or poniz or obfuscated
or whatever and uh and then this is a
new set that you cannot really
recalculate what was the uh pre-image to
that and that is being sent over to the
other party and then the other party
just calculates an oprf for each of
their values with the same key that has
been used by the first party and then if
the oprf output is exactly the same as
uh one of the values in the set that the
first party sent then they then the
party knows that this is a shared value
and so where is this
useful um you can use it for uh contact
discovery in uh in Messengers so vicer
for example is using this for uh privacy
respecting contact discovery which is I
think super cool and the other thing
where you can use this is for example
services like have I been pound uh which
don't use this kind of stuff but uh
Google has a service which uh can tell
you if your account has been uh leaked
in some uh user um database leak and uh
Cloud flare also has a protocol
migp that uses uh private set
intersection or prfs to uh to have a big
database that you can query if you are
in there or
not um so this is private set
intersection then there's another thing
that is uh one of my projects it's
called SNS it's a password storage it's
really just all that it's doing it's a
it's an oprf so you have a server which
might be a threshold settings oprf so
multiple servers which hold a value K
and then you just input put your
password and what comes out of it is 32
bytes which with simple U conversion you
convert into aski printable password and
then that's what you're using as a
password um and uh
yes uh OPAC is going to come in a later
but the question is how is this
different from OPAC uh OPAC is this Loft
Chad between an OPF and an authenticated
key exchange there is no authenticated
key exchange this is just a naked oprf
uh and you can even Force some certain
output values we have uh if you have a
pad that you sore the output of the oprf
with to the value that will generate the
output in asky that you want to have so
the only limitation with this password
store is that the only thing it can
store really is uh about 45 character
long asky strings or if you only use the
number digits then it can be like 100 10
or so long uh strings of only digits uh
decimal digits so this is not uh what
you expect like these encrypted
databases that uh that everyone uses
like bit word and or
keypass um it has a bunch of really nice
security properties that these Legacy
password managers don't have first of
all the password that you as I said with
oprf uh the input password and the
output password is uh conditionally
secure this is like a onetime pad then
because this is an online construct you
always have the the whole thing forces
you to only have online Brute Force
ability so with a GPU if there's a leak
of your database or password database uh
a GPU or fpga will not be able to
password crack your passwords because
every test means they have to go to a
server to ask for a computation and then
come back uh and that's really slows it
down and then you can also say hey after
10 tries enough so there's there is no
offline Brute Force ability of passwords
in in SPS which is a really cool thing
that you want to have it's a
unconditional secure offline secure uh
offline bruteforce secure and since
there's no encryption uh like with the
Legacy password stores you can actually
have multiple input passwords for like
the one that you regularly use for all
the websites you don't care about and
some that you care more about so you can
have multiple input pass
and if the servers that you're
authenticating to supports it you can
even have uh something like uh distress
and panic passwords and your regular
passwords depending on what you input
the output will be either your regular
password your Panic password or your uh
distress password which uh like just
notifies someone hey there's I he's in
here he's there's no alarm but you know
or like we are deleting everything now
and an attacker will not be able to
distinguish between those three output
passwords so this is a really Nifty
thing that you can do so um there's a
some URLs that you can look at it's in
Dean and uh it's basically mostly just a
a common line thing because I'm not a
I'm it's not my thing to do the rest
okay now OPAC is a widely deployed uh in
instantiation of op or protocol based on
opfs um this is a love CH of an oppr
authenticated key exchange and uh most
common uh usage use scenario we use
triple Dy Hammon which is the same
authenticated key exchange that is also
used in in the signal protocol and uh
really what you can do with an
authenticated key exchange in or OPAC
itself is from the client perspective on
the client you don't have any state you
don't have anything stored only thing
that you need for OPAC as an input is
your password and then using that
password and the OPAC protoc call you
can have three things the first thing is
you can uh mutually authenticate each
other to uh to each other the server and
the client and actually the server is
first authenticated and the the so the
user actually knows that the the other
party is the server and then afterwards
the user can authenticate themselves to
the to the server as well if it's
necessary it's not always necessary you
can have uh uh data protected at rest on
the server so you can like store file
has there on the server and you can get
access to them with only your password
from the client or uh since it's an aut
indicated key exchange of course you can
also just use this whole thing to set up
a protected Communication channel
between the client and the
server um there is a a draft in the irtf
the internet research uh task force
cryptographic for research group or
something um it's it's kind of stablish
now um um there's an implementation by
this by me it's called liop par it has
bindings to all the languages that you
can imagine but there's also other
implementations like uh Facebook has one
uh that is Opa care and that is actually
being deployed uh for WhatsApp they
store backups uh using OPAC where the
client only needs their password and the
username and then they can restore all
their data on any device if they know
their username and their password and
this is a really cool thing and I also
implemented some something like that it
is called OPAC store and it really goes
well with Spinx because SX is very
limited in storing data uh and it
shouldn't actually and with OPAC store
you can do that and OPAC store is the
first uh public implementation of a
threshold OPAC instantiation so OPAC
itself can also because it's an oprf
underneath you can actually instead of
using just a normal oprf you can also
instantiate this with a threshold uh OPF
which I did and so you can store your
data in a way that the keys are
distributed among a bunch of uh servers
or shareholders or
whatever uh and then there's one more
thing uh there's also work in
integrating uh OPAC on TLS level and I
think that's uh actually very reasonable
because then you can eliminate client
authentification Sears you can
authentification yourself to the server
and based on the password also uh set up
a protected Channel which is the right
uh thing to do if uh there's I
implemented also OPAC for for sule which
is this authentication layer for IMA pop
tree FTP and so on but that is the wrong
layer of actually integrating this I
think this is the TLs level where this
should be done so I'm very hopeful that
uh one day we will have TLS OPAC okay
next topic uh privacy pass is an
instanciation that is also widely
deployed some of you might know that you
might have seen it when you browse um
websites using the tour browser then you
get these captures from cloudfare that
they want to actually know that you are
not a bot and then you have to solve the
capture
and and uh people don't like
that and
um and so Cloud flare came up with this
privacy pass protocol which when you
solve uh a capture you can
uh uh get a bunch of tokens privacy pass
tokens that um you can show to Cloud
flare later on when Cloud flare wants to
see a new wants to solve you a new
capture and instead of solving a capture
you just pass on one of these privacy
pass
tokens and uh this uh is used by by
cloudflare but since a year this exact
same protocol is also used by Apple for
the web environment Integrity
implementation which is now a big HHA
for Google that wants to do this in
Chrome I think you heard about that and
uh so Apple actually deployed this one
year ago in
Safari and uh Google doesn't want to use
privacy pass because it has twoo strong
privacy guarantees and they want to have
a more invasive uh um DRM so [ __ ] them
um
gole and um so the the whole thing is
really a very simple protocol actually
it's just a it's a it's a blind uh
signature over some tokens that you give
that you as a client make a cloud flare
or Apple sign and then um later on this
blind sign token can be presented it's a
very simple system but um I think it's
also a bit hypocritical because it
protects you uh against uh Cloud flare
and snooping by Cloud flare while at the
same time um they are the one that
deploy the protocol the implementation
so whenever they want they can just um
play play something else to you and so
um this is um Lando's law which I warmly
recommend to you and contemplate uh if
it makes sense to deploy a security
protocol implemented by the people that
you want to protect against this also
applies to Signal actually uh okay and
then the last one this is the virtu
verifiable threshold updatable oblivious
Key Management Service a key management
service is a a data address service
Amazon has one of these so with Amazon
there is a KMS service that you can rent
you have a client that wants to do
things you have a storage that is uh
able to store data but in an untrusted
way and you have a key management server
that is good with handling keys or
protecting keys so that is most of the
time it's an HSM and the storage is just
some Amazon uh bucket or something so
this is how it works it there's nothing
really exciting about is when you
encrypt some data you generate a random
key you encrypt your data then you send
the key over to the KMS server who has
their own Global key that encrypts your
uh unique key and then that gets sent
back and then you can store the
encrypted key with the data that it
encrypts uh on the storage and then the
other way around this is something that
we are kind of doing since '90s there's
nothing really exciting about this I
just wanted to show you it sucks in many
many ways um the server knows all the
encryption Keys the KMS knows all the
encryption Keys you need to somehow
encrypt between your client and the KMS
so you need TLS if there's middle boxes
or TLS Terminators then they also learn
your decryption keys they can TR trace
the usage of these keys and uh they're
not updatable or if they are updatable
these Keys then those take a lot of time
and not very efficient and that's also
one HSM is just a single point of
failure and backups are not very easy so
but you can solve all of these problems
if you just use an updatable threshold
oprf where the decryption key is really
just the oprf with a key that is stored
at a KMS and the data ID and and that's
it and then there's this awesome paper
this updatable oblivious key management
for storage systems by these three guys
jety craft Chi and rash which is a it's
a brilliant paper I warmly recommend
everyone to have a look and it solves
all those problems okay there's two
implementations one is by Jason rash who
is one of the authors of the paper it's
called protect it's in Java and it does
a bunch of lot more things than just uh
implement the paper and I have my own
implementation which is called clnic and
it has some urss and you can stare at
code and so on the whole thing works
like
this um and I'm not going to go into
detail but uh basically we we saw all
the details during this presentation how
this works uh and you can actually do
the uh update and this is the thing that
is a bit interesting you how do you do a
threshold updatable uh oprf here you
need uh first of all there's one hard uh
requirement that you need to have more
shares distributed than two times your
threshold plus one so that means you
have you need a lot of threshold uh
shares uh all the shares need to
participate in the update otherwise they
get out of sync so this is this is uh a
bit of a limitation and then uh you just
do a distributed key generation among
all the shareholders and then that is a
that is an uh a new value and then you
just do a multiparty multiplication
between this new value and the shared
key that the old the old key and so you
multiply the old key in theory with this
new value that you just generated and
then the this new value that you
generated is actually the deltaa token
for updating on the storage and this is
really nice because you can send this
Delta token to Amazon uh the storage and
say this is the data token and Amazon is
not able to use this token for anything
but updating the key and so um this is
all possible but it's a bit more uh
involved so that is it and so why why
this is super cool first of all you have
very cheap key rotation so that can
provide you with forward and post
compromise security the whole thing is a
threshold operation so you are very
resilient against uh denial of service
and loss of key and compromise of keys
uh the the master key is never stored
anywhere at all not even in in Ram
during computations whereas if you
consider like pgp or AGA or something
then you have somewhere a key stored on
your disk most of the time it might be
even next to your crypted
files and and so it has drawbacks first
of all it's online but I don't know if
that's really a drawback in some cases
it might be in some cases it doesn't and
and uh there's strong authentication
needed so the key management servers
need actually uh to somehow authorize
you if you are actually able to do the
operation that you want to do so that's
uh that's something but that can also be
depending on the use case that you want
to do okay so they are cool mostly
provide privacy these opfs you need to
have two parties and they don't want to
share all the information with each
other it's also very useful if you don't
have anything you don't want to store
anything on the
client um
uh no data only like a password when you
want to convert uh low entropy something
into high entropy
cryptographic uh value and uh it's very
useful for rate limiting okay there's a
bunch of papers that I wanted to show as
outakes uh just shortly these are all
very exciting so if anyone ever wants to
play with Ops and do some cool [ __ ]
these are papers you might want to work
with and uh questions and comments at uh
t
[Applause]
house thank you so much Steph for
sharing your insights um as he as said
at the beginning there's also a
director's cut of this talk on YouTube
so check this out if you want even more
details about
this
and there's a Q&A at the house of tea
from 400 p.m. on if you have any more
questions