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/2503 Thanks!
[Music]
so um Mato and Ken are going to tell you
how to Unbreak things even if they
aren't broken so their title is if it
ain't broken do fix it building modern
cryptography so give a warm Round of
Applause and we will
[Applause]
start so hello everybody and welcome to
if it ain't broken do fix it a primary
on building modern cryptography
uh before we start a few things about me
and Ken we
are uh both PhD student at the applied
cryptography group at tth zich and we
spend most of our days
analyzing uh protocols that is
cryptographic protocols for for fun and
not so much for profit actually but it's
it is fun and we actually finished these
slides yesterday night so be patient if
there are some some typos uh or some
unclear things and thanks to kler for
the night
peek okay so to start as academic
cryptographers we are constantly faced
with the question or with the sentence
it ain't broken right like my
cryptography has been withstanding
attacks for for years there is no
practical attack against our
construction and what I want to tell you
is that cryptography much unlike Roman
aqueducts is not something that is built
to withstand Millennia and if something
starts to break then we should take
radical action to repair
it or to tear it all down and build it a
new this is p Morandi in
Genova to start like to motivate this um
disposition I will start with the SSL
TLS Saga so many of you probably know
about SSL or TLS is the green padlock
protocol that protects all of our
internet connections and everything
started with nothing there was no
cryptography at
all then in 19 1994 sslv2 was
released um and these had many attacks
and as widely being regarded as a bad
attempt we may say so just one year
later SSL V3 was released and SSL with3
is was subject to every possible attack
you can find in an applied cryptography
handbook so we have padding oracles we
have uh repeated IVs we have uh black
EMB backers attack on RSA instructions
so no
surprise uh other version were released
like there was TLS uh version 1.1 1.0 in
1999 uh this created a lot of confusion
in the naming of SSL it's still the same
thing secure socket layer and transport
level security but the name changed and
you will piss cryptographer off if you
call it SSL nowadays the name change it
more than 20 years ago so let's call it
TLS from now on and we keep having bugs
and different implementation and
cryptography vulnerabilities in 2008 TLS
1
Point uh two gets released and that's a
bit of a landmark TLS 1.2 will last from
2008 for 10 years until TLS 1.3 is
introduced in 2018 and even this even if
this uh TLS 1.2 continues to suffer a
lot of bugs a lot of attacks return
including black and bucker on the RSA
still present in TLS 1.2 and even
padding Oracle and attacks like Log Jam
um that Target weak defilement groups
and like we we see a lot of attacks in
TLS 1.2 but it keeps surviving because
it's the current version we have and
it's also used today and it's still
secure because it's heavily patched and
it uses currently a heavily restricted
set of Cipher s but the the real deal
comes only at the end of this timeline
and this is TLS
1.3 which we which was standardized in
2018 and we keep using today and the
reason why I really like TLS 1.3 is that
if I now add all the attacks to this
slide it becomes some something like
this so we have a lot of red every every
balloon there is one attack on TLS all
the way up to TLS 1.2 and then they stop
so something must have changed with TLS
1.3 and since the history of TLS has
been already told many times I will um
explain how what we can learn from this
broken
crypto uh but not using TLS as an
example using some more recent
cryptographic breaks and then showing
what we can learn from the cryptographic
breaks I will start from Mega you're may
be familiar with mega as a file sharing
application it's they also claim to be a
secure cloud
storage and
um it's a secure cloud storage in the
sense that it is end to end encrypted so
they claim that uh each user have their
keys without a user key nobody can read
their files not even Mega and now this
work is when you want to create an
account on Mega your your browser will
generate a cryptographic RSA key then
we'll encrypt it with your passphrase
like the password that you use to Lin
into
Mega and only send this encrypted
version of your key to the mega server
which then can store it in a database so
like Mega never sees your actual RSA
key then when you want to access your
files or to upload a new file you can
login into Mega with your
password you can ask for your keys Mega
will fetch them from the
database send them back to you and now
since you have your own password you can
decrypt this key and use it to encrypt
your files with some RSA based
construction let's leave it at
that and this looks pretty good doesn't
it I mean it's uh at least at this level
of obstruction this could be secure this
is actually how we would build a secure
Cloud encrypted storage but the problem
with cryptography often lies in the
details and one SC that Mega committed
is
using as ECB mode it's not really
visible now on the slide this is the key
derivation of Mega so this is how your
password is used
to derive other keys and then to protect
the RSA key that we were talking about
before so that component there where the
L ke is is the key I was talking about
before and this is encrypted with as ECB
is this a problem well ascb is not um
considered too secure right like when
because of attacks like the ECB tax
penguin uh maybe some of you recognize
that if you encrypt two plain text block
with the same key using ASD ECB you will
have the same Cipher text output but
this is not really a problem in this
case because we are encrypting High
entropy material such as a key so there
could be nothing wrong about this in
fact like let's
take this example plain text hello CCC
people encrypt it with ECB and obtain
some like garbage that nobody of you
could decipher unless I give you the key
to decrypt it and go back to AO CC
people ECB also has an interesting
property being applied to only one block
it's essentially like just app the as
encryption
operation on a single block so if you
change any single bite of the cipher
text the result will be completely
scrumbled okay so in ascb if I change
one bite of the
input of the input Block in this case
the entire output block will
change so this is still looking pretty
good for us it means that unless
something very strange happens Mega can
still not see our keys our secret
protected RSA
Keys uh but this is actually the root of
one mity that was found in mega
so um let's say that you register your
RSA key with mega restore it all fine
I'm just substituting the the the blue
key with the actual piece of
cryptography that is in
inside and now you go to
login you ask for your keys but instead
of giving you your keys Mega gives you
something else like some Cipher text
that they have tampered with now we know
by ECB encryption that this will decrypt
to
garbage and the problem now here is that
the user cannot really tell this garbage
from their RSA keys so when the user
receives this
block of garbage they will think oh this
looks legit let's use it from for some
RSA paration they will try to encrypt a
file and then maybe fail or maybe
succeed but this operation like this
using garbage for RSA
encryption can and will leak something
to the adversary about your
key so it's March 24 202 two just last
year and one paper from our research
group comes out Mega Mal encryption goes
aai uh you will notice that um academic
cryptography like dramatic titles so
uh um but the attack presented in this
paper are actually very interesting and
in
particular we Pro that with just 512
login attempts to mega mega could
recover your entire private
key this is very interesting we went
from a system that from a high level
perspective was completely secure to
something that is trivially broken or at
least from our Point of View trivially
broken in just 52 login attempts Mega
did fix this vulnerability but they
commented about the 512 number being an
impractical number of login attempts for
a standard Mega
user and that's where one of the
principles that I want you to remember
today kicks in because just a few weeks
later some of our colleagues from San
Diego saw our paper and they thought oh
well we think we can do better so on
July 13 we had the same attack but in
six
queries now things start to get
interesting because there is competition
between two academic
groups
and so we could not stop here and there
is this final comeback paper in
September after like few months of very
hard work we managed to bring back the
number of attempts needed to just two
login attempts so now if Mega had not
fixed their vulnerability you could lose
your RSA key in just two logins which is
pretty
sweet so first thing to remember from
today is do fix it even if it ain't
broken yet because attx only get better
if you have an attack it will not
disappear it cannot get worse over time
it can only get better maybe it will
stay the same maybe it will keep being
secure for a decade or so but then you
will get eventually a better
attack staying on
Mega uh what we just saw this capability
of the server to change your key with
something else is called by a
cryptographer key overwriting attack or
for friends
KO and I really want to show you another
KO attack this time against pgp our
beloved pretty good
privacy so the setting is as usual
except that the the colors are
not um the gender Norm ones Alice and
Bob both have pgp
keys want to exchange some secret
message so Alice writes their her
message uses some pgp implementation
such as G PG to encrypt it with Bob
key and now we have a pgp encrypted
messages that can be sent out over the
wire or over pigeons or whatever doesn't
matter because whoever intercept this
message would not be able to read it
then Bob receives the message uses the
same or maybe another implementation to
the Crypt it and can retrieve the the
plain
text all good so far we have two users
two keys and this would actually be
pretty secure pretty hard to break in
this current restricted setting one of
the problem with pgp and M solution
actually comes when you start putting
things in practice and adding more depth
so for instance let's take our user Bob
maybe Bob
one phone then another old phone maybe
that uses only as a burner for for
conferences then a laptop and then an
office
computer and still only one pgp key that
now has to be shuffled somehow between
all of these devices so what do we do
with this key well one solution is we
just put it everywhere on all of our
devices another solution is We Trust
some other platform like keybase or
Proto mail to keep the key for us in the
cloud uh and then we can access this
cloud from all our
devices in either case uh what
happens if either the cloud or one of
your devices gets acted so let's assume
now that the adversary has access to
your key for some limited amount of
time
and um here pgp keeps us safe so the
structure of a key is actually like this
if you follow the standard you have like
most of the public parameters of your
key are just plain text but the really
important bit the private part of your
key is encrypted with your PA phrase so
even if you left your key on your laptop
and your laptop was unencrypted your key
was still locked hopefully if you set
the password and the same with with
proton like if you had your proton
account and your key was on proton
servers then it would still need to get
decrypted before you can use
it and well this also looks like it's
all fine like
the the important part of the key is
actually encrypted and authenticated so
it cannot be modified by an adversary
nor read by an adversary so everything
is okay
right and as you can probably guess well
it's not okay because the public part of
the key is in
a space in a space of unprotected
unencrypted plain text which means that
not only the adversary can read it this
this is okay in our public key setting
but the adversary can also modify
it
and this LS us to more key overwriting
attacks the adversary changes that
public part of the
key and make it a pgp key quote unquote
which is maybe no longer a correct key
for public key operation but still looks
like a correct key to an unaware client
unless they do some very expensive
verification of the
key and now the adversary
can like after they had access to Bob's
key Bob will start using this key for
normal encryption and decryption
operation so maybe the adversary malie
can send a message to Bob Bob will
attempt to use the
key to decrypt this message and get an
error which then will be communicated to
mallerie or maybe get no error which
then will be communicated to mallerie
Maybe by hitting uh by simply replying
to an email if it was an email or if
it's some other interactive system in
some automated fashion and now malerie
can observe these errors or the absence
of these errors from Bob and learn
something about the key about Bob
key and like this paper also from some
members and x members of our group
Victory by KO presents one such attack
against
pgp where if you repeat this cycle of
like overwriting the key once you only
need to do that once as a cloud storage
or as a evil
made and then send 338 messages and
observe the error or lack
thereof then you can recover a full 2 48
bit algal key from from
pgp that's like a pretty uh interesting
vulnerability from an academic
standpoint but also like from a
practical standpoint because if you if
you use pgp maybe for only for emails
this wouldn't happen it would be hard to
make it happen 338 times but if you
start using it for cloud storage or like
keyas you you use it everywhere all over
your infrastructure then interesting
things can happen such as like as the
right setting to make this attack
practical and this could only get better
as we saw
before so how do you prevent key
overwriting attacks the solution is to
always
use authenticated encryption with
Associated data nowadays like it's 20123
there is no reason not to use Aid it's
as fast as any other uh encryption mode
of
operation and it protects your Cipher
text from tampering which means that an
adversary cannot change them and there
is no possible setting where you would
want somebody to change your CER text
without being able to decrypt them so I
think it's a very reasonable thing to
assume that you don't want your saex to
be modified on the flight and it also
allows you to store un encrypted
data that is still authenticated so non
temperable by an adversary and this is
also what happens actually in the open
pgp in the pgp cryptography refresh they
start using a not just for the private
part of the key but for the entire key
so that the the Integrity of the key as
a whole is
protected this is a toy example on how
to use Aid it's really simple uh you you
can use we there is a high level if you
like python uh you can use cryptography
doio it's an highlevel uh python
cryptography library that will help you
not shoot yourself in your foot in your
feet when writing crypto and this is how
you would use Aid to encrypt a secret
message with an authenticated but un
encrypted
a so regarding to key over right attacks
do fix them and in general use at least
authenticated encryption for everything
now I leave the floor to
Ken that's okay all right so um yeah so
because I'm a fan of space repetition
let me repeat the last two lessons that
we've seen so the first one being uh
attacks only get better and the second
one always used the authenticated
encryption so be careful about integrity
what I'm going to show you is now a set
of other lessons that we want to present
and they sort of come from the following
two papers the first one practic
practically exploitable cryptographic
vulnerabilities in Matrix um and of
course I'm sure all of you know Matrix
because it's also the communication me
uh media that we're using for this camp
and the other paper being three lessons
from threa analysis analysis of a secure
messenger and this also comes from our
group
now um one thing that is in common
between these two attack papers is the
fact that they sort of are a complicated
system which comprises of the
interaction of multiple protocols and in
particular it it you have to be very
careful when you're using some
cryptographic material material across
different protocols in particular um if
you have different protocols which use
the same cryptographic material what I'm
saying is that for example you have the
same signing Keys you have the same
encryption keys that you use across
protocols right then you could incur
into some uh some pitfalls and in
particular if you are using the same key
in the same way then it that means that
you could take a message from one
protocol and then use it use it in
another protocol sure then uh what what
does this mean let me make you an
example so we have on the left the soal
pizza protocol and Alice um you know is
talking to to the chef and the chef has
a key and the chef asks would you like
some extra mozzarella and of course
Alice would say yes of course and then
signs that message and encrypts it to
the chef right and uh now Alice has used
her cryptography key to sign this
message and assume now that um there is
another protocol you have the bank
protocol which confirms which asks Alice
to confirm whether she wants to transfer
money and Alice would use the same
signing key for that protocol as well
and uh now you can imagine some scenario
in which this Chef is somewhat
adversarial and the bank and then tries
to go to the bank and says hey I'm Alice
can you send $10 million to
Alice and when Comm when communicating
to Alice then uh says that his key like
the keys of the attacker is not his
actual key but is actually the key of
the bank and now when when Alice replies
to this message she will encrypt it with
the key that was meant for the bank
saying yes of course and then signs the
message very happily saying this is this
is coming from Alice and the attacker
can now just take a message from the
protocol from the pizza protocol and
then use it in the bank protocol and now
Alice has somewhat confirmed that she
wants to send 10 Mill to um to Eve to
the attacker rather uh by using uh by
using the message from from the other
protocol so this is an example of a
cross protocol attack and as egum from
Ghostbuster always says then don't cross
the protocols if I if I remember
correctly something like that um and I'm
going to show you now a couple of
mitigations that you can use uh uh to
protect yourself against the sort of uh
cross protocol interactions and they all
fall within the umbrella term of domain
separation so the first type of domain
separation that I can show you this is
not um these is not all the types that
of domain separation that you can you
can do but I'm going to make a few
example the first one is using key
separation so you have seen that um um
that Mega for example has a interesting
hierarchy of keys and is actually kind
of necessary because we you want to use
each key for a different protocol that
ensures that whenever you are creating a
message for protocol one then it cannot
be decrypted in protocol 2 so again so
instead of using the same key k for two
different protocols right that will be
key reuse you use a key derivation
function for ex for example hkdf the
hmac based key derivation function and
then you derive different keys for each
protocol and here again is from
cryptography iio a couple of lines where
it shows you have the starting key which
is my super secret master key and then
you derive two keys K1 and K2 the
difference here being in the info
argument where you can add some label
saying key Proto one and key Proto two
and this will ensure that theing the the
resulting two keys K1 and K2 are sort of
independent from each other that means
that for example even if K1 is
compromised then K2 will remain
secure okay so this basically means in
the example that we seen just earlier
that assume the attacker can sort of
steal a message from protocol one then
it can not send it into protocol CH
because in the protocol CH the bank will
not accept that message it will not be
able to decrypt it it will be just
garbage here's another type of um of
mitigation that you can use it's called
message separation and this could be
useful for example when you want to use
the same signature key and this is
actually more similar to the attack that
we were were um showing just earlier so
assume that you can use the the same
keys for signing messages from different
protocols what you can do is you can
separate the messages for each protocol
that is for example here we have a
message CCC is awesome and whenever you
sign it you sort of prepend a message um
a prefix that says this message is meant
for protocol one this means that if
somebody from protocol 2 tries to verify
this message then it will sort of see
that this message does not start with
protocol one and hence the verification
will with with very high probability it
will um it will not
verify right so this is the lesson be
careful about cross protocol
interactions this can break a lot of
things and again this this was show this
is shown in the two papers that I that I
said earlier and domain separation sort
of fixes
this and to to actually be more more
expc it in The Matrix protocol there was
a interaction between the m and me
protocol which could basically uh break
confidentiality of messages in in Matrix
and in threa uh we also uh managed to
take take some end to end message so
some message you could send to a friend
and sort of take it from that protocol
and use it to authenticate as the user
so sort of an impersonation
attack now uh I'm going to present for
the next lesson a few uh a few couple
interesting facts about some frequently
used cryptographic Primitives some of
them you might have heard of so one of
them is curve to fa19 which is a special
type of elliptic curve and it's uh it
was created by Daniel Bernstein and it's
actually very used because it's uh it's
actually pretty fast has very compact
keys and um well it seems perfect
however it has an interesting uh
property that I'm going to show you
right now so let's say for example that
you have a protocol and you have you
want to let's say deny somebody that has
a specific public key access to your to
your protocol right you you want to
block it for some reason and U one idea
that you could do is you do something
like this you you take the public key
that is being used and say oh is this
equal to the key that I want to block
and in that case then you will just
reject it otherwise you do the important
stuff actually and you start using that
key um this seems sort of reasonable
this is the uh the immediate way in
which you will probably do it and the
question is does it work and the answer
is actually it doesn't and why does it
not well it doesn't because curve 2519
public Keys have multiple equivalent
representation for the same public key
and so what what it means is that
whenever you are trying to uh to block a
public key you would sort of have to
block all of the possible
representations or in or more in a more
solid way you would try to sort of CSE
the public key into a canonical form in
a sense and then try to block that one
for example and this is relevant again
from the threa paper because um in one
instance we have to claim uh to to the
Ser to the server that R key is a
special key um and then an immediate
mitigation could be oh let's just block
that special key and uh actually it
doesn't work because we have multiple
representations and here's a a nice um
website where explains the mathematics
around the fact that this curve 519 has
eight equivalent representations for the
points and I want to point out in
particular that this is not um uh this
is not true for every uh elliptic curve
only like curve 219 has a so-called
co-actor of eight and some other curves
have Prime order which means that they
don't have this property so uh this is a
specific thing for Cur
519 the next thing that I want to show
you is well assume that you are using an
aad which is good because as it was the
one of the previous Les lessons well
it's not uh it's not that simple either
because there are some pitfalls that
happen with some commonly used aads for
example chasa 20 poo 5 as GCM well many
people would think that if you have a
cipher text then it can only be
correctly decrypted with the with the
correct key and what this and sort of
the the the real uh real thing that we
should say is that if you have a message
you encrypt it with with one key you can
only get the original message if you
have the correct key however decrypting
correctly is sort of a
nuanced kind of term and what we usually
mean is that whenever you have an aad
the Integrity part says everything is
correct you can you can go on with the
with the protocol however it it is not
true that only the original key will
make this Cipher text decrypt correctly
and it can be true that the same Cipher
text decrypts correctly under multiple
keys and in some cases it might give you
garbage but in particular uh there we
can also show that one could Forge a
specific Cipher text that can decrypt to
a meaningful different messages if used
with different Keys pictorially uh
actually this this comes from this very
nice paper which is called me fast
message franking from invisible
salamanders to encrypt read the paper to
understand what this means um so let's
say let's say you take a message that
has been encrypted and well you use the
first key and you get one uh one kind of
message and then you use a different key
then you get a completely different but
still meaningful message and you can do
so uh with with multiple of them and
this is actually pretty interesting
because uh let's say that you have um
and this actually comes up in some group
messaging applications where let's say
that you send an encrypted version of
let's say an image to to an entire group
and then you send the keys to to the
specific people then you could think of
a scenario in which you are sending
different keys to different people and
let's say that I want to pull a prank on
on my on one of my friends that I would
send the keys that the Crypt to a
completely safe image to most of my
friends and then to a specific friend
that I want to uh that that I want to
prank I would send him a specific key
that would I don't know send some some
random maybe disturbing image let's say
um you know and then then you could you
could sort of use it for uh for some uh
evil purposes let's say so in general
what I want to what I want to say about
these two uh previous case studies is
that The Primitives are actually quite
subtle right and you you sort of have to
know them you sort of have to know the
tools that you are actually using
because they have different properties
and some of them can be um
can be actually dangerous for your
protocol so do get to know what your
Primitives provide but especially what
they don't provide for example in the
previous one you are not guaranteed that
you will only that a cyer Tex will DEC
correctly only with the original
key um now the next lesson I want to
want to talk about is about um bridgefy
and the bridgy is a peer-to-peer
messaging application I'm not going to
go into the details but but uh um the
the important point that I want to say
first of all again this this comes from
members of our group is that maybe one
could think oh right so I'm not very
good at developing cryptography so I'm
just going to take a cryptographic
library maybe a cryptographic protocol
entirely and I'm going to slap it on top
of my protocol so that it's secure well
the bridgei cas study tells us that in
reality this is not true and in fact
bridgei had there was a previous paper
that attacked Bridge IFI and now
um there is a this following paper says
that you can still compromise the
confidentiality of private messages by
using a race condition and basically you
s side step the entire the the
guarantees of the library so what it
shows you is that even if you try you
know uh you try to fix everything with
lip signal it is not really that simple
you really have to um be careful even
when you use safe cryptography libraries
and safe cryptographic protocols that
you try to integrate Within your your
product and so the lesson is save
libraries won't save you from
yourself now for the final part of this
talk let's go back to
TLS so this is what we saw before a red
wave of attacks that then stops at the
walls of TLS
1.3 how is that
so so so TLS 1.3 is special and one of
the things that makes this special is
formal verification provable security
when TLS 1.3 was published there were
some um formal proofs of its correctness
and of its security and this like
provable security approach will catch
most if not all of the goas that we
presented before so like if you have
lack of key committing or lack of
authenticated encryption or key reuse
because key are not separated then
provable Security will catch this for
you and we are slowly moving in this
direction of having all of our important
protocols proven secure
formally so signal has multiple analysis
of security so do War guard metrics and
as of a few weeks ago treas ibec ic's
forward security
protocol what else makes TLS 1.3
different think it would be unfair to
say that it's just a matter of proving
it secure proval security alone is not
enough TLS actually had a proactive
standardization process where multiple
drafts were presented to a working group
before TLS when was even made public and
cryptographer had time to work through
this grafts and find attacks well above
time it is also accompanied with a lot
of formally verifiable implementation
and being such a big and important
protocol it took years of research time
to analyze it to make a formal
specification uh to find all the attacks
well before it was published in
2018
all of this is a luxury that most of us
like common protocol developers cannot
afford we don't have enough money or
enough time to do all of this every time
we want to write a cryptographic
protocol but we can start with less for
instance just with formally verifying
our um cryptography trying to come up
with a proof or commissioning a
proof um and also by being careful not
to fall in the common gotas some of
which we presented here so keep up to
date with the last cryptographic Trends
if you're doing
crypto we add like this Mantra in
cryptography don't roll your own crypto
this was referring mainly to don't roll
your own cryptographic Primitives
because people when people were trying
to make their own box ciphers there were
a lot of problems and we actually
nowadays see the benefits of this people
mostly have stopped rolling their crypto
nobody uses their own block Cipher
everybody uses as or standardized
elliptic curves standardized
aad should should this become don't roll
your own protocol because we as we just
seen even if you have secure Primitives
and you combine them together in the
wrong way the overall construction may
not be secure at
all and the answer is yes and no like if
we don't roll our own protocols if you
don't roll your own protocols then who
should only a bunch of academics or big
committees that have time and resources
sufficient to spend like years analyzing
the protocols before are published and I
really do want to leave you with this
question and here of course about all of
your question but also about your
opinions on who and
how uh cryptography should be
developed so thank you for listening I
will leave you with the meme and wait
for your
questions thank you very much we do have
about four minutes left for questions
until we need to close down the talk so
if you have any questions please line up
in the middle by this near this nice
Angel and we have the first question so
go
on test test test yeah going back to the
key overwriting attack I was wondering
if you can only have one bit of
information either that decrypts to a
correct key or doesn't how can you get
more out of it obviously I'm missing
something so uh it depends a lot on
which key which uh protocol you're
attacking so you could only get one key
like usually the output is either an
error message or decryption successful
so like this is by itself one bit of
information zero and one how you get
more it could be that like each bit of
information that you get is a ceve so
like you're actually doing uh um uh like
split and search so you can do this in
logarithmic time or it could be that you
only need to recover part of the key and
then for the rest you you run like a uh
exhaustive uh attack or um some latis
attack okay I think we have time for one
more hello so um yeah I have a question
about the mega attack on their
encryption so the password the key is
derived from the password but how does
the login process work because if I
remember correctly with most password
hashing uh Solutions that's do the key
server side you need to send the pl text
login password over there so they could
theoretically use that to derive it
themselves um so if I remember correctly
I don't know for sure but the most
reasonable way to do this would be take
your passphrase use it to derive one
cryptographic key and then derive two
keys from this main key one you send to
the server and the other use for
encryption so even if the server knows
this key it cannot walk back through
like the kfs are not invertible so they
still cannot know your your main
Ash okay thank you very much and if
there are any more questions I'm sure
Ken Mato will be available afterwards so
please give a warm Round of Applause for
this great
[Applause]
[Music]
talk