>>: All right. This is the afternoon session. So our first talk is virtual machine
reset vulnerabilities and hedge cryptography. Our speaker is Tom Ristenpart
from UC San Diego.
>> Tom Ristenpart: Thank you. Can you guys hear me? Okay. So let me just
start off by summarizing what I'm going to be talking about today. So the first
thing is something that's kind of bad. And these are what we're calling virtual
machine reset vulnerabilities. And so the basic problem is that say, yeah, virtual
machine you take a snapshot and now you resume that snapshot on two different
occasions.
Is problem is that as we'll see, software ends up reusing some cryptographic
randomness that's gone captured in this snapshot and this can lead to
catastrophic failures of cryptographic protocols that rely on the randomness.
So this is pretty bad. And then in the second part I'm going to talk about
something that is better, is good, which is what we're calling hedge cryptography.
So we're going to particularly try to address this fragility of the cryptographic
protocols to the reset randomness or to other types of randomness failures. And
so the idea is to provide frameworks and -- for showing that you can take
cryptographic operations like routine operations like encryption and signing and
make them more secure in the face of increasingly worse randomness. And so
we'll get into that kind of in the second half of the talk.
So this is joint work with a bunch of different people. The first part is joint with
Scott Yilek from UCSD. The hedging cryptography is lots of different people,
Mihir Bellare, Zvika Brakerski, Moni Naor, Gil Segev, Hovav Shacham and also
Scott.
So let me start off by recalling a bit about random number generator and what's
going on with it because this is kind of at the core of everything in the talk.
So we all know cryptographic random number generators very important.
Random number generators are very important. And in general in practice they
are kind of implemented in -- loosely in the following way. You have in random
number generation process that is going to measure some hopefully
unpredictable events such as you know, keyboard presses buy user or mouse
movements, maybe network for operating systems interrupts this type of thing.
And then extract from these measurements some hopefully uniform bits that can
then be handed up to some type of application that needs the randomness.
So unfortunately there has been a long academic literature showcasing various
ways in which this type of process has failed us. And so I won't talk about all of
them, I can just remind for example of a particular example that's well known,
Debian OpenSSL problem that occurred relatively recently in 2008, I guess, the
middle of 2008, where some developer commits out couple lines of code in the
source for Debian OpenSSL, and these two lines of code are actually what were
responsible for adding entropy from the measurements to the entropy pool.
So the effect was that the random number generator was just spitting out one or
a very limited set of possible outputs, and so these were predictable to
adversaries.
And so in general, there's been -- we're showing that failures can really occur at
many different levels of this process and perhaps this explains in part why there's
been so many failures and leading to things like predictable randomness or
exposed randomness and, as we'll see in the next bunch of slides, repeated
randomness as well.
So to set a context for this virtual machine reset vulnerability, we're going to think
of the follow type of usage scenario. So, you have a home user who has -wants to do more secure browsing and so they turn to [inaudible] like VMWare
who are advertising if you use virtual machines you can have more secure
browsing sessions. Basically the idea is the isolation guarantees that the virtual
machine manager are going the ensure that say if you get infected with a virus or
something, the -- this won't get -- escape out from the virtual machine and infect
the whole system.
And so snapshots can actually help facility this because of the following thing,
which I'll just show now. So the video is you have a home user and he has his
virtual machine that he can set up. Say he's running Windows or something
inside of it. Say he loads up his Internet browser because this is what he's going
to use this virtual machine for. And so at this point he takes a snapshot. So the
snapshot basically is a copy of the entire state of the virtual machine, including all
of the act, memory, storage, everything. Okay. And so now when he wants to
do browsing sessions he can resume from the snapshot, go surf to one of his
favorite sites for getting some free software.
And in case he made a poor choice of where to visit he gets, you know, exploited
by some type of malicious, you know, code, the virtual machine, you know, ends
up getting compromised, but the nice thing is he can reset to the prior clean state
of the snapshot to remove all this malware and infection.
So this is pretty nice. It does actually provide some really improved security in
the face of these type of you know malware attacks. But there's been a lot of
folklore regarding the fact that these type of resets might cause security issues.
And particular for example Garfinkel and Rosenblum pointed out that
hypothetically of course you could be replaying some type of security critical
state that was saved in the snapshot. If you use it multiple times, this could
cause problems.
And so I'm just going to refer to this as a reset vulnerability. So this exists when
multiple uses of the same VM snapshot leads to some type of security violation.
So even though this has been a folklore problem no one had really knew or
pointed out whether these actually exist in practice. And so that was the first
contribution in this work that we showed that these types of resets could lead to
random number generator failures.
So now consideration a situation where do you your first browsing session, okay,
and you actually want to go to a secure website like your bank. So what's going
to happen is you're going to use a TLS, key transport protocol and, excuse me,
and kind of at a high level what happens is the client here picks a key using its
random number generator and sends this key over to the server. And that's used
to bootstrap the secure session.
Okay. But the problem is that the next time you resume from the snapshot and
go to use TLS to browse some other website, the problem is that the same
session, the same key gets chosen in this as well and sent over to the next site.
And so this of course can be a problem because this is actually all the secret
material that's needed to decrypt a transcript of the prior banking session.
So if -- you know, if this other side was malicious, this is a big problem.
So this wasn't just an abstract problem, but we showed that by checking out
experimentally with Firefox and chrome, they actually allow this type of problem
in current versions, you know, under a couple different virtual machine
managers, VM or server and VirtualBox. And so underneath the hood what's
happening here is that the browser generates some randomness that got
captured in the snapshot and used multiple times to generate these session
keys.
So we went on to look at another settings where this might be a problem, so we
wanted to look at the other side of TLS sessions and look at servers. And so we
used at Apache mod SSL when is the most popular server software for TLS.
And here wee looked at it in a particular mode where you're using the DSA
signing algorithm for authentication of the server. And the -- we're able to show
that what happens is if you resume the server twice from the same snapshot,
with the daemon running and an [inaudible] is able to get the first few
connections to the server after this resumption then you can actually extract the
DSA server key. And so of course this is bad because this, you know, allows
impersonating the server and all sorts of problems. So this might -- yeah. Sorry,
go ahead?
>>: So I'm just writing to make sure I understand your model. So in your model
when you -- when you said you assume that random number generator is a
generalistic from now on or ->> Tom Ristenpart: We're not assuming anything. This is Apache software
that's been downloaded from the Internet. So I'm going to -- sorry. Go ahead.
>>: Well [inaudible] I guess I'm trying to see, are you -- because you're saying
there is this randomness and so here you're not assuming randomness. There's
a problem with DSA or a problem about randomness?
>> Tom Ristenpart: In this case, this problem is randomness being repeated with
DSA. And I'll go into some more details.
The problem with the signing algorithm itself is that if you -- and this is well
known, you can -- I kind of worked out pen and paper, then realized you can just
check Wikipedia for this. But with DSA, if you sign two different messages with
the same randomness and you give some adversary the public key, the two
mens and the signatures, they can just extract the secret key. And that's just the
properties of DSA. It's very fragile to randomness abuse.
Okay. So how is this actually coming up inside of Apache? Well, easiest way to
explain maybe is kind of a logical timeline of events. So first the administrator
launches this Apache daemon inside of the virtual machine. At this point,
Apache software actually forks off a bunch of child processes that are going to be
used to handle individual connections.
At this point, the children processes have their random number generators
initialized, so they take some initial randomness from dev random or some other
source.
Okay. So now daemon is running and we can take a snapshot and resume later
from it. Next thing is that you get an HTTPS request handled. So say the first
request that comes in. And this gets assigned to one of the children processes.
And so actually at this point the Apache does something smart or seems smart,
which is to update now the sources for the random number generator with the
current time, the child process ID which is unique to the child process. And
actually a portion of the runtime stack of the processor. Grabbing a bunch of
stuff out of memory and sticking it in source.
And then at this point the randomness is taken from the random number
generator and used with the DSA signing algorithm.
So this actually seemed problematic from the point of view of actually getting an
attack to work. In particular, the VM image we looked at synchronized their
guess time with the Internet so, you know, if you're running from two different VM
snapshots but they're not at the same time, obviously one's after the other, then
this would give you different randomness from the RNG process.
So but when we took a closer look and then played around with these
experiments we actually realized that what happened is, at least with the virtual
machine managers that we looked at, was that the guest networking would go up
before synchronization would occur. And so this actually left a window of
opportunity to sneak in connection requests by an attacker to try to get two
connections that used the same randomness to do the signing.
So we did some experiments. And this is basically reporting on kind of the very
simple setup where we had a snapshot running on a server and then we would
start resuming this snapshot. And then on another computer we would have a
TLS client just try and rush connections -- or not even rush, just connect serially
to the -- to the Apache server. And at some point the guest -- the Apache
networking would go up and a connection request would go through, and so we
were basically trying to get the first one.
And then we would do this many times, so we would repeat five different times I
guess doing this, resuming from the snapshot and running connections. Then
we would look for repeat randomness across pairs of these trials. And so the -yeah. Sorry. Go ahead.
>>: I can't remember. For DSA can you actually take this by casually inspecting
the signature that randomness ->> Tom Ristenpart: Yes. That's exactly what we're doing, yes. So the
randomness is like the first component of the signature, so you can just look to
see if you were successful. Yeah.
And so, yeah, the right column is the most relevant thing. And, you know, so
VirtualBox, which had very consistent timing, so basically the amount of time
from when snapshot would go up to when networking would go up is always the
same in each of these, and then you would get the same randomness out. And
VMWare was a little bit less so. But still had problems.
So this kind of brings up some questions about well what do we do, you know,
about random number generators in virtualized world? What type of problems
were going on here? So we had this initial issue with the browsers. This is a
problem that, you know, kind of slowly was happening in application space that
Firefox or Chrome was caching randomness that it was getting and this was
getting captured in a snapshot. This issue with Apache which is some type of
combination of problems, right, it was -- you know, it was trying to reset its
random number generator with new sources but those sources, at least the ones
that were taken after the snapshot, when a child -- when a request came into a
child weren't sufficiently different between runs. So you didn't have enough
differentiation. You still had a high probability of getting the same randomness
out.
And then, you know, there's actually further problems that we didn't actually
completely explore yet.
>>: So in cases you looked at, there's an RNG that's in [inaudible] that's its
[inaudible] binary [inaudible] not calling the system call? I mean, you said that in
both Apache's case and [inaudible] dev random or dev D random or whatever.
>> Tom Ristenpart: Right.
>>: But there's an entropy pool in the application itself?
>> Tom Ristenpart: Sure. So this is -- this is a -- you know, maybe a bit
misleading. I'm not trying to say the RNG process here. What I'm showing is
necessarily the operating systems random number generator. Now, if Apache
had actually gone to dev random afterwards, then the -- it's not clear whether
they would have gotten good randomness or not. And this is actually what my
next point was going to be.
But you're right, the fact is a lot of applications kind of have their own random
number generators internally and they're in process and they're kind of doing
their own thing, which is much more the situation I guess with Firefox is very
clear they're kind of, you know, maybe they had initially gotten a good thing put
then after good randomness from dev random but after that they're just doing
their own thing in process space for a variety of reasons.
But the fact is even if they were always going to the operating system random
number generator like dev random, dev random gets rolled back during these
resets as well. And so while we didn't -- we haven't explored it fully, it's
hypothetically the case that you might have not enough difference in the sources
going into deaf random in between a snapshot resumption and when you need
randomness from dev random to cause differentiation.
>>: [inaudible] snapshot basically of all the [inaudible].
>> Tom Ristenpart: I'm sorry. Say that again.
>>: Unless you take steps when you make the snapshot ->> Tom Ristenpart: Right. So if you modify how the operating system deals with
snapshots, that would be good, but right now currently, at least in some virtual
machine manager situations they don't actually know that there's a snapshot
being taken at all so. The operating system is ignorant of when snapshots occur.
And of course there's this other concern with random number generators in
virtualized settings that, you know, maybe the source events aren't even as good
for software based random number generators as you would hope for. And
again, this is kind of a lurking issue that we didn't really explore fully either.
So I get asked if -- you know, aren't there easy fixes to this, right, can't we just
build a good virtual machine managing -- a good hypervisor based RNG, so
backup dev random with something the hypervisor knows about. Maybe we
could use something like the next generation Intel chips that have random
number generation instruction built in, so you can just call one instruction, get
randomness from the chip.
So this would be, you know, helpful to have such a solid design, but unfortunately
it's not going to fix some of these problems. Right? First, it's not going to fix
problems that occur in the -- in the application layer. Because even if you have a
good operating system/hypervisor based RNG, if the operation is caching things,
you're still toasted.
Now, it should help potentially fix these other times of problems like with dev
random being bad or if Apache had been configured to go to the operating
system on every connection request. And it -- you know, it should fix this.
But it's unclear how to exactly design this. It's a nice interesting question. And
furthermore, it's not going to fix all the problems, unfortunately. Yeah?
>>: [inaudible] here between the time [inaudible] and even if you use an RNG
instruction [inaudible] and then get snapshot ->> Tom Ristenpart: Right. So, yeah. I've kind of glossed over that. So there is
this kind of race condition like element to this. You know, actually initial versions
of this paper we talked about like time of sampling to time of use problems, right?
Because you can never really achieve atomicity, at least in theory, with
snapshots. They can happen in arbitrary instruction sets, then, yeah, you're
absolutely right.
So hypothetically, yeah, you're never going to be able to solve this problem. But
I think from a practical point of view, it's less likely. So it's not a sure solution, but
we should -- because like so, for example, if you think about when TLS
connection requests come in, and if you do the sampling then, it's much less -it's not the fact that you're going to have a TLS connection that the -- was
initialized before a snapshot was taken and continued afterwards in the type of
application scenarios I'm envisioning right now.
Now, in the future that may not be true. You could keep a TLS connection going,
you know, through some type of not or replication of a VM. But, yeah, it's -- I
mean, basically this slide is not pointing out solutions, this is pointing out this is a
can of worms that needs to be investigated much further, I think, for a variety of
reasons.
So if there aren't any more questions, I'm going to kind of now take a sharp right
turn maybe in some sense and try and treat this -- another question that this
previous work kind of races which is why is our cryptographic primitive -- why are
characteristic primitives so ridiculously fragile to this repeated randomness use?
Yeah?
>>: I'm just curious ->> Tom Ristenpart: Yes, absolutely.
>>: I guess a [inaudible] solution would be essentially, you know, again as would
be more or less [inaudible] random function or something like that and whenever,
you know, you need fresh randomness you just take the current state of your
applications, like [inaudible] and essentially, I mean more efficiently but there are
[inaudible] so essentially -- so even there is a set attack, there is a set attack,
now you do something different.
>> Tom Ristenpart: Yeah, yeah, so.
>>: [inaudible].
>> Tom Ristenpart: You're right.
>>: [inaudible].
>>: [inaudible].
>>: [inaudible] everything is the same but then resume if you do something else
->> Tom Ristenpart: Yeah, yeah. So you're foreshadowing some of the rest of
this talk, right. At the end of the day what we're going to say is look, we should
be changing the cryptographic primitives so that they handle this failure case for
the randomness. And so we'll build into the crypto primitives what's going on.
Yeah. But the folklore solution is very close to what we were suggesting for
practical solutions, yes.
>>: Just the [inaudible] and also [inaudible].
>> Tom Ristenpart: Right.
>>: [inaudible].
>> Tom Ristenpart: Right.
>>: Because sometimes you wouldn't want to have randomness that you
wouldn't want to repeat, you wouldn't want to force randomness on the
application.
>> Tom Ristenpart: Right.
>>: Because for debugging, all sorts of reasons you know [inaudible] you
wouldn't want to be able to redo the original randomness.
>> Tom Ristenpart: Yeah. I think in general we're trying to stress this idea that if
you make algorithmic changes to the crypto operators we can reason about them
or we can clarify what you're getting out of the changes in terms of the varies
randomness failure models. And so that's what the rest of this talk is going to be
about.
I just want to stress, in case it wasn't apparent that the type of attacks we're
talking about on some of the other attacks on random number generation failures
aren't abusing bad randomness during like long-lived key generation, right? So
the DSA key was generated with good randomness and it was fine.
And really these -- this is just a problem with the routine operations and the
randomness needed for things like signing or key exchange or public key
encryption. Okay?
So, you know, this is not just a problem with DSA or the key exchange, key
transport mechanism. But, you know, lots of cryptographic algorithms have
problems, right, as soon as you take away the good randomness.
And that's, you know, in part because we've been building cryptographic
primitives under the assumption that we have good randomness around and it's
plentiful.
And maybe kind of more philosophical even that, you know, for many of our
standard security goals, you know, you need good randomness to achieve them,
and provably so. And we'll see an example of this in a minute.
So, anyway, the idea is right now we want to, you know, fix this. Right now we
have problems when randomness gets bad. So it's like repetition randomness.
You have VM resets, you have even situation where you have predictable
randomness like the Debian situation. And so we're saying, okay, let's try and fix
this. And at least try and make our routine cryptographic operations, the ones
that use randomness to do things like signing, key exchange, to be as secure as
possible in the face of bad randomness.
And unfortunately we're -- yeah?
>>: [inaudible] randomness is different than repeated randomness.
>> Tom Ristenpart: Yeah. I'm being rather loose with terminology here. But
when I say bad, I really mean any lower quality than perfectly uniform. And then
repeat and predictable trying to clarify for particular things. I'm not going to go
into too much detail in the models and stuff anyway.
But, yeah, bad really means anything except good, and good is defined as
something that's fresh and uniform and private and never exposed.
And so the idea is that, okay, we may not actually be able to achieve our
strongest notions of security without good randomness, but that's okay, we won't
just give up, and we'll try to define notions and meet them that still provide some
meaningful level of security, should the randomness be not as good as we were
hoping for.
Okay. So I'll go through an example of this with public key encryption which is
kind of something easy to deal with and has very interesting definitional issues
actually when it comes to looking at models with degraded randomness. So just
to drive the point home, we have a very simple public encryption scheme right
like using hybrid encryption with in this case counter-mode encryption. And of
course this is well known to be secure under semantic securities, IDCPA, but
when the randomness is bad for repeat randomness in this case, you can learn
quite a bit about messages just from two ciphertexts, right?
So if you use the same randomness twice, you end up using the same AS
application and you get the same pad, and you can learn the XOR of two
messages, for example.
If the randomness is totally predictable, of course you can just recover the
message immediately, right, where here, yeah, R is the set of potential
randomness values. Okay. So this is no good. So what's going on, okay, of
course, you know, this is probably clear to everybody but to most people but to
go through quickly anyway. So we have our traditional public key encryption
notion which is semantic security. And so what happens here is you have a
challenging environment and an adversary which is some arbitrary program. So
the challenging environment picks the random bit B, and the adversary gets to
challenge two different messages. And what happens now is that the
environment is going to sample R uniformly at random and encrypt one of the
two messages based on this challenge bit under the public key and give back the
ciphertext. Now, the adversary tries to guess the bit and wins.
So this -- so as I said this previous scheme of course is secure under the notion.
So what's the catch? Of course the catch is that the -- in the model we've built in
the assumption that the randomness is always good, okay? And so we'd like to
remove this assumption or we're going to have to remove this assumption any
model that's going to provide something for us to analyze public key encryption
when the randomness is no good.
So we in this paper at Asiacrypt last year the variety of great coauthors, we send
this idea of chosen-distrubution attacks. And so it actually extends on quite a bit
of previous work in the context of deterministic public key encryptions and natural
parallels which are in turn based on some previous work on entropic. And let me
just give you a sense of what the definition is.
So again we have a challenging environment and an adversary. And again we're
going to choose a random bit B. And now at this point, rather than querying two
different messages, the adversary is going to query an algorithm basically or
what we call a source. And from this, we run it with some fresh private coins.
And it outputs some randomness R and then two messages M0 and M1. Okay?
So now the coins that are used to run this algorithm are hidden from the
adversary, but the adversary gets to pick how the distribution of R, M, M1 is
defined.
And so at this point we encrypt one of the two messages under the randomness
that was output by this algorithm and return the ciphertext and the public key to
the adversary. And he gets to again try and guess the bit.
Okay. So we're not done yet. There's a lot of other stuff. One very important
issue is that this -- we can't provide security for arbitrary -- arbitrary M. So in
particular, we need some type of unpredictability of the messages of
randomness, otherwise it's trivial for the adversary to win. So we require that this
M must of high min-entropy so that the outputs for any -- so each pair of outputs,
RM0 and RM1, are unpredictable from the adversary's viewpoint.
>>: [inaudible].
>> Tom Ristenpart: Big M -- so big M is an algorithm, and it gets provided fresh
coins. And the output is this triple R, M0 and M1. So you think of M as a
distribution on messages and [inaudible] is that the adversary gets to pick, okay?
And it's going to get fed some private coins, and it outputs what ends up
becoming the message in randomness that we used with the public key for the
challenge.
>>: And PK is the [inaudible].
>> Tom Ristenpart: I'm sorry. I didn't show. PK is chosen correctly by the
environment. So it runs the key generation algorithm of the encryption scheme
and outputs the public key to your key pair. It doesn't output it, it generates them
and uses the public key and then provides the public key to the adversary after
the challenge.
>>: [inaudible].
>> Tom Ristenpart: Does -- yes. Does not. Does not see R, yes. I mean,
unless he leaks it, in which case you have problems, yes.
>>: So one of the [inaudible] PK ->> Tom Ristenpart: He doesn't see PK, yeah. There's a lot of subtleties to this
definition. And, in fact, I only showed you a very rudimentary kind of
simplification of it. So one thing is that actually we have define an M that doesn't
output just three values but actually outputs three vectors of values. And the
reason we have to do that is because in this setting for the most liberal notion of
min-entropy, single -- message security doesn't imply multi-message security as
it does not randomized encryption case. So it's a bit technical but the idea is,
yeah, you need to output vectors as well, so you get backup vector of ciphertext.
This then gives rise to another problem which is that the -- which is what we
called equality pattern restrictions. So the fact is if you're outputting a vector, just
the equality of message randomness pairs is going to be represented in the
ciphertext that get output because the ciphertext will be equal. So the pattern of
equalities inside the ciphertext could leak information trivially, and this doesn't
really say much in terms of security, so we basically have to have some
restrictions saying that the adversary picks an M that doesn't take advantage of
this fact.
So for example, we could assume that -- or we could rule -- require that M
outputs just unique pairs of R and M values in the vector. So all the ciphertext
end up being unique.
We actually also defined and adaptive variant so that you can actually query
multiple times these messages that output vectors. And this actually has some
very interesting ramifications because of what I'll talk about in a sec, which is a
public key issue, that if you can query multiple times, this is not equivalent to just
querying once with a vector because the encryption scheme could leak some
information about the public key, which is problematic in this case if you can
define message distributions as a function of the public key.
And so as Yevgeniy kind of pointed out, if the adversary gets to define message
-- these M samplers as a function of the public key, then you can trivially win.
And I won't go into the details but it's kind of a simple thing to -- a simple exercise
and so for that reason at least, this definition does not imply IND-CPA, our
traditional notion, which is unfortunate, but seems inherent.
Okay. So particularly in light of that last fact, that this new definition is not
stronger than IND-CPA when we target building what we're calling hedged
public-key encryption schemes, we're going to target both goals in the same
time. So we want to have something that is IND-CPA secure when randomness
is good in the traditional sense and now additionally is CDA secure. And this
provides security for a variety of randomness failure models.
Now, I have a little parenthetical comment here that there is some work by one of
our co-authors, Scott, but in a separate paper showing an enhancement to
IND-CPA that can -- the very particular typical of randomness failure, which is
resets, and there you can do a little bit better than with CDA definition. But I don't
want to go into the details of it. You can ask me about it later.
So in this paper we explored a bunch of different constructions. There's kind of
some straightforward ways to go from -- there's some straightforward approaches
to go from deterministic encryption to hedged encryption. So for example ->>: [Inaudible]
>> Tom Ristenpart: Yeah, yeah, please.
>>: What is CDA?
>> Tom Ristenpart: Oh, I'm sorry, CDA is this chosen distribution attack security.
>>: Oh.
>> Tom Ristenpart: Yeah. Sorry. I shouldn't throw around acronyms I'm familiar
with but no one else is. Yeah. So this is the new definition that we want to
achieve.
Okay. So we can -- there's like two natural approaches. If you have a
deterministic encryption scheme, which is one that doesn't use randomness, to
provide a public key encryption scheme and you have randomized encryption
scheme, there's a -- you know, two natural approaches based on the
composition. And only one of these is secure as it turns out under our definition.
And so don't do this one, I guess.
There's another natural approach just using a deterministic encryption scheme of
a specially type of one, one that ends up being Universal Lossy Trapdoor
Function. You can kind of do an even simpler thing, which is just padding out the
message with sufficient randomness, and then you can show this actually gives
you a hedge secure scheme.
Moving on to look at just doing a now a general framework. So talking about
public-key encryption. We treated that case. And then this NDSS paper we
wanted to say okay, well -- yeah, please, go ahead.
>>: So [inaudible] also this repeated randomness?
>> Tom Ristenpart: So not entirely. So the problem is the public-key
independence issue again. So you can -- you can model some forms of repeat
randomness, like your message execution vector could output to -- you could
output vectors that have the same randomness in each one. But uniform. And
so it captures that. But that's only for public key independent distributions.
The definition of Yilek actually just takes IND-CPA, enhances it and shows that
you can -- you can give the adversary additional power to reset -- to get
encryptions under the same randomness multiple times and you can actually
achieve something that does not have just public key independent distributions.
So it is also orthogonal to the CDA definition but is stronger than IND-CPA.
Yeah.
So, okay, so we had this -- so we could just define kind of a general framework
for hedging, you know arbitrary routine cryptographic operation. This really goes
back to the kind of folklore idea that Yevgeniy alluded to earlier. We have some
operation that has some inputs, in keys, some randomness. What we're going to
do is just run this all through a hedging function to derive new effective
randomness for use with the underlying routine operation.
And this has a number of nice properties for practical crypto. One, it doesn't
impact functionality, so you can immediately deploy it. So for example, on TLS
you can, you know, hedge one side of a connection, the other side double even
know, and -- or vice versa or both, which should be even better.
So for -- and, you know, in the paper we suggested that you -- there's a variety of
ways you could implement the hedging funding, you have to be a little bit careful.
We suggested using HMAC, a sufficiently strong hash function. And the reason
is that has two, at least two nice properties. One is that when the key is good,
when this randomness is good, you get a pseudorandom function.
And even if the key is bad, then at least you get the idea of this HMAC behaves
like an ideal hash function and gives you something that is, you know, good
enough to be models of random oracle in our proofs.
So with public-key encryption we can do this. And then we get this kind of ladder
of security that we get. So under good randomness, you know, if we have our
traditional IND-CPA notion well this meets it and we can get by with a relatively
mild assumption on the hedge function.
And then when the randomness is repeated we have to strengthen our function a
little bit, but then we meet this repeated goal. And then for entirely -- like for
example for the case repeated randomness we get -- we can still meet this, but
now we have to make the random oracle assumption on the hedging function.
So but the point we want to emphasize is that you know by doing this you're not
degrading really the security guarantee you got in the original case. We're not
doing any worse than we did before, at the very least.
Okay. So you can do this with other primitives, so for example, signing, the
problem with the DSA attacks we had before, you can do the same type of thing.
And here you even -- you get, yeah, similar type of situation.
So just to drive it home, of course, if hedging had already been implemented,
these attacks, you know, wouldn't have worked because there would have been
no catastrophic failure of these protocols. And so, you know, the take-away is
that really hedging of course is not going to replaces our need for good random
number generators. But it's going to give us some nice defense and depth
properties built into our cryptographic primitives that we can reason about, should
we have failures which seem to unfortunately happen all too often.
We went ahead and implemented hedging in OpenSSL and, you know, ran some
numbers and stuff. It doesn't cost much, I guess the take-away, no one's going
to notice if you have hedging running or numbers and stuff. Okay.
So anyway, just to wrap up. Okay. So we saw two things, right? VM reset
vulnerabilities and hedge cryptography. VM reset vulnerabilities, right, we're
going to have lots of software -- we have lots of software out there already that
was designed for a world in which, you know, virtual machines didn't really exist
or at least I should say weren't being used. And this legacy software isn't
designed with things like resets in mind. And so when you have this new kind of
almost competition model going on in the background that, you know, things are
getting reset, applications are going to break. And I think that at least people
have been thinking very carefully about how it made functionality preserved in
this type of new world for virtual -- virtualization but when it comes to security,
people of course aren't thinking about this as much and the concern is that we
have these type of vulnerabilities, these random number generators, there might
be a lot of other problems lurking out there. And so my sense this is a big can of
worms that we're going to have to deal with.
On the other side of the fence we have the hedge crypto. Okay. Let's try to
make our cryptography behave less embarrassingly in the face of bad
randomness. For practical crypto, it can be very fast and simple, you know, of
course the catch is that you end up with concave looking definitions sometimes
and maybe relatively complex analyses. But that's okay. Give cryptographers
something to do.
And, yeah, so the idea is to provide good defense and depth or graceful
degredation of security in the face of bad randomness failures. And of course
there's this one kind of open thing to do is to set back, at least for the case of
random number generators and look back at how we should be designing these
in light of resets.
So I'll leave it there and take any questions. More questions I should say.
>>: So this notion of hedging can be done [inaudible] right? [inaudible].
>> Tom Ristenpart: That's right. Yeah.
>>: [inaudible].
>> Tom Ristenpart: See, I mean you can do it to anyone, but you should -- you
should check what you're doing. And so it -- there seems like -- in general it
seems like it should be totally fine. But we didn't do -- we don't have some type
of argument saying that no matter what security property you were trying to
achieve hedging will, you know, not sacrifice it. And so my sense is actually you
could find counterexamples that for some cryptographic primitives if you do
hedging maybe you've done things that you don't like, you can think about things
like non-committing encryption or something or -- sorry, non-committing
encryption? Committing. Yeah, non-committing encryption would be potentially
compromised because you're running the randomness through this thing.
So you can apply it anywhere, but probably should have people look at each
example, yeah. Go ahead.
>>: In the '60s, '70s, '80s, and the '90s, there were a fair amount of paper on
how to take IBM's horrible random number generator and make it do something
decent. Have you checked with [inaudible].
>> Tom Ristenpart: I have not. So what was bad with the IBM one?
>>: I can explain to you.
>> Tom Ristenpart: Okay. Yeah. I mean -- random number generators seem to
be something that we haven't gotten right by any stretch of the imagination over
the years. So yeah.
>>: Okay. I'm just curious how far it goes because.
>> Tom Ristenpart: Huh?
>>: I'm curious how far this, you know, hedging goes because presumably I
guess, I don't know how slow it would be, but you can always do stuff like if you
have some [inaudible] and whenever some new data comes in, you just apply,
keep applying that [inaudible] and when you reset and the new data comes in,
you [inaudible] in a different direction. So essentially it's like I'm suggesting you
[inaudible] some kind of iterative [inaudible].
>> Tom Ristenpart: So are you basically saying you maintain substate ->>: [inaudible] where, you know, every nice -- and that was the reason data
which is, you know, particularly the application develop data state.
>> Tom Ristenpart: So I think you're right as long as you're careful to stake all
the same type of inputs that we're sticking and hedging here into this stateful
thing you're good. But I feel like stateful is just going to make things more
complicated to deal with.
>>: But this way I'm saying.
>> Tom Ristenpart: It's not clear you're gaining any efficiency speedup there
either. What's the ->>: I'm just saying it's -- it's not efficiency it's essentially -- it seems like if you
want to get as bulletproof thing in the presence of reset attacks that way to go.
When you say [inaudible] specific randomness presume there is a problem
[inaudible] you use the same randomness [inaudible] the moment you change
the message the randomness will also, you know, [inaudible] you say you can't
[inaudible] whenever new stuff comes in a new message comes in, you will use
the randomness for the signing. So essentially kind of maybe with -- maybe build
it almost the system level kind of thing [inaudible] there is some [inaudible].
>> Tom Ristenpart: So yes, you could rebuild random number generation inside
applications, just have a PRF key lying there and then they run it over things.
The question is you have to be careful about what things you stick into it, right?
Because there could be corner cases, I don't have great examples, I have some
of my anecdotes that you know if you put too much stuff into it, adversarially
controlled things, you might be affecting other security properties elsewhere.
And so if you kind of take it out of the crypto primitive, it's hard to do the analysis.
If systems [inaudible] throw things in.
So one of the things is we do hedging in the primitive, we can kind of just do it,
and then people don't have to be the wiser, right, and we can do the analysis.
>>: I'm not suggesting something maybe [inaudible] system level [inaudible]
essentially do application [inaudible] design a process you have an option to
specify [inaudible] batch of obligation specific data which you want to be used to
mix randomness. So maybe ->> Tom Ristenpart: So we essentially have that type of API now with random
number generators, right, you can have an application say here to the OpenSSL
random number generator here's a bunch of application specific stuff that I want
you to mix into the pool. But I mean it's not clear people do this. And it's not
clear it's always the right thing to do necessarily. I mean, you have to be careful
is all I'm saying. It could be okay.
Whereas the hedging thing, you know, it's simple because we can look at it in the
context of the cryptographic algorithm. And that's the take-away benefit I think.
Yeah?
>>: So assume that you have a hardware RNG.
>> Tom Ristenpart: Yes, I'm assuming that, yes.
>>: And because ->> Tom Ristenpart: Now I'm assuming that.
>>: Well, because I'm thinking about this in the Windows context, right, where
you're looking at VM snapshots but it's actually not that different than say I've got
a bunch of identical machines I'm going to power on equivalently and make this
[inaudible].
>> Tom Ristenpart: Right.
>>: Okay. Independent of the VM issue, the VMs just push the [inaudible]. So
we've certainly noticed issues with [inaudible] across machines. One way we fix
that is you put TPMs and we scrape the TPMs off and [inaudible].
>> Tom Ristenpart: [inaudible] now you guys are going to move to Intel chips,
you're going to use the hardware instruction?
>>: If that's there. We won't take advantage of anything [inaudible] we have a
model where we're take entropy from a variety of hardware sources.
>> Tom Ristenpart: Okay.
>>: So, you know, the more the merrier. If I -- and then there's a case that you
didn't explicitly highlight but I think it's related which is generally when you power
down and reboot a machine, there is a save of pool.
>> Tom Ristenpart: Right.
>>: Right. And to put that similar snapshot [inaudible] protection there will
effectively roll the pool forward.
>> Tom Ristenpart: It's not exactly the same as duplicating a snapshot, right?
>>: [inaudible].
>> Tom Ristenpart: Because you're still moving forward.
>>: [inaudible] generally moving forward.
>> Tom Ristenpart: Yeah.
>>: When you do a VM you either mix in from your hardware at that point in time
when you bring the snapshot back, or if you know that when you safe the
snapshot out, you roll the pool.
>> Tom Ristenpart: Right.
>>: Right? You know, there's ways that you could defend against this at the OS
model.
>> Tom Ristenpart: That's true. If your application is playing ball, right? The
application needs to make sure it's not ->>: So these are cases where the application -- or I'm assuming that the OS
provides a system RNG ->> Tom Ristenpart: Right. So I think we would go a long ways if we had a nice
and like, you know, cryptographically sanctified or whatever [inaudible] the
random number generator if the operating system, the VMM support, right? So
even if you have all that, which I agree that's going to go a long ways to helping
the situation, you still need the applications to use it correctly. Just -- you know,
the same problems we've always had with random number generators,
applications didn't use it correctly.
>>: That is the [inaudible] apps are putting their own RNGs into the apps and
calling the system certified [inaudible].
>> Tom Ristenpart: Well, I don't know. The thing is -- and I'm not positive what
the design rationale is between the -- I'm not positive what designer rationale is,
but my suspicion is for things like Firefox they grab randomness at boot-up time
because it's inefficient to grab randomness otherwise.
Maybe this goes away if you have an Intel instruction that's very quick to give you
randomness. But anyway, they want to do this for efficiency. So they cache it
before the physical examination connection request goes out because they want
to optimize -- that's like on the critical path, right, so they thought they could take
random number generator out of the critical path. What we're saying with
snapshots, the application layer, you need to put it back in the critical path, you
know, for this type of thing like browser TLS request.
So but you're 100 percent right. Like we need to get good random number
generators built that the operating system and the virtual -- and the VMM and
have hardware back up, hardware sources. And then it's just a matter of making
sure applications are doing the right thing. Which I think includes kind of upset
dating cryptographic best practices about saying, you know, you need -- you
can't do random number generation grabbing like, you know, four days ago and
then use it later. I mean, you need to really kind of put it in the critical path.
>>: How much of this problem is because the applications you looked at are
effectively implementing their own RNGs in [inaudible] as opposed to -- and
therefore they're caching -- they're pooling the state out of the system at random
or [inaudible] random [inaudible].
>> Tom Ristenpart: Right.
>>: And they're then doing their own RNG [inaudible].
>> Tom Ristenpart: It's an open question. It's an open question. So you're right,
I think the attack as it is would not work. If you hit dev random every time, even
without a good VMM backed up dev random. But it's not clear you -- it's not clear
you're secure still. I mean, it may be that you still have some probability
[inaudible] repetition. Because it depends on what the sources are going to dev
random at that point. Now, if you replace dev random with something that's VMM
backed up and you're hitting dev random right before the application use the
randomness, then you're probably okay. Accept for this kind of naggling
theoretical issue that it's not atomic, right?
>>: [inaudible] some randomness [inaudible].
>> Tom Ristenpart: Well, I ->>: [inaudible].
[brief talking over].
>> Tom Ristenpart: Some of them do -- they have their own RNG like logic
inside the application and some of them go to dev random sometimes to refresh
->>: Well, let's say they didn't. Let's say ->> Tom Ristenpart: That's exactly what I'm saying. Hypothetically if they always
went to dev random that would be better, but I'm saying that wouldn't fix ->>: [inaudible].
>>: Even if you had a gap between the two.
>>: Right. But look. Look at what happens on [inaudible] as a counter
[inaudible] right? So you call into the SSL stack. That's a common system sort
of thing. That calls down into the RNG inside of [inaudible] right? And, in fact,
there's a fan out down there, and I've actually got eight [inaudible] there's a back
state so that if you've got RNG that are a system function, right, you have to
worry about whether or not back end persistent okay and when you spin those up
when you bring the OS up, where do they full entropy from?
So the question is where is the entropy pool that your system -- I mean, it's a
matter of you've got an RNG, there's an entropy pool pack at -- who pools
entropy [inaudible].
>> Tom Ristenpart: It's not just who but when, right, is the question.
>>: And then if the snapshot it, do you detect that properly and do you effectively
mix something else into it so that you [inaudible] but once the randomness is
[inaudible] there's this gap between ->>: So the question becomes then is the app pulling randomness from the pool
right before it's being used or [inaudible].
>> Tom Ristenpart: And [inaudible].
>>: And is it deriving any further product, right?
>> Tom Ristenpart: Yeah. I mean what he's saying is sometimes they pool it
from the operating system and then they use that as like a PRF key. But I mean
either way it done matter. I mean it's a -- there's kind of problems at a lot of
different levels. And maybe I didn't do the best job of clarifying that there's like
problem A, B, and C, I mean there's like a bunch of problems mixed together
here. But in any case, we need to figure out how to do good random number
generation in VM settings and then we need to educate application design about
proper use in the case -- in the context of resets. And actually doing that is easy
to say that, but doing it is probably a little bit harder.
>>: Maybe you shouldn't take too many time but [inaudible].
>> Tom Ristenpart: [inaudible].
>>: I'm just saying my suggestion very quickly is just instead of [inaudible]
random, we just call that randomness [inaudible] just call that randomness an
optimal application specific input and then [inaudible] so that the user double
have to know [inaudible] I'll just call that randomness [inaudible] specify input and
the [inaudible] system guarantees [inaudible] even if it's [inaudible]. That's all I'm
suggesting.
>> Tom Ristenpart: If the seed was good, then what's the guarantee that
[inaudible].
>>: So when the user [inaudible] instead of just coordinating dev random and
[inaudible] random functions or something I just pull dev random as a logical
[inaudible] message [inaudible] or whatever, then I'm going to repeat the
randomness I get is going to incorporate my optional input.
>> Tom Ristenpart: So I mean that doesn't -- so that might be one solution, but I
mean that doesn't change the three things I said you need to do, right? And what
your suggesting there requires application changes, right? So ->>: Multiplication changes ->> Tom Ristenpart: No, no, the application needs to do this, right, because you
changed the API.
>>: [inaudible].
>> Tom Ristenpart: Yes. So you have to change all the applications and use
dev random, right? So which may not be ->>: [inaudible]. Right? So you could -- you know, they can increase the
application and [inaudible].
>> Tom Ristenpart: Yeah. But if we want security, then you can't -- I mean, you
have to make sure that it's not [inaudible].
>>: I'm just saying that [inaudible] user specify argument and then it will
[inaudible].
>> Tom Ristenpart: I think there's a host of reasons. But you have to ask
someone to sign the APIs. Yeah, I think I'm way over on time. So thank you.
>>: Yes. Let's thank the speaker.
[applause]
>>: Our next speaker the Krzysztof Pietrzak speaking on subspace LWE.
Krzysztof is [inaudible] CWI.
>> Krzysztof Pietrzak: Okay. Can you hear me? Okay. So I will speak about
something which actually honestly has nothing to do with the cloud but we'll talk
about it anyway. So it's about the learning with errors problems. So here is a
short outline of the talk.
I will first define the learning with errors problem and the less general learning
parities with noise problem. Then I will show you in the -- this is non-adaptive
hardness assumption. Then I'm going to show you the adaptive assumption
which just has the seminar subspace in front of it and actually prove, could show
proof that those two assumptions are equivalent, the original and this adaptive
one. And then I'll show some cool applications of this new assumption.
Okay so. What is the learning parities with noise problem? This is a problem
that comes -- has a long history, has been looked at by people from learning
theory and so on. It's defined very simply. So if a person who has access to
black box, this black box -- this black box has some random bit string of length N
inside it and some parameter between zero and one-half, and then the person
can just ask, give me a sample, and what this box does is it samples a uniform
random bit string of length N, it samples and error with Bernoulli distribution with
parameter tau. This means this is a random variable which is zero with
probability -- sorry, this is a random variable which is one with probability tau and
this bias towards zero.
And then what this box outputs is, yeah, this random R, and the inner product, so
bitwise, bitwise multiplication with R and the secret S, plus added just a little bit of
noise to it. And, yeah, we will say that so these learning parities with noise
problem is hard, so parameterized by this length of secret N the number of
samples that the adversary does this noise parameter tau. You say it's S epsilon
hard if you're at the advantage of any adversary of outputting actually the secret
is upper bounded by epsilon.
So this is the computational version of the LPN. Probably you can also define a
decisional version. So in this case, you have an adversary who has either
access to the box that I just described or to a box which actually does adds
uniform random error to this thing, so actually the entire string is in eForm
random and then you say okay this problem is hard if the adversary has at most
advantage epsilon and distinguish these two cases and, in fact, decisional and
computational version have been shown to be polynomial equivalent.
Okay. That's the learning parities with noise problem. It has been generalized
by Regev in '05 to a problem that is called learning with errors. Again, we have
like a secret but it's now not a bit string but like a string of elements in set Q. And
we have not just an error parameter tau but like some error distribution chi, which
outputs -- so this is a distribution over elements in zed Q. What is used actually
in this something that is called a discrete Gaussian.
So it's like an error distribution that looks like a Gaussian and this -- small
variants like I think square root of Q or something is what you usually use.
Okay. Distribution -- the game is the same. We sample a random R in zed Q.
We sample an error according to this distribution and the adversary can ask for
arbitrary many samples and again we say that this problem is hard, we cannot
distinguish, and the decisional version is you cannot distinguish this distribution
here from uniform -- from a box that just gives uniform random stuff.
Okay. What is known about this problem so as I said before the decisional and
computational versions are the same, and from now on I will always talk when I
talk about the LPN and LWE, I will always talk about the decisional version. So
the strong version where you ask to distinguish random from these samples.
The learning parities with noise -- yes?
>>: [inaudible].
>> Krzysztof Pietrzak: So [inaudible].
>>: [inaudible].
>> Krzysztof Pietrzak: So the LPN is model is two, and I really don't know what
Regev shows. Kris know it probably better.
>>: Prime polynomial Q or something with Q ->>: What's KSS? What's KSS?
>> Krzysztof Pietrzak: That's -- I took this from Regev's overview of learning with
errors [inaudible] that is actually so the Regev attributes it to this [inaudible] okay.
Maybe it's a typo of mine. I will get that.
>>: [inaudible].
>> Krzysztof Pietrzak: Okay. So it's equivalent for appropriate choices.
Okay. So look the LPN problem is known to be equivalent to decoding random
linear codes. This is the average case, however, in this assumption. And what's
cool about the LWE assumption is so when this rare distribution is something
called a discrete Gaussian this problem has been shown by Regev to be as hard
as worst case lattice problems. So this is ->>: [inaudible].
>>: No. No.
>>: [inaudible].
>>: [inaudible].
>> Krzysztof Pietrzak: Okay. And these problems were LWE and LPN problem
have been used in cryptography a lot, so LWE has been used -- so for one thing
because it has this extremely cool hardness guarantee and for another it has
turned out to be extreme versatile for crypto, so Kris and Dino and other people
have built pretty much any primitive you can think of from LWE like, yeah, public
encryption, IBE hype and I don't know what, signatures and so on.
The LPN problem is less versatile, so it's -- so there is something like it's less
versatile for doing crypto, but it still has found usages because it's extremely
efficient, because you just painful do bit, bitwise taking in a product that's
extremely fast. So you might have heard about this authentication protocols due
to Hopper and Blum. I will come to this later. Okay.
So this LWE problem is -- it's a non-interactive hardness assumption. You just
get samples you distinguish. Okay. Now let me define a new hardness
assumption which I will call subspace LWE which is now a adaptive hardness
assumption. So now the adversary action can interact with this box. The box
again is parameterized it has some secret of length M in zed Q. More over, it's
parameterized, again, the error distribution chi and moreover some parameter N
which is less than M. I will come in a minute to what this M has to do.
What the adversary now can do is he can ask the query to this box, not just give
me the next sample but actually the adversary can choose two -- two fine
projections, phi R and phi S. So technically, the phi R is for example given by M
times M matrix XR. So this is 2 to the -- you know, 2 to the linear projection and
it's defined so you can have this little XR to add something to it. Same for phi S.
And what the adversary gets back is now the following, as before the box
samples of random R are distribution T. But it gives back so this random R and
the inner product not of error S, plus the error S before, but like it first produces
phi R to project R to whatever phi R defined. It projects S to whatever phi S
defined. And then it takes the inner product of this -- these two projected values.
Okay. What is this -- oh, yeah, this is the definition of the [inaudible]. So
basically we can define like a hardness assumption. So okay, look at this
problem, this M, NT, chi, sub SLWE problem is hard if no adversary can
distinguish this. And I should say something more. Okay.
>>: [inaudible].
>> Krzysztof Pietrzak: What?
>>: Can you repeat again what [inaudible] the adversary chooses?
>> Krzysztof Pietrzak: Yeah. I forgot to [inaudible] the adversary chooses this
matrices, XR -- big XR, small XR, big XS, small XS, which defined projections of
R and S. And there is one constraint to this choice. He cannot choose this
arbitrary because if he can do this, this is obviously trivial, this problem. One
second. Because the adversary could just protect in the first coordinate of S of
many samples, the little error you could cancel it out, you would learn it.
So I put an additional constraint, and this constraint is that this project this phi R
and phi S overlapping is efficiently project and overlapping is efficiently large
subspace and I require that the subspace is at as I mentioned at M which
formally means the rank of XR and XS. Has to be at least N. But otherwise the
adversary can do what he wants.
So for example, I will show you in next example what XS and XR can be. For
example, he can just take a subset of size N of the element or fix all of the bits of
R except N positions. Yes?
>>: [inaudible] let's assume for a minute that also XR, little X subzero.
>> Krzysztof Pietrzak: Yeah.
>>: That's okay, right? And big XR and XS are [inaudible].
>> Krzysztof Pietrzak: So this is the input to the box. The adversary adaptively
chooses this as inputs, he chooses this as inputs, S gets stuff back. Chooses
adaptively new XS, XR, asks the box, gets a new sample back and so on.
>>: [inaudible] so somebody should restrict them. So their restrictions only on
each [inaudible].
>> Krzysztof Pietrzak: Yeah. Of each fit independently. When he chooses this
to SXR, they have to overlap in a sufficiently large subspace. Okay?
>>: [inaudible] the noise is chosen randomly each time.
>> Krzysztof Pietrzak: The noise is as before. The noise is exactly as in the
original LWE.
>>: [inaudible].
>> Krzysztof Pietrzak: Yeah, with each, with each -- exactly.
>>: [inaudible].
>> Krzysztof Pietrzak: It's not the same [inaudible] no. It's like the LWE.
>>: So in that case the [inaudible] is basically the [inaudible] right?
>> Krzysztof Pietrzak: In which case?
>>: So [inaudible].
>> Krzysztof Pietrzak: When what? So when XR and XS are [inaudible]
matrices and XR, XS are zero, you are back to the started [inaudible] okay? All
right. So let me say a few things to clarify. One thing is completely trivial. So if
this adaptive thing is hard, then this [inaudible] that the standard [inaudible] so
this is the trivial direction, and this is very easy to see why. Because, okay,
assume I -- assume I have access to this M, N subspace LWE oracle, then I can
-- and if an adversary who breaks this assumption to advantage epsilon then I
make you an adversary against the standard LWE assumption which uses
secrets of length N, which is the intention of the subspace that I have to project
into in a very simple way. I just choose the inputs. I always choose the same
inputs to this adapt -- to my subspace LWE or I can just input simply this XR and
XS are zero. And the projections that the use the identify matrix in the first N
diagonal entries, and the rest is zero.
What happens -- okay. What happens is that I get the inner product of this form
but not this XR times R, it is just deletes out everything of R except first N
positions and this deletes everything out except the first N position. So what you
get is basically in the product of like a prefix of S which you have exactly the
same distribution as with the normal LWE assumption that uses as a secret a
substring of S which just contains the first element.
So this direction is trivial if the subspace is hard -- if the subspace assumption is
hard using secrets of length M where we have to project the two dimensions N,
this is as hard as the -- if this is hard, then also the standard assumption is hard.
So the interesting thing is that the other direction is also true. Basically. So if the
-- this N -- this standard problem with secrets of length N is hard, then also this
subspace LWE problem that maps into subsets of -- into subspaces of dimension
N, it's also hard.
And what do we lose? Okay. So the size of the -- of the adversary's considered
you don't say anything, so this epsilon here is the error of the subspace, and this
EPS here is on the standard LWE. It's the same but plus something that
depends on the dimension of -- that depends on the dimension of the -- so on
that queue, on the elements that you use.
Okay. This is good enough if Q is exponential or very big super polynomial but
not if Q is say two for LPN but fortunately we can do a little bit better. So if you
take a gap between these dimensions that you require, so I want that you map
into dimension of N plus D where D is I don't know, 50 or something, then this
problem is actually as hard as the LWE assumption of dimension N, and you only
get an additional factor in the error which is like exponentially small in D. So Q to
the D, Q is the size of the field in D, so if you choose this gap big enough,
depending on Q that you need, then you have -- it shows that those things are
basically equivalent.
>>: [inaudible]. I'm saying the same thing. Maybe a more clean way to say it,
you could say for any delta, you get epsilon prime is epsilon plus delta, but then
you put N plus log [inaudible] I mean this is more like more consistent [inaudible].
I'm just saying M [inaudible] delta, this thing is epsilon prime is equal epsilon plus
delta as long as you set M prime to be [inaudible].
>> Krzysztof Pietrzak: Okay. So why -- what does this imply? So before I show
you any construction, what does this, the fact that this subspace LWE samples
are hard? So I said to you before that there are tons of applications -- or
applications of this LWE and LPN assumptions. So and many of these
assumptions they use the fact that the samples of pseudorandom that you get
from the LWE oracle. But what happens, for example, to [inaudible] okay. This
is what the SLWE case gives you. What for example -- what happens for
example if now we have this application that -- whose hardness relies on, you
know, the hardness of LWE but somehow the adversary can kind of fix a few, few
bits of this random vector R? So the application has to fix the random vector R.
But maybe the adversary can control this source is like a bit fixing source say so
the element can fix all the elements of R except an element.
So this, because the sub-- this is going to be as hard as the subspace LWE
problem of dimension N, so you have secrets of length N, the adversary can fix
all the bits except N element and because this is as hard as the SLWE problem
of dimension N, your primitive will stay secure even if the adversary can't fix all
bits. Okay. You do great in security, you basically fall back to the security that is
guaranteed by the LWE assumptions with secrets of length N instead of M, but
you're still safe.
So caveat here is we still have this error vector which tells us to be random, and
you cannot tamper with this. So if anything goes wrong with the randomness for
the error here, you're dead.
But in many occasions, for example, the HP product called [inaudible] you -- this
randomness is sent over a channel. And maybe the adversary can tamper with it
and set a few bits but not everything. And this basically implies that you're still
safe, even if this happens.
Another thing is relate something that is called related-key attacks. So in the
related-key attacks you have a crypto system that has a secret S. And what you
can do is maybe you can somehow change to secret. Maybe it's smart card you
can put it microbay microbay, flip a few bits or something, you can somehow
change the secret and then actually invoke the crypto primitive with this slightly
tampered secret.
So assume for example what you can do is you have this -- again, the perimeter
that is based on the LWE assumption and you have the secret key is actually at
the secret S used for LWE and maybe the adversary can somehow set the
elements of S. He can set almost all elements but like -- he can set all elements
but maybe not N of them. So N of them will always be the original ones.
And, yeah, the hardness of SL to be -- subspace LWE implies that this is still
going to stay hard. As hard as the standard LWE problem with secrets of length
N. So these are just to illustrate like two particular examples of what such a
subspace LWE allows you to do.
>>: [inaudible].
>> Krzysztof Pietrzak: No, no, it says F can fix O but N elements of the secret.
>>: [inaudible] here you show the [inaudible] distribution on average has to have
[inaudible] and here you're saying the distinct distributions could be the
subspaces microbay some sense but you [inaudible] change it.
>> Krzysztof Pietrzak: So, the -- this LWE assumption we have proven to be
extremely resilient to leakage. So if you have a secret S that stays -- the secret
stays always the same. You leak something [inaudible] so this is -- this shows ->>: [inaudible].
>> Krzysztof Pietrzak: It's a completely orthogonal thing. This shows it's resilient
to tampering not against leakage, this is resilient to tampering. Here you actually
change the secret and [inaudible] you don't leak anything except what you get
from access but you actually tamper with the secret. Okay.
Okay. So let me give the proof sketch of this theorem that I said before that
okay, if the LWE problem is hard and also this subspace LWE problem is hard.
So what's the challenge here? So the challenges here we have access. What
we have to do is we have access to LWE oracle, that gives you simplest of this,
so some secret S of length N samples random vectors R, that's error and so on.
And you have to show how to transform this, so to prove this theorem you have
to show how to transform this sample into samples of this form, where this XR
and XS are just chosen with every sample.
For every sample we have to do this transformation. And for all these samples
this S hat has to stay the same. It doesn't -- it has to be random and stay the
same used microbay all the samples because it stays the same microbay the
assumption. And this R hat has to be uniformly random microbay every new
sample.
Okay. How do we do that? So that's the transformation how you transform this
S into this S hat. Of course if it's a transformation, you don't actually do this at
the reduction because you don't know S. But that's what you -- that's how you -what you do is the following. You sample the random matrix R, N times N matrix,
some blinding vector B, and you define this new S hat to be R times S plus B.
You don't know what S hat is. You don't know what S is. But you will generate
samples of this form using this sample S hat.
Okay. How do you sample this R hat? Okay. That's how you do it. So this is a
-- this is a set. This is the set of solutions to this equation, so you you have this -these are all Ys that solve the inputs from the adversary this is the R that you
chose here, this is also inputs from the other [inaudible] again, this R. This is the
R that you get from the LWE sample. And you just sample this R hat randomly
from all solutions to this equation. And this set is actually nonempty if the rank of
this matrix XR times XS times R is at least N.
And actually you can show -- you know, if the rank of this here is at least N plus
D, which you were guaranteed because that's what you require from the
adversary that you only choose this matrices that have rank N plus D and this R
is uniformly random, you can actually show that the probability that this has rank
less than N is at most basically two divided by Q to the D plus one. Okay. And
then because you use T samples you have this T up here.
Okay. Okay. And now, okay, I'll show you how to sample this R hat. I still have
to say how to sample this entire big thing. So the error E here will be exactly the
same error as you have here. And that's how you sample it basically. So this
term here does this term here is basically the term you get from the LWE sample
plus some set zed that you can compute from values you know when that's the
zed that you -- so you know everything. You know our hat, you know these
values from the adversary just B you have chosen yourself and so on.
And you do some linear algebra and proof that this is perfectly the right
distribution. So that's the reduction. Okay. That's the first part. Yes? Okay.
That's the first part of the talk.
And now I come to an application -- so I showed you that this subspace LWE
assumption is like [inaudible] applications microbay terms of you have a bit it
immediately implies security [inaudible] bit fixing sources or some classes of
related key attacks for all existing schemes that are based to securities based on
the LWE assuming to the randomness of the samples.
But you can also -- once you know that this thing is hard, you can come up with
completely new protocols. So I will show you an authentication protocol.
So what's an authentication protocol? So consider a protocol where we have -it's a symmetric authentication protocol. We have like some prover and some
verify that's sometimes called attack and reader. Whatever, they share some
symmetric setting, they share some secret key, they communicate at bit, then at
the end of the communication this reader says okay, I accept or reject.
And of course, the idea is somebody who doesn't know the secret -- secret and
interacts with this -- with the verifier shouldn't be able to make the verifier accept.
And there are many different notions for the security of this authentication text
that the weakest one is so called passive security. So here you consider an
adversary who like microbay the first phase can observe arbitrary communication
transcripts between this programmer the verifier, including the final decision of
the verifier if they accept it or not. So usually he should always accept, but
maybe if a small completeness error.
And microbay the second phase, then the adversary interacts only with the
verifier and he tries to make him accept, then you say okay, the adversary wins
and if he actually can make this prover accept.
As strong a notion is so called security against active attacks, here the adversary
also can first like observe as many samples as he wants. But additionally the
adversary can actually interact with the prover. So he can send challenges or
whatever to the prover and see what answers this very verifier gets. Not only like
randomly chosen challenges from the verifier as normally, and again the second
phase is the same. Okay.
And the ideal notion that you usually want to have from this, and the strongest
notion of cores is security against man microbay the middle attacks. So here you
consider an adversary who sits microbay between the reader and the verifier. He
can arbitrarily interact with those, maybe schedule the messages how you want,
maybe currently and so on. Okay.
>>: [inaudible] you know, you can talk to many provers [inaudible] which is I
don't think it's [inaudible].
>> Krzysztof Pietrzak: The same secret or ->>: No, no. I mean, you -- yeah, the prover's independently talk to -- yes, the
provers say [inaudible].
>> Krzysztof Pietrzak: Yeah, you ->>: [inaudible].
>> Krzysztof Pietrzak: Yes. You could have concurrent execution, some -yeah?
>>: [inaudible].
>> Krzysztof Pietrzak: So I mean actually it's trivial to achieve this kind of
security if you have like a PRF or something or even a Mac. So this is you just
you know the prover the random challenge you evaluate the PRF on that input
and you're done. But what we're doing, this -- what I will do now is to try to get
like authentication protocols which are like extremely efficient, so basically they
just should use a few XRs and Ns. And what you will achieve is only this active
security. So this -- and it's actually open how to do efficient authentication from
LPN.
So you can't do -- that the security man microbay the middle attacks. You can't
do it because it's a pseudorandom generate. You can use GGM and then you
have the PRF, but that's not efficient. So when I say efficient, what I mean is
basically K times N basic operations where K is some parameter that such that
the LPN assumption with secrets of length K is secure and N is some statistical
security parameter a hundred, so K times N [inaudible] source or Ns. That's what
they all are. That's efficient. Okay.
So there is a famous protocol due to Hopper and Blum, so they proposed this
protocol actually as authentication protocol that even humans can compute. So
even if you have like a piece of paper with your secret you actually can do this
microbay your head, or on piece of paper.
So how does the protocol work? So the verifier and the proof of share is secret
S, the verifier chooses a random A, sends it over and the prover sends basically
back so that the LPN sample. So as microbay the product of S and S plus this
error E. And the verifier checks what he gets from the progress really did
microbay the product of S and A. Of course this has -- this has a very big
soundness error -- sorry. Correctness error because, you know, the verify will
only accept with probability one minus tau, so something more than one-half, so
let's say if tau is 0.25 with probability 0.75 and it [inaudible] so this was the
completeness error, it was the soundness error because if I just send the random
-- random bit, the verify will accept still with probability one-half.
But you can amplify this. So you can cut. And Shin showed me how you can do
this microbay parallel like N times, where N is the statistical security parameter
and you're safe. Okay. So that's what I just said.
And this protocol is secure against passive attacks, so this weakest notion that I
showed you before and this trivially insecure against active attacks. And why is it
insecure against active attacks? It's easy to see. So assuming -- so microbay
active attacks you can query the prover microbay the first phase so you just send
microbay As where the first bit of A is one and all the other bits are zero, you get
basically noisy inner products of S times A, S times A where A is like this, which
basically is the first bit of S plus some error. And if you get enough samples you
can -- it will be biased towards the first bit of S and you have [inaudible] the first
bit of S.
And you do this with the second bit of S and so on, and you're learning. Okay.
So subsequently like Jules and Weis if the proposed protocol that is called HB
plus and the chiefs active security, so what we basically do is they add an
additional third round. So if the first rounds, actually the prover chooses the
random B and sends it over to the verifier. From then on -- okay, as microbay
the HB protocol, the verifier chooses A, sends it back, then you compute this so
the inner product of some secret S1 with B, some secret S2 with A at the error
and again the thing is as before. This is secure against active attacks but not
against man microbay the middle attacks. Has three rounds.
And let me see. Okay. That's the protocol again. And it breaks -- okay. And
that's a very, very cute security proof that I will go through and -- for a few
minutes due to Katz and Shin. So they show the following. So assume I have
and adversary A who breaks this active security of this protocol with advantage
epsilon. So this adversary expects first access to some -- to some prover P and I
-- so I run this adversary and I do the following: I choose S2 myself. I have
access to some LPN oracle which either gives me LPN samples or uniform
random junk. And okay. Whatever I get from the oracle I send to A. I get like N
samples with the randomness I concatenate them, send them over to the
adversary.
The adversary sends me back some matrix A. I send the -- this answer here to
the adversary who just computed as follows: Okay. I know S2, so I compute A
times S2, where this is the A I got from the verifier. And the 6 is whatever I got
from my oracle so this is the elements which are either random or, yeah, all this
noisy inner product that I got from the oracle.
Microbay the second phase -- okay, now the adversary is on the left side and he
has -- and we know that he has advantage epsilon and actually making the very
fair accept. So what you do is the adversary sends the P, we send the adversary
back some random A1 and he gives us some zed one. But of course now we
can't compute anything because we don't know as one. So we kind of check if
this is a valid answer or not.
What we do is we rewind the adversary to this first phase and a different A2 and
a different zed two. And now assume that microbay fact microbay the second
phase both the zed one and zed two would cautious the prover, verifier would
have accepted both of the zed ones, which means the zed one and zed two are
of this form where this E1 is the weight. Okay, if I add them together, then it's B
teams as long, which is the same. I rewind it, but I only rewind it to this point, so
we have two times the same P, which will cancel out.
What I get is -- okay, imagine here is equality, not a plus, and here a plus -- what
I get is this here. So I take this term on the other side of the equation and what I
get, if I just -- okay. These terms I know, S2 I know, so I add this to this term -sorry. I add this to this term, I get like the sum of these two low weight vectors.
And -- okay. If I -- what I get is low weight I assume, okay, this oracle that I have
here really gave me LPN samples.
So microbay this -- okay. And we'd have probability epsilon square. I will accept.
And microbay case this X is uniformly random, then, microbay fact, what you get
microbay the first phase, the zeds, are independent of the secret S2 that I chose.
And you can show that microbay this -- microbay this case the probability -- so
this because -- okay. Because -- I will accept if this has low weight and because
the adversary has no clue about S2, and if this has sufficiently high rank this
thing you rule basically uniformly random, this thing here, so if the adversary
chooses any zed, one or two, it's very likely that this will end up microbay a low
weight vector. So exponentially small probability.
Now, anyway, there has been like tons of follow-up work on protocols we try to
make this protocol active, secure, and then other -- against secure against men
microbay the middle attacks and all the papers that break this again.
So this is from this Website. Okay. And those protocols are all HP -- had
protocols that are like HP are like extensions. So I showed you HP+. There's
like HP#, HP++ and others.
Okay. Now I'll show you protocol which completely different, and it's not the HP
style protocol. And there's two rounds. And it works as follows: So we again
have a verifier and a prover. There's a secret of length -- okay. So we have
some parameters. Parameter K chosen such that the LPN problem of -- with
credits of length K and some security -- an error noise tau is hard.
Okay. I define L to be slightly more than 2 times K. Okay. And N is a statistical
security parameter. The secret is of length 2L and is shared between two. So
what the verifier now does, so microbay the HP protocol he choose a random
vector R to be taken as the inner product. Now he does something else. Now he
chooses a vector V which has length 2L and has weight that's actually L1s. A
random V and you are constrained on the fact that the task weight L. Prove very
fast sends it over to the prover. What does the prover do? He samples the error
vector -- okay. Random matrix.
So think for the moment that this is just a random element, a random vector of
length L, and he takes the inner product of this random R with SV. What is SV?
SV is if you have the secret S and you delete all the elements where V is zero,
that's what I call SV. So it's like basically SV defines like a subset of S. And you
take the inner product of this random vector R with this subset of S and add the
error E to it. And you do this actually N times parallel, basically. So you choose
the R which is like N vector of length L and you take the inner product that is
subset N time and you add this error vector of like E random elements.
E noise elements, each one biased towards one. You send this over to the
verifier. What does the verifier do? He checks if this matrix R has actually full
rank, which it will have almost certainly if it's chosen randomly. And then yeah, it
checks what is the weight of -- of this term here. So what should -- of -- so it -- it
talks the zeds and adds basically this term here RT times SV to it, and if
computed correctly, this should have weight roughly N times tau because there's
N elements, this is basically -- so this should basically be the error vector which
should have roughly weight N times tau.
So if it's significantly more than this, so tau prime is some constant which is
bigger than tau and smaller than one-half, if it's significantly larger than this, then
I reject, otherwise I accept.
And that's the theorem. So if the learning -- LPN problem is a security -- with
secrets of length K is hard, then actually the active security of this protocol is
basically the same epsilon, okay, minus something exponentially small microbay
this statistical security parameter.
So the constant here depends on basically on tau. And on how much bigger
than two this is. So it's -- but it's -- okay. Okay. I wanted to prove on this black
board, but I think I'm running out of time anyway. So I think I'll skip that. But the
prove is really cute. The proof is -- okay.
So let me conclude. So I showed you new adaptive assumption for -- which is
like similar to the new adaptive assumption which is equivalent to a learning with
errors problem. So a application, I showed you like a new protocol. Okay. I
should maybe say a few things about this protocol. So why is this better than
HP+? So for one thing it has one round less. So it's two rounds, which I think it's
for the goal of this protocol, which is like this high efficient -- highly efficient
authentication protocol for RFID tags. I think this makes a difference because
actually it's probably even going to be four rounds if you use HP+ because you
have to take -- to tell to the attack that you now want to start interaction and he
has to send you something and something and so on.
Okay. It's rewindable for the very fact it's HP+. And it has a tight security
reduction. So you see there is epsilon. And what you got before with this
rewind, so there's no rewinding going on microbay the proof. What you did
before with the rewinding gives you epsilon squared.
Okay. So I showed you this new protocol. We also have very efficient Mac from
LPN but it's not really a Mac, it's randomized Mac and it only satisfies a weaker
security notion where you're not allowed to actually ask for verification queries for
Macs, for messages that you have all right received. So you cannot get the Mac
and slightly change something and ask if it's still valid. So but it's okay. You can
still authenticate communication with this microbay the passive setting.
Of course, the question is what else can you do from this adaptive assumption.
So thank you.
[applause].
>>: [inaudible].
>> Krzysztof Pietrzak: The definition of the assumption?
>>: Yes.
>> Krzysztof Pietrzak: Okay.
>>: [inaudible].
>> Krzysztof Pietrzak: So S is like microbay the box. S is secret.
>>: Okay.
>> Krzysztof Pietrzak: So now you make a query. So the adversary makes the
query.
>>: You make a [inaudible] right? [inaudible].
>> Krzysztof Pietrzak: No. The box [inaudible].
>>: All right. So what is the adaptive part?
>> Krzysztof Pietrzak: The adaptive part is the projections, this matrices, XR,
XS. So you look at this and I'd like to microbay the product microbay this
subspace, you know, project this secret into this subspace and the random R that
you will choose into this subspace and compute the product there.
>>: So [inaudible].
>> Krzysztof Pietrzak: Yes.
>>: [inaudible].
>> Krzysztof Pietrzak: Yes. Just for each query you will require that the overlap
of the -- yeah, this projections overlapping and dimension subspace. Because
otherwise if you overlap microbay the one dimension subspace, you can't slap
everything and just keep the [inaudible].
>>: So just one way you could do is [inaudible].
>> Krzysztof Pietrzak: It's [inaudible], right? So even if you make the same
query twice you get different outputs.
>>: [inaudible].
>> Krzysztof Pietrzak: Yeah, yeah.
>>: Aren't you going to get something, you know, very close to each other?
[inaudible].
>> Krzysztof Pietrzak: LWE is always the same.
>>: [inaudible].
>> Krzysztof Pietrzak: Yes. I'm sorry. [inaudible] and then projected down to
[inaudible] yeah.
>>: [inaudible] right, and then the problem becomes [inaudible] that's -- so.
>> Krzysztof Pietrzak: But it's adaptive, right, it's not -- the point is of course if
you just multiply once and ->>: [inaudible] how does XR times R transpose times XS times S? One more.
>> Krzysztof Pietrzak: This [inaudible] here?
>>: Yes. So that's going to be R transpose times XR times big XR matrix XR
times big matrix Xs times S. Transpose. So that's why the matrices kind of
come microbay between the R -- that's what makes it kind of different from
[inaudible].
>>: [inaudible].
>> Krzysztof Pietrzak: That's -- yeah, yeah. That's basing -- yeah. You have
basically R on the left, S on the right and this thing microbay the middle that you
want. So ->>: Yes.
>> Krzysztof Pietrzak: It's redundant. I feel you problem could -- problem it's
equivalent if you Lee out one of these. I'm not sure.
>>: Well, if you could make some on the right and [inaudible] out on the right.
>> Krzysztof Pietrzak: It's probably not the simplest -- it's probably not the
simplest ->>: [inaudible].
>> Krzysztof Pietrzak: It's probably not as [inaudible] you can compress this
somehow to one [inaudible] probably you can't. I just care about the product. It's
probably I think if the adversary just sends this, it's the same. But it's easier to
think about this [inaudible] maybe it's not. But I thought it's easier to think about
the R and the S [inaudible] instead of having R on the left, S on the right, and
then some -- this thing here, matrix microbay the middle. I don't exactly know
what this means. I know it's the same as the other thing, but ->>: And you right away get [inaudible] right because [inaudible] to the sequential
[inaudible]. The other thing already [inaudible].
>> Krzysztof Pietrzak: Because, you know, the point is [inaudible].
>>: [inaudible].
>> Krzysztof Pietrzak: But I have to do right way parallel, and the reason is the
following. You see -- this is the protocol. The reason is the following. And so
Katz and Shin like the HP+ protocol you have this basic round but just like a gap
between soundness and completeness and [inaudible] parallel.
Now assume I would do just the bask round. It just chooses one R here. And
then you repeat this microbay parallel. That's not secure. Because I need to
know this is like -- so because you have to this additional constraint that if you
repeat it microbay times you would have to put the additional constraint that the
Rs chosen by the prover he can't choose -- you know, he can't be malicious and
he can't choose hike a diagonal [inaudible] or something. I'm not -- I cannot force
him to choose randomly. But I need that the rank is big enough. So basically he
has to.
You can do something slightly different. What you can do is you can actually
skip this check and make the secret N bits longer, or you don't even need that, N
bits longer and put the identity matrix microbay front here. So then you kind of
enforce that you always have rank N. But basically it's the first N element. You
can precompute. They're always going to -- it's not going to be less efficient
because it's always going to be the same vector that you basically add.
And another thing is here the prover has to check that this view really has weight
L. And you can also get the -- so this is my -- if you want to do it [inaudible] this
might not be very efficient. But you can get around this and add some -- out of
the secret prime that you always add to it. And to prove it's a bit more
complicated then it's not going to be the weight of the [inaudible] isn't going to be
exactly but it [inaudible].
>>: [inaudible]. Coefficients then that's like leading these coefficients of S out.
>> Krzysztof Pietrzak: Yes. But again you can do it adaptively. I can do it a
priori, I can --.
>>: [inaudible].
>> Krzysztof Pietrzak: Yeah, yeah, I can -- I can fix some bits here and then I get
to sample the next -- microbay the next invocation I fix other bits of R and I get
the sample and [inaudible] the real thing here is that makes it surprising that it's
equivalent to [inaudible]. If you just would have -- you know, if the adversary
chooses this matrices once and we then use it [inaudible] that would not be -would not be use and I wouldn't see how it would be useful. It's the adaptivity
that makes it useful.
>>: [inaudible] question? All right. Let's thank the speaker again.
[applause].
>>: Our next speaker is Yevgeniy Dodis from NYU talking about cryptography
against continuous memory attacks.
>> Yevgeniy Dodis: Okay. So I'm going to talk about leakage-resilient
cryptography. And just kind of a quick motivation, it's probably unnecessary
here, but I'll just run through it. Anyway, so traditionally microbay cryptography
we assume a very nice kind of abstractions that secret keys are perfectly secure,
so for example when we use public key cryptography, public key, but there is
some kind of wall so the secret key is really microbay the safe. And there is a
very well defined interface between the way, you know -- what kind of usages of
the secret keys cryptographer can see. Maybe he can see exactly signatures,
maybe it's ciphertext. But, you know, he be see precisely things as protocol
[inaudible] and some well defined model.
And of course microbay practice, ironically I'm not putting references but there
are a million of references that wouldn't have fit on the slide. Microbay reality
most the cryptography is actually broken, not because somebody breaks
[inaudible] factoring but because of some security things. That's why security
gets much more like federal funding and so on, not because it's like scientifically
deeper but because, you know, that's unfortunately what happens microbay
practice.
You know, you get all kinds of like side channel attacks, you know, this cold-boot
attack, which rested a lot of attention from Princeton and of course there are all
kinds of hackers and so on.
So what those guys do, typically the secret key maybe on some server or on
some smart card or something like that and then one way or another the attacker
gets all kinds of sneaky, geeky machines like monitors an electromagnetic things
or whatever, some things that, you know, when you design crypto systems we
really don't think of it's some weird stuff or which is really outside the model. And
usually one way or another through this we're stuff which is completely outside
our idealized models, attacker gets partial and, you know, unfortunately microbay
some cases even complete information about the secret key.
So until recently, even though kind of there are a lot of, you know, almost
anything cryptography you can kind of relate it to leakage but until recently
essentially the usual responsible cryptographer says well, what can be done? I
don't know about the monitors or, you know, electronic magnetic [inaudible] I'm
not going to write papers like the monitors and, you know, the model or
something like that.
So it's not really our problem. We have a clean model you guys, whoever,
electrical engineers or programmers or security guys or [inaudible] experts or
guys, you know, security guards downstairs, you really have to do a better job to
make sure that our keys are not stolen. So this is kind of, you know, of course
those guys says well, look, it's inevitable, something gets stolen. So anyway
probably what you guys prove is anyway irrelevant. So there is this blame game.
But recently I guess it has been this dedicated effort from a cryptographic
community to do well of the leakage-resilient cryptography and to say let's try to
help. Of course we're not going to get to the low level details how exactly you're
going to, you know, get information about the secret key even though we will try
to be as gentle as we can.
But let's let -- let's add this highly adversarially specified leakage to the idealized
adversarial attack model, and I'll talk about it microbay the next few slides. There
are many options how to do it. And then what we want to do, after we add this
well defined kind of leakage oracle but still adversarial chosen leakage oracle to
our own model we want to design primitives which are provably secure even if
the adversary sees some leakage of the secret key. And hopefully this will allow
us to bridge the gap between theory and practice. And know, this is a young
field. It remains to be seen how far it can bridge the gap. But it's kind of a very
highly promising deduction, and I'm excited about it.
So how do you model leakage? Well, the start is easy. Let's start as a theory.
We will just give the tracker what we call a leakage oracle. There is this owl or
whatever it is that [inaudible] the secret key and the attacker can specify some
function without loss of [inaudible] to a bid because maybe you can call the
oracle multiple times and you will just get one bit of secret, you know, the
function of the secret key.
And of course you can say okay, great, give me first bit of the secret key, give me
a second bit of the secret key, I mean, you're not going to prove any security.
So naturally we -- some will need to restrict the leakage such as attacker doesn't
get secret key microbay full and, you know, one of the stupid comments I got on
a grant application when I wrote something like that, people, you know,
somebody says oh, it's like a theoretician, how can you do it? Well, the attacker
gets something microbay full, well it's kind of a stupid comment but still let me -yeah, I mean look, unfortunately we cannot do magic, we cannot do everything.
So if some who you really don't protect your secret keys that, you know, the
attackers powerful enough to get it microbay full, there is nothing maybe you can
do. But at least if it's reasonable and [inaudible] attackers don't get the key
microbay full because maybe they don't get full access and they just measure
some temperature or something like that, it would be very nice to kind of say
something probably secure about that.
So what it means is just defines if you actually want to put cryptography microbay
provable security here, we have to put some restrictions on the kind of access.
And naturally there are two kinds of dimensions of restrictions that we can put.
The one I'll talk about it on the next slides but roughly the first dimension is -bounds the number of queries during various stages of attacks. So maybe one
bit so you don't [inaudible] it too much. And also maybe the second time of
orthogonal is maybe restrict the type of leakage function. Maybe you can
compute on a like low complexity function so some noisy functions or something.
I'll give you some examples microbay a second.
And so this is kind of exactly what we are going to do. So let me talk a little bit
more about this leakage model. And from the purposes of this talk I want to
make the full distinctions. The first distinction is the last two bullets of the slides.
I'm going to distinction -- to maybe a distinction between restricted attacks versus
memory. So kind of green is better throughout the slides.
So restricted I'm not putting reference -- I'll put references at the end if I have
time. But people kind of can see it maybe the top one, the physical bits like
microbay this case more tampering but, you know, those work on like physical
bits maybe some kind of low complexity circuits, something, for example,
microbay complexity AC0 circuits, you cannot compute even parity or something
like that.
A very poor axiom variance of this axiom says this only computation leaks
information. So for example if you don't turn part of the secret key you cannot
leak on that secret key. And, you know, variance of this axiom like independent
leakage and so on. And so on. So this is also very, very interesting type of work.
The problem is of course it's not, you know, fully general and the second problem
kind of really forces you to be -- to still prove that to, you know, [inaudible]
particular kinds of things you need to know how the secret key's stored microbay
memory and so on. And of course there is this memory, what I call memory
leakage where you know it will say hey, look, any efficient function F is legal. I'm
not going to place any restrictions. So definitely if we can protect here, I'm
microbay great shape.
And of course the second very big distinction which is, you know, recently started
to be kind of more pronounced but, you know, it definitely is a very important
distinction, so informally they will call it one-time versus continual leakage. So
one time it didn't men that you can call the oracle only one time but essentially
just means that there is a a priori upper bound to how many times you call the
oracle throughout the lifetime of the system.
So overall, there is some leakage we call it leakage parameter capital L and you
can call the oracle at most like capital L times, and usually let's say capital L is
less than the length of the secret or something like that. Right? So this is what I
call one time schemes and continuous leakage schemes. So let's change one
more letter. It's unrealistic still. Maybe if my scheme is used for a while then
eventually the attacker will get more information of the secret key so this model is
kind of interesting. It's very, you know, at least to some beautiful theory. But still
this model might not be applicable. There are some relaxations of this model,
something called bounded retrieval model and so on.
But still this assumption is a long one. It's going to be problematic.
So the second line it relaxes the model a little bit to chief stronger security, can
say you know what we are, we are going to periodically refresh the secret key,
so, you know, initially let's say I will draw it kind of microbay different colors to
initially have the thread secret key and then some [inaudible] say well, you know,
maybe too much of the secret keys kind of leaked, maybe it's safe I should
refresh my secret key. So now it becomes kind of green. Maybe I'll refresh
again it becomes yellow and so on.
So then microbay between the refresh you still don't necessarily bound the
number of leakage queries so the amount of information that I can get about the
secret key. It against to look, if I refresh frequently enough, and I'll talk more
about refreshing microbay a second, this is hopefully realistic. But overall, the
overall leakage of the system is not leaked. So this is really what practitioners, if
you talk to [inaudible] other people also microbay practice, you know, I talk to
various people, this is really -- this is a model of a, you know, I contributed to a lot
of, you know, works but it's a nice theoretical model but microbay practice and it's
useful for this model, but really this is the model that, you know, partitioners want
because this is what realistic side channel attacks do.
Okay. So kind of to summarize, we have these two larger orthogonals. There is
some interception but largely orthogonal dimensions. You know, one time versus
continuous, restricted versus memory attacks. And very roughly there was a lot
of work, especially recently, starting from '09, '10, you can see a lot of references
here to these years. And I cannot like really cover all this work. But there has
pen a lot of very, very interesting beautiful work on all kinds of things.
But unfortunately so far, you know, this corner was pretty much untouched. I
mean, I will talk about what is known but not much.
>>: [inaudible].
>> Yevgeniy Dodis: AKA? Oh, that's authenticated key agreement.
>>: Oh, okay.
>> Yevgeniy Dodis: Yes, authenticated [inaudible] or something like that. Yes.
So essentially really if I want -- if I don't want to worry about computational leaks,
something completely unrestricted leakage but I want to have continuous things
so the secret key kind of updates nothing was known so far, and this is what we
tried to achieve microbay this work. So can we achieve the best of both worlds?
And throughout this talk that's what I'm going to call CLR, doesn't even
[inaudible] it means continuous leakage resilience, this is a model that you know,
we are going to try to get the first key microbay this model. Okay?
So just to recap or model of continuous leakage resilience, I mean, I kind of said
it, but let's be precise because random references and so on. The credit key will
be updated. It will be updated to only using local randomness. So I don't want
like any external servers so like time periods or something like that. I myself, on
my computer, you know, ideally hopefully using good randomness, we will locally
refresh my secret key.
Other users, they do not need to know that updates exist, they do not need to
know how frequent they are, I don't need to do updates periodically. It's
completely up to me if I think I am more compromised, I'll be able to update more
frequently. If I think, you know, I've been sitting at home and didn't do much of
[inaudible] update, it's completely up to me. Microbay particularly the public key
doesn't change because other people don't know, so definitely I cannot change
public key.
So for other people who don't know, it's totally my own local maintenance
procedure to periodically refresh my secret key. And no time periods, no
synchronized clocks, nothing like that. Okay. So clean model like that.
As I said, number of leakage queries will be bounded by the parameter L, which
will be less than the secret key microbay between the updates, but there is no
bound over the lifetime of the system. And.
>>: [inaudible] there's no leakage during the update?
>> Yevgeniy Dodis: I'll talk about it.
>>: Okay.
>> Yevgeniy Dodis: So I mean everything I, you know, work very hard,
everything I think I will be very surprised if there is a question which is not
answered on the slide.
>>: Okay.
>> Yevgeniy Dodis: But still feel free to ask questions. So there will be no
restrictions on the type of leakage. So these will be memory attacks.
So microbay intuitive way we will get our securities that our adversary, you know,
when he breaks microbay now he cannot predict my future randomness. So for
example he cannot do this, you know, future, this kind of predict realistic attacks
that you kind of break microbay, compute what would my key be like 20 years
from now, whatever, like and then for every new kind of break-microbay the
[inaudible] of my key 20 years from now. So very important question for the time
asked there are no leakage during key updates and practice is extreme important
that [inaudible] during leakage key update, but microbay our schemes, our final
scheme we'll have it. I'll talk about it. But microbay the basic model we'll already
have our hands full with the model where we do not allow any leakage during key
updates. As we'll see it's too highly non trivial because it's completely [inaudible]
there is no external server and so on. And the keys still have to remain
functional. I cannot just wipe out my secret key because you know, it has to
respond to a public key, it has to remain functional. So it's not a trivial thing.
But for now, let's assume that the updates are leak free and I will show you a
completely general theorem which will kind of allow us to generically go from this
model to the model that allows some leakage during key updates. But for now
this is great question.
And of course another thing we definitely don't want our schemes to have
efficiency which kind of degrades even logarithmically with the number of
updates. Yeah?
>>: [inaudible] erase the past secret key.
>> Yevgeniy Dodis: That's [inaudible] yes. So I do issue [inaudible] yeah.
>>: [inaudible].
>> Yevgeniy Dodis: Well, I mean even if I have -- yeah. I mean [inaudible] but
you can kind of put microbay perfect into this leakage, you can say look, I
assume every time I erase maybe like seven bits of my secret key is not leaked,
so this can be kind of formally model that I decreased it by seven and the
attacker also learns. So you can do stuff. But yeah. I assume, you know,
perfect.
So to answer this question it's very important. So I tried to be as precise as I
could about the model, but it's very important that you get it. Good.
So the worst may be [inaudible] but the most is most relevant to our problem. So
nothing was known is first iteration we had encrypted two years ago where we
kind of designed this one time schemes, you know, microbay the -- again, a
memory task.
And we know it is very trivial to hear of a variant of CLR signatures where the
updates require external master key which never leaks. So this master key is
only used like I put it on some, you know, external CD or something like that.
And I don't need it to run regular operations like regular signatures and so on, but
when they do updates, maybe I go offline or something like that. And I just
refresh my secret key.
And it's actually not completely trivial, but it's pretty simple. It's just pretty simple
way to take a regular signature scheme and the one time secure signature
scheme, you know, one time leakage resilient signature scheme and compose
them together. I'll let you think about it. But it's pretty simple.
So and then there is a very nice paper that I will mention a little bit at the end by
Vinoit [phonetic] and others also ends up counting forks. But their initial kind of
results that we knew before they started their work. They kind of had the, you
know, I would say semi heuristic indications that maybe actually this remarkable
primitive of continuous leakage resilience is possible. So they give a
construction of CLR signatures based on a pretty strong non-standard
assumption which for technical reasons they kind of, you know, use the hash
function inside this assumption but even if the hash function is modelled as a
random oracle you for technical reasons cannot prove security. But you can
make it highly non-standard assumption about PCPs and so on that will kind of
show that some extremely inefficiencies of our signatures might exist.
Which it kind of gives you some hope, but it's definitely inefficient, so it's kind of,
you know, what is the question, you know, can you actually really do something
useful?
So our results -- so we build CLR schemes under standard assumptions. Well,
the assumption is called K-linear assumption which is by now a standard
assumption bilinear groups. So we will use, you know, a little bit of pairing
operation. But as I said, well, I'll mention it on the next bullet.
So microbay the best schemes we can leak up to one-half of the secret key
microbay between our updates.
All the schemes are really practical, efficient. Well, they use pairings. But
essentially any scheme, you know, take a scheme which uses pairings, those
schemes will be essentially as efficient as that schema may be like 20 percent
slower, something like that. But it's not like some theoretical thing, it's a
complete very, very efficient schemes. Okay?
And which addition and continuously is resilient. And even though this
application is kind of the main application, is way we derive this application, we
build this primitive which is the most basic cryptographic primitive which is useful
but by itself maybe not that interesting. It's just one-way relation, which I'll talk
about the next slide. And once we build one-way relation, we will plug microbay
previous machinery, which is you know nontrivial machinery, but we'll plug
microbay machinery, previous machinery and kind of argue that it works with our
stuff and we get the small application, which is interesting stuff, but I really want
to tell you as a novelty, so we'll really concentrate largely on this continuous
leakage resilience one-way relation for much of the talk.
So let me tell you the definition that's kind of you can guess it, but let me be
explicit so that we're on the same page. So one away way relation microbay
general is, you know, there is a key generation procedure without -- with a secret
key and a public key, okay? And you know, there is a verification procedure,
some relation R, which kind of checks is the secret key really a public key and,
you know, under normal circumstances it should open. So that's great.
But the attacker who doesn't know, who only gets the public key is very hard, it's
computationally hard to find any secret key satisfies their relation. That is kind of
relation of one-wayness, but instead of one way functions we talk about relations.
General relations as opposed to functions.
All right? So this is a standard notion of security. So what we will want, we will
want to have [inaudible] relations but we will also want to have a new procedure
which didn't exist before, which is this randomization procedure which use only
local randomness which allows us to rerandomize the secret key, right?
And the correctness should be the new key, the green key should still verify so,
you know, we want to do it, you know. And we can do it as many times as we
want, you know, the efficiency shouldn't degrade kind of. And all those green,
red, blue, whatever other colors, all the keys should be good.
So this is just kind of correctness, kind of correctness requirements. Good. So
what about security? Security is exactly what you would expect. So the attacker
started with maybe the red key. He can ask up to L queries about the red guy,
what the second bit, what is like the third bit of SHA-2, the secret key, what's like
fast forward a transform like, you know, 17 bit or something like that?
You know, collect this information, get this part of the secret key. Now the key
for now is securely refreshed. But, as I said, we'll add randomness, you know,
leakage during randomness later. But for knew it's perfectly securely refreshed.
It becomes green. The attacker again asks question. It gets this, you know,
green guy. Now the key is refreshed to yellow. It gets you know passed to the
yellow guy. And for arbitrary not paranormal number of periods he gives this
information. So the total leakage could be unbounded, right. It's just bounded
microbay between the periods, right?
And now the attacker does a magic thing. He tries to combine the keys, you
know, to form a meaningful key and he isn't be able to succeed. Okay? So this
is a notion of continuous leakage resilience which is hopefully very nice
[inaudible] kind of, you know, abstract the novelty. Okay. Any questions? Okay.
Good.
So very briefly, kind of informally, what the difficulty of constructing one-way
relations, well, aside from the fact it hasn't been done. So microbay the
reduction, if you think about it, you know, you need to know many secret keys
microbay full. Because intuitively how else would you simulate leakage if you
don't know the secret key microbay full and you should be able to, you know,
answer arbitrary function? You kind of need to know many valid secret keys,
right?
Nevertheless when the attacker forges, when the attacker kind of forges a secret
key for their relation you need to solve some hard problem, right? So intuitively
what you want to hope, you hope the [inaudible] was a forgery is of a different
type than the kind of keys that you know. Right?
But the attacker gets unbounded now amount of information microbay total. I
mean, how do you ensure through this overall unbounded number of [inaudible]
the attackers doesn't learn of the kind of type of the keys that you know? Yeah.
>>: [inaudible].
>> Yevgeniy Dodis: Exactly. Microbay some sense. It's similar to the signature
paradox except here microbay some sense it's -- you know, well, I will tell you it's
even harder because there is this leakage queries. But, yeah, it's kind of for the
signature you necessitated to be able to force signatures of messages and hear
from a new message. You can do stuff but, you know, they can do more stuff.
You can change public keys and the reductions are here kind of the [inaudible]
the public begins to stay the same.
But it's very similar and if you manage to overcome this difficulty I'm just kind of
pointing out, you know, the difficulty microbay at least microbay particular non -you know, previous techniques kind of would fail precisely let's say previous
technique for one-time leakage won't extend precisely for this difficulty. Right.
So this is kind of [inaudible] but you know, we'll solve it. And hopefully I'll try to,
you know, tell you how we'll solve it microbay a general way before getting into
specific assumptions.
This is and outline. First I will tell you a general strategy which microbay some
sense will be the heart of kind of how to go from continuous leakage to one-time
leakage to more complicated problem, one-time leakage that was previously
nope how to solve but still going to be one-time leakage.
Then it will show how to relatively specialize but still general constructions that
[inaudible] specially encryption and no interactive zero knowledge proofs we
would be able to, you know, solve this one time leak problem and finally I will
show you an efficient instantiation of this component based on this assumption.
>>: [inaudible].
>> Yevgeniy Dodis: Yeah.
>>: [inaudible].
>> Yevgeniy Dodis: Yes, a bit leakage is definitely the secure update is trivial.
You can use [inaudible] or you can use generically. For any primitive you can
use something called asynchronous form. You store something big and then you
know is the attacker [inaudible] if you bits that your secret is kind of secure.
Yeah, so for bits -- yeah, and refresh is from -- it computes the secret and
encode it again. It's trivial. At least without leakage.
>>: [inaudible].
>> Yevgeniy Dodis: Yeah.
>>: During the refresh ->> Yevgeniy Dodis: So during the refresh I'll show some general theorem, but
I'm pretty sure microbay five minutes we'll come up with a scheme like that. It's
trivial.
>>: [inaudible].
>> Yevgeniy Dodis: [inaudible] is a difficulty, yeah. Not just bits as opposed to,
you know, anything else. Yeah. So clearly channel functions. Yeah. All right.
So let's start with this. So I'm going to give you -- so this is a strategy. So this is
a little bit -- I think the definition is very natural, but essentially I'm going to tell
you if I can define a specially kind of one-way relation which shares some special
properties, it will automatically be continuously secure. Okay.
So what is the kind of relation? So imagine this is a space of all possible secret
keys and there will be -- and, you know, we can always given a relation have this
blue said of valid secret keys. Those are secret keys just verified. This is a set
of valid secret keys. They [inaudible] of the secret keys verified.
But some who secretly a little bit too -- this side will be partitioned into good keys,
green keys, and bad keys, red keys. All right? So we'll of to design [inaudible] is
kind of the secret key is kind of secretly partitioned of the two sets.
And during key generation, not only do we sample public key and secret key, but
we can sample three keys which only use to improve the security, but they are
not used kind of microbay the scheme. But we can kind of sample three keys.
We can sample a sample -- a samG key, which intuitively allows us to sample a
random good key.
We can sample samB, which is kind of some key which intuitively will allow us to
sample a random bad key. And we can also sample a trapdoor so that we can
actually -- which actually can tell them apart. So that, you know, just which
essentially defines what is good and what is bad. Right:
>>: So what are the white keys microbay the picture?
>> Yevgeniy Dodis: Association this is invalid. So this is just a space 01 to -and if the secret key is 1,000, this is just all possible key. This is the keys that
don't verify. I mean they will disappear very shortly. I'm just saying this is a
global set of -- this is a domain of keys. Yeah. Secret keys. Good. So all right.
>>: [inaudible].
>> Yevgeniy Dodis: The key is a key which just allows me to actually to test.
Given a valid secret key it will tell me.
>>: [inaudible].
>> Yevgeniy Dodis: Is it green? It's just performing -- what does green and red
mean actually? I mean DK is a formal way to define what green and red actually
means. Good.
And also of course -- and we need the syntactic property which will allow us to
randomize. We still need -- this is already exist microbay CLR. They need to be
able to microbay the mind actually green keys. So given a green key using local
randomness I should be intuitively able to sample a completely fresh green key.
So intuitively this procedure around which is exactly the procedure which we'll
use, actually if it happens to get the key which is good, it's not going to sample
maybe -- it's essentially going to sample essentially a random good key. So
that's the kind of restriction, you know, so we will put microbay our rear end
procedure. Okay. So clearly so this is the kind of -- so this is the kind of, I'll tell
security properties microbay a second. But this is the kind of syntactic properties
that I want for now. Yes? Any questions?
>>: [inaudible].
>> Yevgeniy Dodis: Oh, no security properties yet. I'll put them on the next
slide. So there is no security. This is just syntax for now. Okay. Now security.
So I won't like two complementary properties, hardness of good keys and
hardness of bad keys. The hardness of good keys says that even if I give you
essentially a way to -- you can sample yourself arbitrary mainly red keys. If you
want I give you the sampling key for red keys. It's computationally hard to get a
green key. So given not just even [inaudible] I just give you red key, even give
you, you can sample as many as you want red keys, you cannot get a green key.
And the other way around. All right? So these keys are kind of from one it's hard
to get [inaudible] so assumptions very difficult. Okay? I mean very different from
each other.
And the new property which is microbay substance -- all properties are important
microbay the proof as you will see, but this is really the key property that will
allow us to push stuff forward. We call it leakage indistinguishability property.
And leakage indistinguishability property says that, you know, that adversary get
public key and he can sample both good and bad keys. He can do, you know,
whatever he wants. Behind my back I sample -- essentially it says that red keys
look like -- are indistinguishable from green keys.
I will pick at random one of the keys, okay, and I don't give you it microbay full
but you can get up to L bits of leakage about the key that I pick behind my back.
So you can learn a lot of information, but not all of the information.
And then you output an arbitrary key other key SK star and you win if SK star is
microbay the same category as the key behind my back. So essentially you are
trying to guess which key I pick behind my back, but you don't see it completely.
You see this. Well, of course just kind of to make sure that you follow what the
problem if you see it complete like microbay this property is impossible to satisfy,
you just copy the key, right? And so it's just, you know, just to make sure,
otherwise it's not trivial. Yeah, of course.
So there is red. So this is -- but this leakage is -- leakage microbay this thing
should be trivial. But it really doesn't say that it's hard like to copy my key. It
really says you cannot correlate because you can sample arbitrarily your own
keys. You really cannot kind of, you know, correlate intuitively it says that you
cannot correlate the category of your key, the ones that you come up. Because
notice you cannot even test yourself if your key is green and red. You know red,
but you -- you know, you cannot correlate it with a hidden key.
>>: [inaudible].
>> Yevgeniy Dodis: We're thinking about leakage normal liability, it's just normal
liability you know it focuses on one aspect but we really want to emphasize
because it's both indistinguishability and normal liability so microbay some sense,
yeah, it has aspects of both. We felt indistinguishability is a more important thing
to stress, at least for the [inaudible] but yeah. Yeah?
>>: You need another indistinguishability [inaudible] microbay the previous slide,
right?
>> Yevgeniy Dodis: No. Oh, yeah, this is -- [inaudible] but yeah. This is -- I view
the correctness property. But, yeah, sure. I view it more as a correctness
property. You know, the previous slides that if you just randomize the secret key
you get a fresh key. But, yeah, you can view it as security property. But I view it
as a correctness property. And there is no attacker, it is just, you know, good.
All right. So now I claim -- so we call it leakage indistinguishability randomizable
relation, short long and [inaudible].
And the important thing, look, this is a really weird primitive. I mean you have
this beautiful continuous leakage zero one-way relation. You know, natural
definition actually what you want. Now they give you these three new trapdoors
and so on.
The important thing is that this weird new property is a one-time property. And I
claim, and as we will see, as I will show you microbay next slide, anything which
is like this weird one -- satisfies these weird one-time property can do a hybrid
argument to get a rue usable property. Okay?
So let's see the proof. It's actually very simple intuitively, and it is really simple.
So let's start with the real experiment for continuous leakage resilience. So the
attacker sees, you know, only good keys randomized -- essentially we start with
the green key. Any other key [inaudible] randomizing it, it always is inside is
green stuff. And you get leakage from these things and so on. And then
eventually come up at a forgery, okay.
So I claim that your forgery must be a good key. Why? Because, look, if you
only see green keys and then you output the red key, you broke hardness of red
keys. Right? From only green keys you can come -- you came up with the red
key. That should be hard. Right?
So the forgery should be red. This is our first property.
Now I'm kind of going to play this hybrid game with the adversary. One by one
I'm just going to switch, you know, a key from green to red. Just one by one I'm
going to make this hybrid games where I just switch one key from good to bad.
And I'll see if [inaudible] notices. And I claim but leakage indistinguishability the
forgery, every time I do none -- one switch like that, the forgery should still
remain good. So it's kind of unlikely that, you know, I switch one key from red -from green to red and previously the attacker forged the green key and now
suddenly attacker forged the red key.
You said look, I assume he does it. That contradicts leakage indistinguishability.
Because the only difference between these two worlds is that one key
essentially, one key behind my back, you got L bits of leakage about the key, and
suddenly you manage to output the key microbay a different category. Kind of
you correlated with the categories that I had, essentially, you -- initially it was
green and now it changes to red, you started to get red.
So this is exactly leakage indistinguishability. And of course you say well, wait a
second, how do you get the other keys? And of course you say well, wait a
second, how do we get these other keys. [inaudible] even if you have your own
sampling keys. So those -- those keys and these keys you can sample yourself.
So this is intuitively. So leakage indistinguishability we allow it to do this hybrid
argument. And finally, all the keys are red. But the forgery still remains green.
But that the contradict the hardness of good keys. Because now microbay these
experiments all the leakage is from the red keys but you still forge the green key,
and that's a contradiction because green keys are hard to get from red keys. All
right? So this is -- any questions about this?
All right. So anyway, so this is maybe abstract them -- sorry. But, you know, it
really took us a while to abstract this property. So maybe looks trivial but it really
simplified us to kind of present our construction this way.
So now the construction based on PKE/NIZK, so this is the outline of the
construction. So we are going to use some magical, two magical encryption
schemes and you know, no interactive -- and I apologize. Hopefully you'll get at
least -- if you get even that part up to now, it's fine. I see the construction is
natural but, you know, fortunately it is, you know, somewhat technical. But it's
intuitive. So anyway, I have two public encryption schemes you know and a
special no interactive zero knowledge proof. And here is the syntax of my
[inaudible].
So my public key will be on a common reference string for the NIZK it will be two
public keys and a ciphertext. Essentially my public key is an encryption of a
random message. So ignore those other public keys. A public keys encryption
of a random message. Okay? The syntax of the secret key will contain another
ciphertext and a proof. And intuitively secret keys will say C2 encrypt the same
message. So C1 and C2 encrypt the same message.
But maybe the nontrivial encrypt but the proof verifies. So valid secret keys
means that P really proves that C1 and C2 encryptions are the same message.
Okay. So public key is encryption one of the message and intuitively secret key
should be encryption two of this message and approve. This is a good
encryption.
So a good secret key will actually mean that they really encrypt the same
message. So if you actually decrypt you get, it's not just the proof verifies
because maybe it's a fake proof. Maybe somebody forged the proof. But it really
means that they decrypt the same to the same message. Okay? And I claim
you can sample very easily from the trapdoor, which is M and R. So if I give you
the message and the randomness used to encrypt this you know the message,
you would just encrypt the message under the second key yourself, you have the
witness, R is the witness so you generate the proof yourself honestly so you can
easily simple fresh secret keys. Without using this trapdoor you can sample
fresh secret keys. Right? So this is good keys. And what the bad keys?
Intuitively bad keys are the keys which don't encrypt the same message but
[inaudible] verifies. And those are very easy to sample. You like encrypt
garbage. And if you have what is called simulation trapdoor [inaudible] for those
of you who know simulation trapdoor allows you to go forward with any kind of,
you know, valid proofs for [inaudible] so intuitively it will allow it to be -- to give
proofs of false statements. Okay?
So this is a syntax of the construction. We are far from done, but this is a syntax
of the construction. Okay? And distinguishing how to distinguish them, well, if I
give you two secret keys you can -- just decrypt and check if the message is still
the same. All right? So anyway, this is a syntax. Okay. Good. Now we just
need to briefly argue these properties. And it turns out some of them will be
actually not that complicated.
So let's start with the simple property, almost a trivial property, which the
hardness properties. All right? So this is a scheme. I'm sorry. Just truss me,
this is the same scheme. You know, encryption of random message, encryption
of random message proved. So I claim that PK1 is just semantically secure,
even one way secure, and pi is a sound proof. You cannot prove false
statements. The scheme has its hardness. Look, assume I'm giving you a
trapdoor to generate good keys. So you have the message and the randomness.
All right? And you need to produce a bad key. What is a bad key? It means that
you need to encrypt a different message and fake a proof.
Well, but that means you fake a proof. You produce the proof of a false
statement. That should be hard. Right? So given, you know [inaudible] it should
be very hard to fake the proof. Soundness isn't easy.
Now, if I give you a way to generate fake proofs the [inaudible] of this statement
doesn't really matter. How can you produce a good proof? Well, a good proof it
means that I encrypt the random message, I give you encryption of a random
message. Now what you need to do, you need to produce a different encryption
of the same message. Well, but if you produce a different encryption of the same
message it means that you [inaudible], you know, the encryption. Because I can
just decrypt it and, yeah.
>>: [inaudible] if the adversary has an [inaudible] has the encryption why can't
he just encrypt the same?
>> Yevgeniy Dodis: The adversary will not see it. Remember, this key is -- I'm
sorry. This keys are just [inaudible]. So I just need to tell you how to do a key
generation so that I simultaneously also generate this way to sample a random
good key, a way to sample a random bad key and this -- so the adversary -- I
mean, it sounds -- the properties adversary will get this key.
>>: [inaudible].
>> Yevgeniy Dodis: Sorry? Okay.
>>: [inaudible] M and R?
>> Yevgeniy Dodis: So it depends on which property. So microbay the property
of hardness of good keys, of hardness of bad keys he will get M and R. So he
will get M and R. But his job is to forge a bad key. What does it me to forge a
good key? It means that he has to produce encryption of a different message
and the proof it verifies.
>>: [inaudible].
>> Yevgeniy Dodis: He has a public key. Sure.
>>: [inaudible].
>> Yevgeniy Dodis: But he has to encrypt -- it has to be a bad key. Of course he
can encrypt a good -- you know, [inaudible] and produce a good proof. But then
->>: [inaudible] a bad message why can't he -- oh, because he can't make the
proof?
>> Yevgeniy Dodis: Yeah, because, yeah, he doesn't know the trapdoor to the
CRS. So he only gets a sample -- a good sampling key. He cannot produce a
bad [inaudible].
>>: Okay.
>> Yevgeniy Dodis: So he, on the other hand, he will actually get the trapdoor so
that he can fake proofs, but his job is to produce a good key, and that intuitively
means that he has to encrypt -- decrypt E1. He has to break encryption of E1.
Right. So these two properties -- yeah?
>>: Why cannot he just like bring it?
>> Yevgeniy Dodis: So what -- so intuitively -- well, because if he reencrypts, it
means that he decrypted the first encryption because I give you encryption of a
random message. I don't tell you. You produce a different encryption of the
same message. Right? I don't care if you know the trapdoor and some proof.
But it has to be of the same message. Under different public key. So it means
that, look, you could have -- microbay the first three -- microbay the reduction to
the security of E1, I can just choose a subsecret key for the set of encryptions,
can you produce an encryption of this thing? I encrypt it and I break the first
encryption scheme. Right? So these are like really simple properties. And so
now, you know, I'm going to do the randomization. So this is something
previously -- starting me to make serious assumptions. Yeah?
>>: [inaudible].
>> Yevgeniy Dodis: Of course, of course, yeah.
>>: Could we go back to the hardness and the bad keys? Saying the [inaudible].
>> Yevgeniy Dodis: Sure.
>>: [inaudible] he creates a ciphertext which is a new ciphertext but it's an
encryption of the same message he has the trapdoor ->> Yevgeniy Dodis: But it's a different public key. So E1 and E2 have
completely independent pees. So this is not -- it's not like I'm using the same E1
and you know -- it's not like I'm -- I use two completely independent encryption
schemes. So what I'm saying if you can do it, it doesn't matter if it's
homomorphic or not. Microbay fact, our schemes will have to be homomorphic.
I just break encryption.
So I get a challenge, encryption of a random message, I pick public key secretly
or for the second scheme myself, I give you that as a public key. You produce a
second encryption of the same message I decrypted. I said oh, great. I broke
my first [inaudible].
So the randomization. So now I will need to assume some special properties.
And if you think about it, what is our secret key? If you have a secret ski, our
secret key is the ciphertext and the proof. So I need to randomize the ciphertext
and the proof.
So the randomization ciphertext as you said, many encryptions will do it,
microbay fact if encryption is what is called homomorphic it's very easy to
randomize a ciphertext for many standard encryption schemes. Proof is a little
bit weird, because after we randomize C2, the statement for the proof changes.
The first part is microbay ciphertext remains microbay the public key, but the
second I just refreshed. So I need to kind of make sure that I need to update the
NIZK proof, NIZK for some old statement, a NIZK for -- a fresh NIZK for a new
statement. So it will be kind of nontrivial.
So here is what we are going to assume. We are going to assume that the one
and two and pi are homomorphic of appropriate groups. So for encryption
homomorphic is essentially natural. These three pluses are different you know.
They don't have to be the same. But intuitively it just means if you just add two
encryptions up, it's like encryption of some of the message and some of the
randomness. And essentially any encryption you study microbay the first course
like [inaudible] for appropriate meanings of plus will have this property. So this
is, yeah.
>>: What is the update [inaudible] obviously it can have a witness for the new
statement ->> Yevgeniy Dodis: So this is the next two bullets. So let me discuss. But great
question. Yeah, this is like the new, the novel stuff, right. It's like how do you -you know, you have a NIZK for one statement, now you refresh the statement
yourself, you need to update the proof. So this is tricky how you can do it.
So it turns out that there's a syntax just to make sure how is it even possible
without breaking the soundness of NIZK. So it turns out that the NIZKs that we
will use will be NIZKs for homomorphic languages.
So what does it mean as homomorphic language? It means that you have two
varied differences, X plus X prime is also microbay the language. So there are
natural languages which are homomorphic microbay this, and microbay particular
we will see one.
And I claim that a homomorphic NIZK for homomorphic language it means that if
you have two proofs pi and pi prime are proof for two statements X and X prime,
if you have add up the proofs, you simultaneous -- you right away get a proof for
X plus X prime, which luckily isn't the language. So it's kind of this knows only
makes sense for homomorphic languages because otherwise you break
soundness. But luckily because, look, this valid inputs, so they have proof, you
add them up, it's still a valid thing. So there is no contradictions that you can get
a proof for a valid statement. Soundness only says that you cannot get proof for
fake statements.
So this is just, you know, this is just a syntax that shows that it's conceivable to
have this homomorphic properties. Right?
And this is really inspired, this notion is really inspired by a paper of Mihir and
Melissa, which use the -- which you know we use the fact -- you know,
randomizable and malleable NIZKs. We kind of have to go just a bit -- once the
further [inaudible] we even change the statements microbay some sense.
But, anyway, it turns out that once -- the point is if you have both encryption
schemes are homomorphic which is easy to satisfy by itself, the language of -they both encrypt the same thing is easily homomorphic. It's easy to see that,
you know, if these two guys encrypt the same message and another two guys
encrypt the same message, he adds them up, they both encrypt the sum of those
two messages.
So this is trivial a homomorphic language. And now I claim it's very easy to at
least a statement is very easy to randomize, it's actually very easy to randomize
the whole thing. If we have homomorphic NIZKs and homographic encryption
schemes syntactically, here is how we randomize it. So C1 is part of the public.
I'm not allowed to touch it. So this should be encryption for the same message.
So I will randomize it. I will let the random encryption of zero. Okay? Well, but
let's look at the resulting ciphertext. I can write it also as C1, C2 plus encryption
of 00, encryption of 0R. Right? I mean, this is just because the encryption is
homomorphic.
So for this I have the proof. For this statement I have the proof. But I don't have
any witnesses. I don't know anything. But here this is essentially an encryption
of 0 for which I now have a witness. What is the witness? It's 0 R. R I chose
myself. Right? So essentially the new statement I got is the old statement plus a
statement for which I know the witness. So what I can do, I can generate a fresh
NIZK for this statement, at it to the old NIZK, and I get a valid NIZK.
So this is just syntactically the [inaudible] of these properties I can randomize
syntactic stuff. Okay. So [inaudible] I should finish soon. Okay. Maybe like
three minutes. I'll skip a lot of things.
So anyway, this is like the important thing. Okay. So maybe like three minutes
on the most important property. This is kind of the key new property that we get.
So this is at least we manage to show that we have these magic things we can
have -- this property now is a novel property. And intuitively the novel property
needs something from E2. Pause I used everything else, all right. I used
properties. Encryption schema 1, I use the soundness and so on. But I didn't,
you know, use anything about it too. And it turns out if you just run the definition
of leakage indistinguishability, here is a new security property from E2 that you
need. So this is a security property. It's very cute.
As you will see, it's precisely microbay between chosen plaintext and chosen
ciphertext security.
The property is this. That given intuitively L bits of leakage over the ciphertext,
so usually you see the ciphertext. Here if you only see some partial information
about the [inaudible] ciphertext, you cannot produce a related ciphertext.
So formally the [inaudible] public key, he chooses two messages, challenges and
encrypts one of them, but instead of giving the full ciphertext to unable the
adversary gets only L bits of leakage on the ciphertext. So you cannot see the
entire ciphertext. The attacker has -- essentially produces another ciphertext C
prime. It makes a encryption query of this C prime and [inaudible] the encryption
of C prime says V is equal to B.
So it's not very hard. So we call it L leakage of ciphertext normal liability. So
intuitively it's kind of you know it's kind of a [inaudible] notion. And it turns out it's
not very hard to see, that it lies -- it's precisely microbay between chosen
plaintext and chosen ciphertext security. Just kind of -- this is kind of cute. This
did actionwide [inaudible] here because if the scheme is even one leakage
non-malleable security, so you can say, look, assume the scheme is not chosen
plaintext secure. How do I break this? Well, I look at the ciphertext, I have a
distinguished [inaudible] encryption of zero, of encryption of one. That's my
leakage function. I look at the ciphertext. I just [inaudible] whether it's encryption
of 01 and I break the scheme. And I just reencrypt let's say 01. So it's kind of
iteratively that this notion implies chosen plaintext, just a little bit less trivial but
also microbay two minutes you can see that normal liability implies this. And the
challenge of course you can say oh, great, just use non-malleable encryption.
But remember, we need the encryptions to be homomorphic. Right? Encryption
has to be homomorphic for the syntax. And this is a new property that we need.
So the question is is it possible to have this thing. So CP is iteratively to do
homomorphic, right, but it's not probably going to be non-malleable.
This is leakage nonmalleable, but it cannot problem be homomorphic. Can I do
something microbay between?
Okay. And this is kind of -- so anyway, this is a summary maybe I'll skip. But
essentially we show that everything will work out if we have E1, E2, and 5 which
are homomorphic and we do have this novel property and -- okay. Microbay one
minute I'll wrap up. So it's very nontrivial to instantiate those things. I just
wanted to give you the summary of this construction.
So luckily homomorphic NIZKs there is this paper of Groth-Sahai which happens
to be homomorphic. It's just beautiful paper. But it's only for restricted classes of
languages. But likely it is [inaudible] powerful enough for us.
It's secure under the K-linear assumptions. That's why we are stuck with K-linear
assumptions. So this is a magic box with essentially, you know, pushes this
thing through. But there is a lot of other work as you see we need to be done.
Anyway, this is a reasonable assumption so given what homomorphic encryption
E1 is trivial, just use a Gamal encryption or you know, it's easy to generalize it for
K-Linear. So if we got K-Linear for K equals one is just a DH assumption. So
just assume DH assumption. And for E2 it turns out that we can use
Cramer-Shoup-Lite encryption.
So for those of you know who -- so there is a full Cramer-Shoup encryption,
which is not homomorphic intuitively because there is this component which, you
know, is like hash of something, and it cannot be homomorphic because CCA-2
-- there is a CCA-1 version of Cramer-Shoup which is Cramer-Shoup-Lite, which
is easily homomorphic. There is no real components. We can just multiply those
or just propagate. But it's only CCA-1 security microbay general, it didn't apply
normal liability. But if you look at the proof -- I mean, I'm not going to tell you
intuition but it's not very hard microbay two minutes. I wouldn't be able to tell you
intuition. It's just, you know, [inaudible] easy adaptation of Cramer-Shoup proof
shows that he has this incompatible property of leakage normal security and it
gives you leakage one-quarter, but you can kind of add more elements microbay
the public key and you can get like one minus epsilon leakage normal liability.
So anyway, to conclude, so this is what we have. And then we constructed L
leakage resilient one relation based on K-Linear assumption. The leakage is
roughly speaking one over K plus one, depending. But you know, the
assumption is [inaudible]. So the highest case, the lower the leakage but the
more believable the assumption is.
And it's really practical efficiency. There's a constant number of group elements,
a constant maybe like 40 but you know, it's a constant. But I mean, there is no
PCPs, no [inaudible] deductions or anything like that. And this application, as I
said, using -- heavily using prior work adapted to continuous leakage setting will
show how to build the scheme. And it's -- that was actually very surprising.
Especially for signatures [inaudible] so this was actually a highly known trivial
bullet, but it's only one bullet but there's a lot of work microbay this bullet.
And okay. We won't mention -- I'll talk offline about leakage during key update.
We cannot [inaudible] if we're following implicit observation of this very nice
paper of [inaudible] that if you have a scheme which is L leakage resilient without
any leakage during key updates you can kind of treat one bit of leakage during
key updates if one bit of leakage inside key update. But unfortunately you pay a
factor of two over K microbay security [inaudible].
And this is -- it's a very cute but it's totally trivial observation if you think about it.
Corollary is that if you have an L leakage resilient scheme microbay the Q setting
it's automatically -- it can [inaudible] all the log of security parameter leakage
during key update.
So the moral is unless you break this barrier, which is a very difficult question, it's
a great open question to allow higher leakage during key updates, but unless you
can break this better don't even bother with the more complicated model, just do
it clean beautiful model which is already complicated, you know, and then
automatically for free get security with leakage during key updates. This is a very
practical and foreign thing, so it's actually very important that our schemes or any
other schemes that you can come up microbay the future will satisfy this property
from encryption signatures or anything you want. So this is kind of for free.
Okay.
We have other extensions, leakage of randomness during computation, you
know, all of those are nontrivial but it turns out that our scheme happens to
satisfy them with our work. So for example during signing, for one variation there
is more randomness, more local randomness, it's just you have a secret key to
verify it. But if you sign messages, you know, the signatures could be
probabilistic. So maybe not only your secret key leaks but the randomness
during signing leaks.
Or for key agreement you choose G to the A, G to the B, maybe those leak and
so on.
And so it turns out that there's some nontrivial work. We manage to do it, put
unfortunately our signature and ID -- sorry, our ID schemes and AK are only -sorry, signatures microbay AK are only a random oracle model, ID schemes as a
standard model. So, and you know, there are some more extensions. So there
is a very nice paper of Vinoit which unfortunately he is not going to talk about
here, but it shows how to extend -- I mean, it's totally different scheme, you know,
beautiful techniques. But they also show how to get continuous leakage resilient
public encryption and even like more stuff like AB. And it leads also to an
alternative construction of continuous leakage resilience one-way relation and
signatures. Ironically and implicitly when [inaudible] had like a very long like 50
page, you know, proof of this kind of thing, implicitly they also build a [inaudible]
so implicitly they, even though they do encryption, but if you look at the public,
the secret key relation it also builds a new leakage indistinguishable
randomizable relation. And ironically it's very different technique but they use the
same assumption. They don't use explicitly Groth-Sahai proof but algebra they
use based on the same assumption. There is some magic from very different
angles, you know, they came up with same schema. And even the schema is
also very nice. The schema has better leakage, one over K as opposed to one
over K plus one that we have and it is kind of the observations that we have
microbay proving a slightly you know bounds that I originally had.
So anyway, so this is state of the art and I'm sorry for, you know. The paper is
available.
>>: Let's thank the speaker.
[applause].
>>: [inaudible] offline for the break and then we'll resume at [inaudible] microbay
six minutes. Ten minutes. Okay.