Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/609 Thanks!
It's actually nice to encrypt your data,
as you may probably know, and it's even
nicer if you can store it online, but
the only drawback is that you
that the cloud storage provider that
actually can't do such operations
on the encrypted data, the next
talk actually presents some solutions
to this problem.
There'll be a smaller and Christian
follow present, different
approaches, how others can search
through encrypted data without
actually knowing the
the key nor the plain text.
So please welcome warmly Christian
Falo and Tobias Malow.
Perfect. Thank you very much and thanks
for being here at day four after
like these many parties and having party
hard and I'm surprised to see so many
people here. And by that, I mean, I'm
surprised that I can actually see so many
people after yesterday's tonight.
And I'm I'm glad that I've made it
up here and this very morning.
That's correct.
We are concerned with the problem
of encrypting data in such a
way that you can still
search over these ciphertext.
And over the course of this talk,
we will present some well schemes
or solution to that problem, which
will hopefully inspire
inspire you to firstly
demand these services from your
cloud provider.
And secondly, if you're inclined to
to do the programing, then to hack
on these schemes and implement them and
make them practical.
So I'm Toby, this Christian in
the course of the next forty five
minutes. Well, we'll talk about this and
hopefully we'll we'll leave some room for
Q&A. We also intend to before I
forget that we intend to hang
around at the bar just outside this
lecture hall after this talk
in case you want to chat about these
techniques or encryption or just buy us a
beer.
Well, maybe not the 12, but later.
So this is our agenda.
We want to talk a little bit about
how we see the current world
or the world around the cloud is
organized and where your
position as the customer is and that
architecture.
Then then we present a couple
of schemes which allow you to
well perform searching over,
well, your ciphertext, which you have
uploaded to the cloud.
And then we'll we'll wrap up.
So.
Let's talk a little bit about
the cloud, so
let me ask you, how many of you
use the cloud, any external
third party provider to upload?
Well, data, whatever it is.
That's many and probably
the majority, and
that's how we actually imagine
this world right now to be
that many people use external third
party services to upload
to hold their data.
Yeah, well, for the customers to
avail of this data, well, at any point
in time with any device they have.
So I for myself,
I went with Stan, a trustworthy guy.
I can upload my data the first
a couple of gigabytes for free.
And he promises me well, if
he promises me that I can at
any point in time download and access my
data and
well, there's many of those rights must
not be him. There's so many companies
offering cloud services
and they not only allow you to store
your files, you can also upload
your contacts or your calendars, your
messages, your files
and all of them
probably promise you that they will
not be malicious or do not
go through your data and run analysis
or even tell your user profile.
Except a couple of providers
actually do so.
And they do tell you straight in your
face that they will mine your data to
present you, for example, better ads.
So they go through your email,
they look at your keywords and they will
determine what ads might
be best for you once you know what you
are most inclined to click at.
So anything
you can say, well, I'm paying money,
right, I'm using this premium provider
for my email, my calendars, my my data,
so they have their incentive
to cheat on me is not that big.
Well, you might be right, except,
you know, if they could make an extra
profit, they might possibly do so.
And also, we don't we are being
cryptographers.
We don't necessarily want the guarantee
that they don't look through your data
on a piece of paper.
We want to have, well, a rather
mathematical say guarantee or proof
or we want want
the provider to not be actually able
technically to go through the data.
Not only, well, the privacy statement
from this provider should guarantee
that they don't look through the data.
So we are looking for a cryptographic
solutions to that problem of,
well, uploading a data, but
still
still enable you to execute
operations on that encrypted data.
So the problem, as I've said, is
that these providers
go through the data and they extract
information about you, about your usage,
about your behavior.
And it turns out that mining plaintext
data is actually not that hard.
So the data mining being performed
is, well, relatively
easy because it's plain text and you can
just, you know, run your analysis over
the plaintext.
And we think that we are on
the wrong track.
We think we
as a community, as the cryptographic
or the hacker community should actively
work towards the goal
of providers not being able
to look through your data and
to not well create profiles about
you and to not be able to predict what
you're doing next.
So we will hopefully.
Well, thank you.
So we ask the question, why, you know,
Interex, why do you not, you
know, do put on encryption
on your data before you upload it
because the encryption will save
you or will save us from the dark side,
you know, which performs all this
analysis?
In our scenario that we
have in mind right now, when when
presenting these slides, in
our scenario, the USA
has some data like locally.
Right. And the user uploads
their data to a third party
and then forgets about the data locally
because, you know, you have uploaded your
massive movie library and then you're
going with your mobile online
and you don't know you don't necessarily
know about the full
well, the full data that you have online.
Yet at a later point in time, you want
to perform search, right?
You want to know which files by half,
which contacts you? I have without having
necessarily seen that data previously
on that device that you want to access
your data with an.
What we will do is we will present
certain schemes that allow that,
allow you to perform these operations,
but these well schemes
or these technologies are not necessarily
plug and play. Right.
It's not that you could drop in,
say, the scheme, and then you're done.
You need to, you know,
say manage keys and look
at the rough edges off of cryptographic
schemes in the science track, by the way.
Right. So we are taking academic
work and we're trying to make it
practical and academic work.
Well, sometimes it's
complicated, say, to apply for real life.
So just keep that in mind.
When when listening to these.
To these.
Um.
Yes, we as I said, we are
trying to point you in
a direction of trying to give you some
inspiration as to what
to look for when, well, either
implementing encrypted
search or when demanding encrypted search
from your cloud provider.
So let me start by a very
simple scheme, a
very simple encryption scheme that allows
you to perform an encrypted
search as an engineer, I'm
trying to think about the most
minimal solution, the most easy solution
first and then try to build it up to make
it better and better.
So my engineering approach
to that very simple encryption scheme
is to just simply encrypt all the things.
Sounds simple, right? It actually is
in the scheme. We have our plaintext data
and we simply encrypt each and every
entry of our database
with a secure encryption scheme.
And we upload that data to
the to the third party.
The right word on any any questions.
So in a way, when you want to perform
your operation, what you need to do is,
well, you need to download all the things
right. So you need to
ask the database on the Internet,
on the couch to give you all the entries.
Then you need to decrypt locally and
then you have the plain text and then
you can perform whatever operation you
want.
In this scheme, well, it's very simple,
right? It's probably not
what we want.
Why? Because, well, if you're on your
mobile, you don't want to to download
your three terabyte movies library first
to find the file.
And so this is not necessarily,
well, a good scheme for us.
So we are trying to build up
wealth solutions which perform
better in that regard.
However, I just want to point out that
this, as far as I'm aware, is being
implemented in commercial products
that you could buy. So as far as I'm
aware, proxy products that,
you know, sell as
an appliance that you put between you and
Gmail, as far as I'm aware,
they will do exactly that.
So the question now,
as soon as the engineer that I am
is can we do better?
And that question I asked Christian,
Christian, can we do better?
Yes, we can do better.
Yes we can. Sure we can.
Yeah, let's do it.
OK, we one that
the cloud, uh,
performs the search for us, because
this looks like cloud service and
I'm not willing to perform the thoughts
on my computer, especially
when I have big data stuff on the cloud.
And, um, slutting unencrypted
data sounds a little bit like magic.
But in fact, it's so simple.
Yeah, I soever like scheme
of a simple scheme, how to perform
a search on the
data and figure out
just by using a deterministic encryption
scheme.
OK, that's an interesting direction,
means same plaintext,
same ciphertext, so we have two identical
plaintext, then we will have
two identical ciphertext
super easy.
We can use such a scheme, a space
to encrypt all our keywords
one by one, and then we have
a ciphertext collection.
OK, that's fine.
And now, uh, now,
uh, it's, uh, it's not working, uh,
it's broken or maybe it's
not that.
Oh, well,
hang on.
So shall I go through
this again to anybody?
Did anybody not understand anything so.
Sorry about that.
We are.
Here, right?
Oh, that's wrong.
It's not just here.
OK, sorry about that.
I'm fed up with crypto, with computers.
OK, I will.
OK, that's a two button interface right
there.
Yes.
Hey, it's a
oh, we should have practiced that
beforehand. Yeah, yeah.
I don't think this computer thing will
ever, you know, we're going to succeed if
it's too complicated,
right.
Yeah.
Well, OK.
Oh yeah. I've received a crash report.
All right. That's that's handy.
Oh yeah.
Please stop off on the hacks right now.
Uh, OK, that's horrible.
But you're going to do it anyway.
Let's get the slide, you
don't press the button. OK, OK,
maybe I press the button just.
Oh.
Isiah's.
Next, the next
right.
It's easy to say, but a
crash crashes on that very flight, the
terrible.
OK, can you tell a joke?
Let me just have this finishing the pre
rendering.
Now, it's not that we would have never,
you know, gone through the slides with
that very program and of course, a random
problem right now.
OK.
Oh, there you go. OK, now it's.
I'm not skipping through this, like I'm
opening it directly.
No, I'm not.
OK, I have a backup plan.
Don't don't worry, it's all
right because, uh, as an
OK from.
Now we are
listening to the latest source would
probably be better in your ear right
now. Yeah.
Finally, OK,
that's amnesty and corruption once again,
if same train, same plaintext,
I same ciphertext.
So it's quite easy to search for farmers
much on the other side,
trust and crypto keywords they're looking
for.
And then for each ciphertext, the
collection, uh,
you just check if if
it's a match or not and when there's a
match, it's fine.
The then the keeper is part of
the ciphertext collection.
That's why this is this is
indeed two is a little bit too easy.
Uh, OK, let's try it one more time.
Uh huh.
So it's OK, there must be
a catch. Yeah, I understand
it's a serious problem because
that having this description, it's not
really secure.
You cannot consider this as secure
because you all know the, uh, example
of the pinguin. Yeah.
I mean, it's just the form
that exists.
And it's only
partially, uh, hides the plain
text.
And so we
can we do better.
Yeah. Because this is not what we want.
Uh, at the end, we want
to hide our data.
And do it well, very well.
OK, and now there is some
idea from Song by The
Pretenders that 2001
and it's quite it's worked like a charm
you just use.
The missing persons scheme and
then, you know, OK, the is not releasing,
you will have to fix something and
there is a fix in step.
And what we do is just we we
all mask. Mask means a random bit thing.
Yeah. If I tough.
A random thing and have something like a
one time pet, and we all know one time
pet works like a charm, it's secure,
you're OK if you
don't read the math, are using a
streamside, whatever.
It's not a big problem.
OK, but then again,
we have the problem when if
it's Q and corruption, how we can,
uh, perform a search on
the encrypted data.
OK, and this is about the point where we
lose to the audience.
Right. So are we, uh, using
the audience?
We're losing the audience because now
it's getting complicated.
Yeah, OK, OK.
But we have this means now we
have some magic.
Yeah. And we cannot use any mask
at all. We need a magic mask
to perform this kind
of encryption.
OK, and and
OK, let's let's see how we can craft
such a mask, OK, we
divide the mask in the left side and the
right side and the left
side. We are using random bits.
Yeah, we can generate a friend of bits
once again by using a
stream cipher. Yeah, a boring string
cipher, but boring and secure
screensaver.
No big deal.
Then we performed the deterministic
encryption on our keyboards.
And then we divide this keywords in the
left part and the right part,
and from the left part, we derive
a Slutsky QEI
and we can do this by
using a key hash function.
So you can keep hash functions.
One can use H.M.S..
Yeah, you only know the max you can
perform here.
You trust your hash for left part
of our search query using each Mac
and then we have our Slutsky.
Yeah. And then with the left side
of our mosque and the Slutsky
we craft the right side of
Omarska. You drive the right side and the
right side, the left side
of our markets as I and the right like
to see. And that was the trick is from
the other deterministic encryption from
our internal ciphertext and the left side
of the mask, we can compute the right
side of the mask.
And this is Hendee,
OK? And now we we exploit
this to perform,
uh, such encrypted data.
Yeah, the basic idea, once again,
we can compute the right side of Omarska
on the left side.
This is the basic idea, and now
let's watch your fellow magic mask.
Let's do the magic.
Uh, OK, first of all,
we have to upload our stuff, we
each.
It's plain text.
We have to first form the encryption
then.
We have to explore
the result with our magic mask.
And then be uploaded to the cloud, to
a server.
So far, so good.
And now the metrics
that we want to search at some point of
time involve a former search
query and then this means
for such a search
query consists of the deterministic
encryption of our keywords
and the Slutsky Soviet era
each time when we perform.
Such query, we upload the
interim ciphertext and
the Slutsky, OK, and then
the cloud can test
for each other and
ciphertext from our ciphertext collection
if the X or if our
deterministic ciphertext ISMAT
is the magic mask, and if so,
if this turns out to be a magic mask,
we haven't hit a match.
And then we can figure out if some if
this is part of our
of our ciphertext collection or not.
So now this enables us to search of
bankrupt the data.
That's beautiful.
And it's fine
to talk.
It's done.
Uh, not really.
There is a problem.
Every blessing comes curse.
Yeah.
And do we have to curse is
the first curse.
The scheme is not, uh,
super secure. It's vulnerable to
statistical analysis.
What does it mean, OK, if
I know maybe my target, my victim,
it's someone from the Wikipedia
community and the staff
are targets uploading, I'm a victim,
maybe it's connected to Wikipedia.
And then I can make some
estimation about the search pattern.
I can make some guesses, wild guesses.
And this means, I guess, the
frequency.
Offer so much, yeah.
And then here a large
to means high frequency.
And small
size means low frequency that
can make estimation.
And then what next?
I'm gonna tell you, is that behavior?
Yeah.
And this means I'm monitoring the search
current search queries.
Yeah, and then after a while.
I can make a quick compare
my my guess with what I've
monitored and then I
see, oh, this guy looked a lot for, uh,
uh, zero x
nine for, uh,
and on you seven, blah, blah, blah.
Oh, that's a good chance that this,
uh, that you searched for.
This might be the ciphertext
for Mr. cipherText,
for Wikipedia or Foundation one or
foundation or so on.
Yeah. And you and my target
only looked twice for the small
ciphertext, our x uh, the,
uh, eight felines on.
So this, uh, must
be one of a smaller
stuff here on the right side, uh, like,
uh, I've got at least license
or whatever though.
And this is how I can partially
reconstruct the ciphertext.
So, yeah, this is the problem.
If your point is to perform a lot of
search queries, you can
decrypt parts of the ciphertext.
And it just can
become a problem.
OK, and then there is the next
problem, speed,
OK, this is,
uh, symmetric encryption.
It's not so bad then using full
homophily encryption either.
And OK, first
of all, I have I
implemented this stuff and,
uh, this is a fun performance,
benchmarks.
And first of all, you see over ciphertext
is about six times larger than the
plaintext.
What happens?
I patted each worth
to 32 bites before
I interrupted this petting is
crucial because when you
encrypts, uh, natural
language stuff, words,
uh, you can see from the fact that and
then you reveal a lot of information.
Yeah. If you if you if I interrupt.
Uh, yes and no.
And then I look on the for outputting and
looking for the life of Texas.
CipherText of Yes.
Should be longer than the cymatics of
no. And then I ciphertext.
I can learn a lot about language
ciphertext, I can learn a lot
about Blendtec. And this is why I just
patted each word to 32 bytes
and then perform the encryption.
OK, just have OK.
This is a fact that depends on what
you encrypt.
OK. The other thing is, uh, time to
encrypt. OK, this is quite fast because
I used a s and
with the a selective instruction
stuff from insert thoughts quite fast.
And this is only on the stuff,
on a single warmish, on the normal
regular notebook, on the single
core. It's OK
and the such.
Yeah. OK, so that might be a problem
because you need linear time.
Yeah. Eidson any such
query. I have to go to each entry
of my ciphertext collection and check if
it's a match or not.
And when I perform big data
or utilites data you'd say that this
means uh I have to wait
a couple of minutes.
It's quite good if you like to drink
coffee a lot and you can make coffee
breaks. But
this is not what you really want to wait
a couple of minutes before you have to
search results.
What can we do better?
Can we optimize
for such time and then
what we can do, OK, we can look at
what do the guys,
the database guys or the
operating system guys have a lot of data
and they have to touch quick
and they using indexes,
using an index.
And OK, let's use the index,
though, to speed up things.
OK, then once again, you can
hear have the most simple
stuff to have
a plain text index on your client's
device.
Yeah, right. And and then and
the plain text group that using it you
can encrypted the plain text using a
secure encryption scheme, your favorite
secure encryption scheme.
Just encrypt it and upload it to the
cloud. Everything is fine.
And your text is on a local device.
Yeah. Nowadays you have
your smartphone, your tablet,
your notebook, your PC,
your server, your whatsoever,
and five fifty thousand
thoughts and
becomes quite a mess when you
try to synchronize stuff.
The index on site.
And yeah,
some guys know what they're talking
about, it's
not work.
Yeah, OK. Next approach, let's
interrupt the index and upload
it to the server.
OK, you can do it.
It is just encrypted.
Atholl if a secure encryption scheme.
And then on demand,
you can download the index.
Up to date index and can perform your
encryption on the index.
Yeah, well,
then, if you're doing, uh, big
data again, your index
can become a couple of hundred a couple
of hundred megabytes maybe, and
this makes no fun to download at all.
Specially when you are
at the countryside in Germany.
And I have a little something
makes not fun at all.
So.
I want to have my index
now and not in 10
minutes, 20 minutes or whatever,
this is not this is the best
news experience yet.
We've only had four nice suits
experience.
OK, then, to
achieve this, we need a little bit
advanced transcriptase stuff.
OK, here, first of all,
we have to generate a special index
that fits our purpose and
how we can do this, therefore, I mean,
it's such key and
the index key.
And for this example, we want to
generate an index for the last name
of user data.
And we want to hear so much for last
night's.
And then for each last name, which
generate a such key and the index
key.
And then before such Slutsky,
we just let.
Zero.
And that is our slogan, so we
derive from zero and the Slutsky
and the hash function, our
touchstone for and then
with the index key, we just
securely encrypts the raw ideas
in this example, the.
And this works,
so if you want to perform a search.
Uh, uploads for former secretary
by just uploading for such key and the
index key.
For our last name
and then for Cloud can perform a look
up in the index.
And when it gets hit.
It decrypts the index
and send us the results.
Oh, this is quite embarrassing.
OK, there is a problem because
if you have a very common,
uh, last name, like Smith
or Mahala, you will have,
uh, lots
of, uh, well,
you have a lot of hits, a lot of, uh,
values that that fits
a lot of real ideas.
You have a good set of ideas that
that match for Smith,
people with Smith and therefore
the size of the value of for Smith
is larger than the
size of the value for a dollar
because like,
I'm coming, I'm coming him.
So you can if you get access
to this index, you can
from the size of a well, you
can you can try to postulate
to try to estimate the plaintext
last name. I'm just looking at
the value size.
And this is a problem.
Yeah, we have to hide Forsys,
so.
Number of occurrences, the frequency of
a loss of a last name.
Yeah, if not, you have a bad
time because we
that, uh, you want to be able to
lose our, uh, our index
without, uh, get uh, if
we want to give our adversary
the index without becoming
trouble. So, uh, this is the whole idea.
If if if you if
some of our assumption is that the
adversary.
Has never, ever access to the
our index. We don't need to encrypt our
index. Yeah.
OK, so and then we assume
that adversary has access
to our index, and even if it
exists, his index would not reveal any
information about
our plaintext.
Therefore, we have to hide Forsayth.
OK, and and that's
a cool idea from it all from last
year, they've published a paper,
How to Hide Forsys.
And this is the flatten out of the index,
quite cool idea.
OK, therefore, we have to remember
the occurrences of a last name.
OK, it starts here.
And if, uh, if it's the first
straw, you its full
swing, last name for, OK,
let's make an entry for food
and occurrences to zero, this means
the hash Yashiro
and then encrypt the real ID.
You have one.
OK, then next, we have Bob Fu,
same last name, the last
Democrat once before,
so now we have one instead of zero.
OK.
And shareholder value is the liberal
idea.
And then they fire
and then the occurrences so far,
none.
Then again, we just
under the new Slutsky for the.
OK, and then we encrypt the, uh,
the value, the idea and
I was encrypt for each
and any entry index, only one row
ID so that
we are aligned for all this
is always the same.
And this means our adversaries
is not so much anymore if you get access,
just a bunch of random values.
OK, and once
again, how this works in reality,
just you encrypt
your plain text using your favorite
Sawatzki one Guptill scheme.
And upload it.
And then you
read your index.
And upload the index.
OK, and now it's the can
the cloud can now have the capability
to search of an encrypted data,
you once again for its search,
the compute for such key
and for index key, upload it to
the cloud and now the
cloud can make look ups in the
index. First,
we start by making look up for zero.
Yeah, we have it.
OK, then let's try one hit
again. Yeah, let's try to no-hit.
Oh it's over then.
Fower hits three decrypts
the values and sent them
the results to the client.
And and this works
like a charm.
So it's OK,
I once again, I use the same plain text
such as the King James Bible.
So OK, and I use the King
James Bible because a lot of other
researchers are doing it.
And it contains a lot of evil, a lot
of words, about eight hundred
thousand words.
So it's it's quite OK.
And yeah, I,
I didn't care about
the of putting.
I used it as a blob, as a binary blob,
the entire King James Bible.
This is just this is why the ciphertext
is equal length and the plaintext.
Depending on your scenario, you have to
do some padding.
So it's most likely that the ciphertext
is larger than your plaintext.
That's OK.
OK, what are the index sites to see here,
it's OK.
Uh, depending on your,
uh, on your
flying text, you'll
need about, uh, thirty
two bytes for each entry.
Sixteen bytes for
the search target and 65 to encrypt.
The well, the real ID.
And sixty five for its entry.
Might be OK, depending on
your scenario, but the cool thing now
is we can perform so much in in,
uh, Konstantine more or less.
So it's it's I make a lot of
tests and it was
all alfer results I got was,
uh, such and such
crude was less than one millisecond.
Less than one millisecond.
It's, uh, it's quite good.
So it's it's fucking it's
and the speed is fine.
And yeah, so, uh,
this is everything is sunshine and
rainbows and not really,
uh, again, we have the problem with, uh,
statistical analysis.
Because we the
Slutsky and the index key for same
for me. I have multiple queries for the
same last name. So we have so much 20
times for the same last name.
I have 20 times the same search query.
And yeah, OK, I technique's
I get rid of those.
But then the performance of empowerments
performance breakdown then you have
usually wait a
couple of hours or minutes
or ciphertext size explodes.
Yeah. And if you want to make it
practical then yeah.
Until now you have to live
with the statistical analysis.
Maybe we get rid of those and then the
future depends.
OK, and now, uh,
probably concludes the talk and give
outlook what's going on in the future.
Thank you very much, Christian.
So that was fascinating, isn't
it? So the you enable
a third party to execute
a search operation on
encrypted data, although, you know,
you've encrypted the data.
How could anyone possibly execute any
operations, any operation on that
encrypted data?
But it's possible.
And these were just a couple of schemes
that we've presented and which were those
that we've implemented.
And there's many more.
And from what we've
shown you, these schemes
have the problem of the deterministic
search token.
So whenever you query
two times for the same or for
the same keyword, then
you will generate the same token.
And the database or the service
provider might very well
interfere.
What you are searching for based
only on your queries.
Based only on your. On your.
And there's.
Attempts to
or there's other techniques to,
well, deal with the problem,
but making those practical
is a major challenge.
Currently fully morphic encryption has
been, you know, on everyone's mind
for the last couple of years.
And there's massive research efforts
going on right now.
But for now,
you cannot use that because it's
simply too well, too demanding
in terms of performance, computation
or memory.
So this is not an option.
But if you if you happen to have
a few spare cycles, you may very well
enter this area of research and try
to find solutions well
to these problems.
We have seen them that we've implemented
those schemes and there's many more.
And again, if you have a few
spare cycles but rather want to hack
instead of research, then go go
off, read these papers and build
libraries for four encrypted touch,
build libraries so that subscribers
can use these libraries and offer
encrypted services.
Ideally, we'd have a collaborative
effort to demand
encrypted services and to write these
programs, these libraries for third
parties to offer these services, we will
not kick off the new Latson
initiative, but we
will hopefully will inspire some of you
to go into that direction and to make
well, to bring more encryption to
the Internet, to the cloud.
We have seen a couple of schemes,
we have seen the very first
deterministically what encryption scheme.
It's very easy to set up
and you can do that well with low
computational effort on your and machine.
The search, however, does not perform
very well in terms of security.
We have seen a well,
probably better scheme
in that regard.
We can search over
the size of the database because the
server has to, well, go through each and
every entry in the database.
That may or may not be what you want.
If you don't want to have such a scheme,
you may want to look into the actual
scheme.
You can search in basically no time
because you have the index.
And if you saw the index cleverly, then,
well, if you make it a hash table,
something, then you can search an open
one and of one,
however. Well, index,
whenever you have an index, you need to
think about what happens when
you add new entries, when you delete
entries, when you change entries.
So this well, if you are going
the cash all route, then
keep that in mind.
There's so many schemes, as I've said
already, all of them
have different, slightly different
features, so depending on what
you actually want, you can
build a very efficient scheme.
So if you will cut down
on the functionality that you expect from
your from your scheme, then,
well, by doing some clever engineering,
you can cut down on
runtime and memory demands
significantly.
So if you are
about to build a scheme, think about
what your actual requirements
are.
And as I said, many
more, if you research, if you do some
research on the Internet search and
corruption, that term will find you.
Well, quite a few academic papers
on that.
On that topic.
You will also find a couple of libraries.
There's already software implementations
available in.
I haven't evaluated them all, but,
um, well, uh,
some need work, let's put it that way.
So, again, if you have some spare cycles,
go and look at these libraries and
provide patches, make them work, make
them actually built in first place.
That would be good so
that we can have nice things in the
future.
And as we've hopefully
presented, searching of encrypted data
is practical, you can
build your encrypted database, you can
have clients that search over encrypted
data without, well, the server,
the server side learning either the plain
text nor like the key and or what you are
what you are searching for directly.
So whenever
someone or whenever you are in
a discussion about whether such a thing
is possible now, you hopefully know that
this is possible and we should use that.
And with that, we'd like to conclude
and we'd like to thank you very much for
your attention again. Before I forget it,
we will be at the bar in like
at 40 a quarter to
one or whatever it is.
So just right off the top.
Thank you very much.
So let's go over to.
We still have plenty of time left,
please, if you leave the room now, do
so quietly because we want to actually
hear what is what is being asked into
the microphones.
So please do it quietly and take
all the trash with you.
So now let's start
microphone over there, please.
Hi in.
Philip Roth with the very
good paper. The Moral Code of
Cryptography writes in
critique of FHC,
providing strong funding for AVICHAI and
IO provides risk free political cover.
It supports the storyline that cloud
storage and computing is safe.
It helps entrench favored values within
the cryptographic community, speculative
theory centric directions, and it helps
keep harmless academics who could, if
they go to the store, to invest in more
sensitive directions.
So I read this as a critique of that.
This work sucks into good cryptography,
work into an
area where you can actually
do better, work somewhere else.
What are your thoughts on this?
Right. That's a very interesting paper.
By the way, if you have a couple of
well, if you have a couple of hours, you
should go off and read the it's a couple
of weeks old, right?
Like three weeks maybe in
the paper in a in and of itself is
well, as you said, criticizing
the crypto people for being,
well, way off the real world,
essentially. Right. That's that's the
bottom line that I took away and
rightfully the full of my morphic.
Well, for a string of research.
Well, it's complicated in the sense that
it's very, very demanding.
And so and I think
it's perfectly right.
And I think we should focus we as the
community should focus on making real
world things happen and enabling
these techniques that we have, like
for real world usage, for usage
in such a context such that you could
actually upload your content and
still, well, perform your
queries over the encrypted data.
So I sympathize with that paper
like to to the full extent possible to be
I again, I encourage everyone to read
that paper and I hope that we don't fall
into that category of
good crypto if Dejavu
called it. I think I hope this is
becoming boring crypto in the sense that
this is a commodity, that you can use it
just like that.
And everybody read the paper.
Yeah. And oh actually on paper, something
before you forget for completeness sake.
These are the references in case you
want to go off and read these papers
yourself, you will find them anyway.
Uh, is there a question from the
Internet? Yes, I have two questions.
The first one is, can you compare this
scheme with IAMGOLD was private
information retrieval.
Uh, I'm
OK, I'm not a super expert at
this information, which is a
major topic, but
I think that it's just
I think it's just almost practical and I
think the stuff is indeed
practical.
If the index stuff.
Uh, usually
when you have, um, yeah,
when you use this, uh, these
other techniques, you have
problems with this.
If the ciphertext
with the length of a search query of the
indexes are you have problems
with the complexity or
its will, this information
retrieval might not work
as well. In practice, with
data at the fingers will be
there are scaling problems
so far. Smaller stuff might be fine,
but on a large scale, I
think it's it's
very challenging and also
private information retrieval of the
different parties, the private
information retrieval.
You will download something from
the server or the server network without
the server, the Seven Network learning
what you're downloading. This is
different from performing such operations
over encrypted data.
OK, yeah, here
the schemes to present the database
as learning of a service learning which
which rolls off the Y axis.
If you hide this, it will
come with a cost.
It will be costly, and
I don't think that you can implement
it now needs any database and it
will run smoothly.
I think there is a lot of work to
do, but just my
opinion.
Next question on the microphone, please.
Oh, I have a light on me, so
oh.
So one problem that I potentially
see in this and so you mentioned that you
pat each word, have the same length
so that you can analyze the word length.
That's good.
There's one other issue in that.
There's I don't know if you're heard of
the distributional hypothesis, but
basically the colocation
of words within large
sets of text kind of defines the
semantics of the word themselves.
So just by if I get
access to your encrypted data,
looking at how encrypted words occur with
each other and knowing that, OK, this
might be English or even without knowing
the language, potentially, I could kind
of reverse engineer what specific words
might be just by the fact that they occur
together or how often they
use those words again occur
compared to other ones.
So you can kind of cluster them.
And there's a lot of research that's
going on in deep learning on this
word vector modeling basically.
And the thing there is word vector
modeling works, even if you don't look at
the surface form of the word like the
actual letters. So I
don't know if you've gone into this
a lot in your research at all, but it's a
potential vulnerability that if
you encrypt your data word by word, just
the fact that each word is still the same
token makes them vulnerable
to being reverse engineered.
Sort of.
Yeah, you're totally right.
Yeah. This is this is a problem.
But what I want to emphasize once again,
it's much better
than upload to the Blendtec stuff.
So now we upload
plaintext and they come a plain
text from plain text is not challenging
at all.
So even
if you perform that stuff, if
it posts the code
closely and you have to do it,
you have to believe that
they really have to.
Now, you can just look at the data
now then if I ask you to
have do you have to mount a negative
attack? And I think that's.
Yeah, it's, uh, it's
much better than uploading our problems,
OK?
I told you, it's not
maybe not the final not the best
solution, but we
I think we should now shift to
upload and drop the data, even
if you can partially decrypt
it if, uh, if
you perform a lot of amount of stuff
of computation.
Yeah. It still makes it harder to
analyze.
Sure. I think it's super hard
to decrypt all the data
partially. OK, but
it's better than uploading plaintext
here. OK, thanks.
Please come to the front to pick up your
seats. We're having our next question
now in the middle, please.
Hello. Thanks for the talk.
I was quite pleasantly.
I'm interested to see,
uh, this, uh, talk
sponsored by a company was started
by a person from the Chinese National
Army or People's Army.
So kudos to that, that they are
sponsoring such kind of, uh,
research. The question I have is,
uh, the new anti-terror
laws in China, how do they affect
this kind of research?
Basically, you need to either
build in a backdoor or have the keys
sent to China.
So can you in your
working life use this
in a way, or is it
not possible because you need to have
the backdoor built in?
Yes, I don't know.
It's I, I,
I'm not concerned with any of that.
OK, maybe you should look into it.
Is there a question from the Internet?
Yes, I have one more question.
What about contacts like normal service
gives you context and the result or
can consider the context
when doing search.
What what's your approach to this?
Difficult, you mean contact
that in the morning, like the time
maybe, or the place where you are
accruing from that?
No, just the words that are around
the, um,
the thing you're looking for.
So some hits might be
more relevant to the search performed
than others, despite having
the same keyword.
Yeah, once again, yeah, we can
just might be your problem.
Yeah, right.
We have no practical solution
yet, but once again,
it's better like uploading a plain text
file.
I recommend to encrypted Justis
techniques and you will
have got Rothery
the agencies will have a much
harder time than now.
And just looking at the plain text.
Oh, yeah.
Or you can yeah, you can
say, yeah, there is this problem, this
problem, so don't deal with it but
don't deal with it means you upload stuff
in plain text and then you're
the agencies.
The military is superheavy if
you upload plaintext.
Though you make that the top more
difficult issue of to perform
encryption.
Next question at middle middle
aged, please.
Are you aware of any schemes
to also offload the index calculation
to the provider and work on encrypted
data?
Whether we are aware of index schemes
that offload the index calculation,
as I understood your scheme,
that client is doing the index
calculation.
Now, if the index is to be calculated
by the service, that's possible to
make it much easier to create the index
when you know the plaintext.
That's something you thought about
searching, too, in the beginning,
although I'm not aware of a practical
scheme, but
that may be a scheme,
but I'm not aware of any.
I don't think you.
Next question now on this side.
In the middle, please.
Thank you for your great talk.
I was wondering, are there any approaches
to do a little bit more complicated
queries like get all the people
in your database that are older than 30,
for example?
OK. Yeah, it's
the yes, but no, but yes.
Well, I mean, there are schemes, right,
that there are schemes to
well, for example, order
your entry's you know,
you can encrypt in a clever way such that
you could steal all of them by ciphertext
and you would have them ordered.
If you decrypted them, then you would
still have the very same order in plain
text. But
it's difficult because some people
might not necessarily consider that to be
well, as secure as you would like
to be if you make
all the efforts of having really
secure. You have exponential size
in ciphertext. And yeah,
it's not practical.
Oh, yeah, you can
you can make it better
if you sacrifice some
security, but there are
some schemes, but
yeah, I've
yeah, right now, uh, we make
some we have made some
analysis and stuff and test,
but, uh, it's not as
easy as the schemes I
showed you. Yeah.
You can do it, but it's much more tricky
in hurry.
Yeah.
You have to consult a lot of people.
To the teeth, this.
Next question, please, on that side, you
have presented two ways for implementing
index based social
interaction. One with just encrypted
line was encrypted in the text, the one
where you additional hide the length of
the index.
Do you think it's a worthwhile
step to put the additional effort
into the second solution since
each time you're searching, you're
basically disclosing the relationship of
those rows, since you will be
sending like a bunch of search requests.
And if you just search
them one by one, you will also get the
low latency and you get a lot
of additional network overhead.
So is it worth it?
Depends on your needs, I guess.
I mean, the first scenario where you
don't hide the length, you're so
vulnerable against the network stealing
your hard disk or database, because then
you can run the analysis on the size
of the index values.
You don't have that only second scheme
where you hide the length.
So if that's you know of your
concern, then, well, you better
go for the hiding one instead
of the cheaper one thing.
Again, if you if you know your
requirements, you can engineer
your scheme such that it performs very
well.
Do you know how much information this
leaks?
It just totally depends on your takes
on the structure of latex
and also it's a difficult subject
matter to define the leakage,
that state of current discussions
among cryptographers.
What does leakage actually mean?
Thank you.
There is still someone standing
there, please.
Um, yeah, so for the
for the scenario you briefly mentioned,
like I have a three three terabyte
of loaded data and I want to search
it. Um, I
see that it makes a lot of sense to
cooperate with the cloud provider and
make them search.
But I sort of wondering
what the break even is, because if I have
way less data, let's say, I don't
know, just a few gigabytes like many
of us probably have,
it might also make sense to just
compute the index on my site, upload the
index somewhere. I know.
And then downloading just the index,
which is way smaller than my actual
data and then use that.
So have you looked into
at which point of of
the volume of data, um,
does it start to make sense to employ a
solution like that? Because I think that
most people just have a few gigabytes
and for a few gigabytes.
I don't I think it's
faster to just download the index
search and then download the specific
part of the encrypted data I want.
So where to when does it start to pay
off?
Oh, no, we didn't look into
that because we want to
build a cloud service,
that's such a lot of stuff
we're interested in, and
implementing a cloud service that
can perform such Ivankov good data.
Therefore, we have not looked at
the solution.
A little bit out of scope of our
research.
We still have time for one last question,
please go ahead.
Have you ever thought about
organizing all your text before
you encrypt them?
Because, uh, tokenized list doesn't
change so much you can keep it on your
devices would also
defeat, uh, frequency analysis
and encrypted data would be a lot
smaller as well.
Yes, you're right.
We can you can do it this way.
Yeah, well, OK.
Uh.
So as it seems, there are no questions
left. What about the Internet?
No, the Internet is quite so
small, of course, and follow.
Thank you very much for your talk.
Thank you, House.