>> Kristin Lauter: Okay. So this morning we're very pleased to have Mihir
Bellare from University of California San Diego visiting us. He'll be speaking on
cryptography from theory to practice. Mihir Bellare is a well-known cryptographer
who along with Rogaway defined the random oracle model. He's also a
co-inventor of the HMAC algorithm which is widely used in industry. He is a
recipient of Packard Fellowship and an NSF CAREER award. So we're indeed
very pleased to have Mihir visiting us here today. Thank you.
>> Mihir Bellare: Good morning. And thanks for the kind introduction. When I
was given the opportunity to speak here I had several choices for what to do and
I thought maybe people are expected to give some kind of big vision talk, but I'm
not much into these nebulous visions, so this is more for pedagogic talk. And
rather than try to select one specific result to talk about, I thought I'd consider
broader topic and which is to look at cryptography through the lens that is
motivated most of my work which is bringing theory to practice.
And I apologize in advance to the experts in case a lot of what they see is
something they know or also for the fact that to make things simple I mostly
selected relatively old work for examples but I'm happy to discuss new work in
person.
So with that cryptography from theory to practice and with great thanks to Tom
Ristenpart [phonetic] for his Power Point magic that makes this possible. So let
me just begin by asking if you used any cryptography recently? And I'll venture
that whether you know it or not, you're likely to have done so. Something that
was once largely a military interest is now in widespread use. You can figure this
out any time your URL changes from HTTP to have an S at the end, indicating
use of the TMS or SSL protocols or some of the siblings which are widely used
for Internet secure communication.
So also, for example, if you make an Internet purchased where you pay with a
credit card you'll be using cryptography in these ways. But even prosaically
every time you use an ATM machine you use cryptography.
While preparing the talk, I was channel surfing and interested to find that even
shows up in James Bond movies where one of the bad guys in this one talks
about using SSL. It's hard to get more popular than that.
So what is the subject about? The core problem is communication over an
insecure medium and there are a couple of different goals. One of them is data
privacy which means we want to prevent the adversary who is in control of the
network from seeing the content of the communication and the other one is
integrity or authenticity which means that we want to ensure that the data
received originates from where it claims to and wanted modified in transit.
And these goals apply to pretty much all kinds of settings you could think for. For
example bob could be a doctor requesting a medical record from Alice the
database. The privacy ensure that the -- the sensitive contents and medical
information are not revealed and the authenticity ensure that the record really
originates with it database and not someone else.
If you're transferring a credit card number over the Internet then the privacy
relates to the fact that the number itself isn't made known and the authenticity to
the fact that the credit card number originates with the right [inaudible].
To achieve these goals cryptographers construct algorithms which process the
data so what's actually transferred is a cypher text, and these algorithms operate
under the influence of keys. There's several settings for this. If the key being
held by the two parties is the same, we call it the symmetric setting and we also
have an asymmetric setting in which the encryption key and decryption key are
actually different and moreover the encryption key can be known to not just the
address but any potential sender which makes it more flexible but also more
expensive.
So some of the rules of the game here are that algorithms should be considered
objects that are known, the public standardized and present in software so any
security comes out of the secrecy of keys.
We can distinguish here between computer security where the goal is to protect
the system on which the cryptography is being executed and particular protective
the keys from exposure due to system and software holes, and cryptography
which kind of assumes that you have a secure system underneath you and is
worried about how you use these keys and build the algorithms for it to get
secure communication on the network. And it's the latter that I'll be concentrating
on not because the former's not important, but just because this is a good
distraction boundary to draw and the fields are different kinds of tools and this
happens to be my expertise.
So the questions we're interested then is how we design these algorithms to
achieve whatever security goals we have and we tend to call these algorithm
schemes or protocols. What makes cryptography hard to get right is that it has to
with stand attacks and attacks it's hard to predict how someone's going to try to
attack your scheme. And failures do occur.
For example, the web wireless protocol had some poor cryptography which
resulted in pretty well known failures. Failures are costly for two reasons. One is
the publicity, negative publicity, and the other is changes to software which are
expensive. So a lot of the goal of cryptography is to try to prevent failures. A
classical way to do that is to begin by analyzing a scheme and then attempt to
break it. And if you succeed in breaking it, well you iterate until you can come to
a point where you have a scheme of which you feel reasonably confident.
The people who attempt to break these schemes are called cryptanalysis and
their expertise is to mimic attackers and try to figure out what the weaknesses
are. And eventually one hopes to come to a scheme where these experts don't
really have a way to break it.
What one needs to understand about this process is that the confidence they're
getting in securities is somebody's view that they themselves can find an attack,
it's not an indication that attacks are guaranteed to be absent. And I can raise
certain concerns about this approach. One of them is that we achieve our
confidence by trust in experts. That's not necessarily a bad thing, but some of
the -- its difficulties are that it doesn't scale well.
There's far fewer of these experts than we have schemes being created. So for
example in Microsoft you're lucky to have Neils Ferguson [phonetic] who is one
of the experts in this area. But imagine if every single crypto containing product
had to be passed by him before you deployed it? It would simply become a
bottle neck in the process. So we'd like things that scaled better.
And unfortunately many people think that they can do cryptanalysis quite well
and try to do it on their own and then they get it wrong. So the ultimate
methodology I always like to consider begins with the people here at MIT and
when you start using it you probably begin the same way as before, you design
some scheme you try to break it and you iterate until you get to a scheme that
seems reasonable in the sense that you probably can't find an attack.
But you don't stop there. What the methodology that they develop can do is offer
you some kind of proof that not only can a certain person not find an attack but
there's some sort of evidence that other people are not going to find it either, and
the advantage of this is that you get some core sort of verifiable certificate of
security which you can check and can -- and allow other people to check and
there by gain confidence in the algorithm.
So there's a few there that I'd like to explain more depth about this methodology,
in particular why it says and what it means that nobody is likely to, not that they
actually can, and secondly how you can possibly get proofs for security.
So we start with some desired end goal which is to design the schema called Y
and it might be for some task that we want to do over the Internet like encryption
of data or authentication of data. Now, historically people may have approached
the task of designing the scheme by simply sitting down there and starting to
write some algorithm, but modern cryptography doesn't do that. What we have is
a set of tools or problems from which we start and view those as something we
call atomic primitives.
They might be mathematical problems or they might be certain constructs that
have been engineered by cryptographers. As an example, the factoring problem
is that I give you a composite number and ask you to find the factors. Now, this
is pretty easy for a small number, but once it against big it's hard to figure out
how to do it and there's a task that as far as legend goes as it even daunted
Gauss and certainly no one's done any better so far.
The difficulty with something like this is that it's not a cryptographic solution, it's a
mathematical problem to solve -- to factor a big number, and we need to see how
we can actually use that to encrypt a large file. So what cryptographers do is
transform these atomic low level primitives into high level ones. And when we
talk about proof, in particular about security, we're largely we're concerned with
the security of this transformation process. Historically or empirically it turns out
that atomic primitives tend to be much more stable and secure than the schemes
we built for them. There are relatively few of them and although they're
sometimes subject to attack, they're studied in depth by experts and we can have
reasonable confidence in them.
But the number of schemes that people are designing on them is huge. In
Microsoft there are probably hundreds of pieces of cryptography at this end of
the spectrum but they all use this transformation process starting if the small set
of primitives.
It seems that we tend to put bugs in when we do this transform and what the
proof process does for us is say that this transformation process works in the
sense given here of a reduction which says that if you give me any way to attack
this scheme by some adversary I'll call A sub-Y, then I have a way to turn it into
an adversary that attacks the scheme. Read backwards it means that if you
have confidence in the atomic primitive, it automatically translates to confidence
in the higher level primitive. And the advantages of this are that not that you've
done away with cryptanalysis but that you've confined it to a smaller set of things
so that the cryptanalytic talents in the community are not kind of spread out and
wasted over too much stuff but can be used on the things that actually matter
and the rest of the confidence can come mathematically.
I'd like to point out that sometimes people who look at proofs of view as
anti-cryptanalysis that's really not my perspective. What I'd rather believe is that
cryptanalysis is an important and valued trait in the community and what proofs
do is leverage it better rather than allow it to be kind of dispersed across too
many things.
One of the center pieces of what this methodology is about is that when we use
the term of breaking something, it has a precise definition underlaying by a
precise model and the consequence of that is that we know what assumptions
we're making and against what class of attacks were secure.
So you get a much better understanding of what kind of security you are getting
from this process. Provable security isn't [inaudible] will give you many examples
of provable security schemes he's broken. Some of the reasons things can go
wrong are that although you did provide a formal model it didn't capture some
threats that were later seem to be relevant. A neat little example of this is wins
encryption which are shown to meet certain security notions in theory but they
didn't cover the attacks that could actually be mounted in the system and hence
was broken.
Another example is attacks that go outside the model by looking at things like
the -- the time taken by your program to execute are the variation in its power
consumption and things like that. And if your models didn't take this into account,
well then it will fall to these threats.
You have to implement it correctly. Didn't have to have a proof if you don't. You
do assume your atomic primitives are good. If they aren't and that happens
sometimes the most spectacular case recently was when collisions were found
for hash functions then of course all bets are off. If you get a proof you better get
it right, otherwise it's also worthless.
One of the things I often feel about the way we do proofs is that I can't verify
some of the proofs in the literature as dubious how valuable they are in this case.
But even given all these caveats, I do feel that probable security is valuable. On
the whole it can give you increased confidence in scheme security and it's
something that people can learn to use and be educated about in a way that's
more difficult for an art-like cryptanalysis which is somehow requires just a kind
of cleverness which you don't necessarily need if you just have to check proofs.
Provable security is good in that it makes clear the models and assumptions in
use and can be communicated. As a rough analogy in case you don't know
about this area much, proof of security is very much like an NP completeness
proof. It's not telling you -- if you remember the story from Gary N. Johnson's
book, your boss asks you to solve some problem and you come back the next
day and you say you don't know how to do it and he's not very impressed, but
then you say I don't but nor do all these famous people because it's NP
incomplete equivalent to all these other things.
It's somehow the same principal. You're seeing that your scheme is secure
because if not then a lot of the problems and a lot of clever people like Gauss
have studied would become easy and we don't believe that. Okay. So that was
kind of a background. My story begins here. I was a graduate student at MIT
where we learned all about the theory and the beautiful framework for proofs and
all kinds of notions and generally we're giving the impression that we could solve
all the world's problems.
And after that I got a job at IBM in a group which was working on a high speed
network and it felt like they wanted a cryptographer and what I found was things
are extremely different. The kind of cryptography in words we were seeing in
paragraph were things like block cyphers, DES, things like CBC encryption or
MAC, lots and lots of standards for doing cryptography. Protocols for session
key exchange. And when one looked to see what the theory had to say about
this, well there also is basically nothing. None of these things were covered in
theory. A course at MIT didn't give a mention DES. They don't -- and there didn't
seem to have any knowledge or interest in these kinds of topics. That didn't
mean that they were idle. There was an entire framework of cryptography in
theory based on assumptions like one way functions achieving goals like zero
knowledge, talking about proven security public encryption and signatures.
And when one looked to what was happening with that in practice, well basically
nothing. No one was using that or seemed to be influenced by anything like that
at all. And this was the gap that kind of motivated our work, and my work with
Phil Rogaway was about bridging this gap. And what we did was provide
schemes for which we could give proofs but which reflected practical constraints
and problems in a way that made them usable.
And if we want some very simple let's say oversimplified view of what the source
of the gap was, you could say it's effectively performance. So theoretical strings
were slow and practitioners lien at things that are not faster. But this gap wasn't
something that you could change by writing faster code or something like that, it
was the gap was enormous, it was factors of millions and billions and more than
that. And what we found was that the gap didn't arise from say levels of detail
but from major cultural what I would like to call cultural differences in the way
these two communities looked at things. And it's -- I'd like to examine those
differences and what we have been trying to do to change them to bring this gap
as kind of the focus of my talk.
So one of the main and first differences we found was in what people viewed as
appropriate atomic primitive. So remember the atomic primitives are the things
you start with as given before you start building schemes. In practice, we saw a
set of primitives that were built by what people call the confusion diffusion
paradigm, which means that they were engineered by cryptanalysts who studied
them and tried to make them secure and included things like block cyphers and
hash functions.
What theory was using is things arriving from mathematics like one way functions
fact indiscrete log, RSA and things like that. And if you ask the theoreticians their
general view of what practitioners use as primitives was quite negative. They
thought of them as ugly objects which really shouldn't be looked at and had no
place in the theory. The answer of the practitioners was well if you think our stuff
is so bad, why did you try to break it? And by and large that turned out to be true
in the sense that these things were not broken and that performance gap
between these things was incredible.
So it would seem unreasonable to say that this group of people should move to
this viewpoint. Now, the reason I call this a cultural gap is that the theory
community hadn't looked at what the practitioners did, analyzed it and decided
that it's bad. It was at some sort of level of taste that they viewed these things as
something that just shouldn't be considered. And it reflects probably just the
origins of this community in complexity theory in mathematics whereby
engineered objects which are built by hand based on principals that are maybe
sound but held implicitly by experts was just somehow not to their taste.
Now, another confusion I might eradicate before I go on, is that from these
callouts you might think these groups of people actually talk to another -- each
other. But they never did that. Whatever I've seen here are things that they've
said to me when I asked them questions or communicated to each other. So
what Phil and I did is to bring these types of primitives into the fabric of provable
security by supplying appropriate definitions and models under which you can
use them and once we did that what we found is you can build cryptography just
as well on the back of confusion diffusion as a number theory.
And this is a gap which in fact one could spend an entire lecture on. In many
ways once you start looking at it, you see that these primitives have greater
strengths than the ones here. They have different varieties of strengths, ones
which in some cases are harder to capture by models, but which seem to be
present, and also there are strengths simply due to the fact that crypto is just a
much higher targets, they expect things in some sense to be much stronger than
in this domain. And that's why things are often viewed as broken here which may
not really reflect weaknesses.
I'm happy to say that subsequent to our work this has relatively standard so by
now a lot of people in the literature use our assumptions and methods to work off
these kinds of primitives and build probably secure schemes on them. A second
cultural difference we found is in concrete versus [inaudible] security. The way
theoreticians model security is to have a parameter called a security parameter
which goes to infinity and so that any scheme is actually a collection of schemes,
one for every value of this parameter, and the advantage of an adversary which
is a success probability is a function of the security parameter.
In practice, however, many of the primitives have no parameter going to infinity.
The AES block cypher has 128 built keys and input, outputs, and that's all there
is. What theoreticians dub security is to say that they have schemes where
polynomial time adversities can't break it in the sense that as the security
parameter goes to infinity, so does the success probability.
Now, they have a specific definition which says that the rate at which this function
goes to infinity is something. In particular it's less than the reciprocal of any
polynomial and that's called an negligible function. The difficulty with this
approach is that if you want security like practitioners do, well say well, we want
to know when you have an attacker that has two to the 50 running time and we
want to make sure it doesn't have this much success probability is in principal
this tells you nothing because all it tells you is that as the security parameter
goes to infinity things get reasonable and it's not clear what polynomial time is in
the context of two to the 50.
Now, again, one of the reasons I called this gap cultural is that it's not as though
there's an enormous technical difference between these two. It's more that the
people who develop theory had the origins and complexity theory and viewed
cryptography as an extension of complexity classes like P and BPP and NP. And
to them it was natural to translate that framework into the definitions here so that
you got polynomial time adversaries and security parameters which function just
as the length of the input in complexity theory.
And they just somehow didn't feel like they could develop a theory around things
like this. And our contribution there was to produce -- is to bridge this gap by
producing provable security statements in this type of framework by appropriate
models and definitions and results.
Now, again, this is a perspective -- this gap is something one could spend a
whole lecture on, but it is kind of interesting in the way that it developed. Once
the culture of theory was fixed to this, a large fraction of them followed it, you
know, continuously after that without trying to make a change. But nonetheless,
some fraction of the community has since switched over into a viewpoint and into
concrete complexity in particular for example work on [inaudible] base
cryptography implies this.
Now, in this -- another way to look at this gap from my perspective is to consider
the theoretical compute science has people working in complexity theory and in
algorithms. Algorithms are people who care about whether an algorithm runs in
time N cubed or rather N squared logN which are highly different to them.
Complexity theory is largely care whether something in polynomial time or not.
In some sense cryptography never developed an algorithm's community, it
stayed a community where people were interested in polynomial time as
opposed to finer grained measures of efficiency.
It's also -- you can see cryptographers improving efficiency and giving, you know,
algorithms which are computationally more efficient but when they disregard
concrete security that actually turns out to be effectively vacuous and this
[inaudible] understood to do greater next time. Anyway, our final gap here was in
goals. Theory tended to focus only on public key cryptography in public key
encryption and signatures and then lots of fascinating higher level goals like the
ones listed here. But 90 percent or more of the cryptography that actually goes
on in practice is in the symmetric setting and there are also problems like session
key distribution which I found seems to have more incorrect protocols than any
primitive I've seen in cryptography and was not being addressed in theory at all.
And the theoreticians viewed symmetric cryptography is kind of a special case of
asymmetric, isn't this something just stronger. In fact, the view isn't even correct
in the sense that even definitionally they are not the same but the performance
gap is huge due to the fact that you can use confusion diffusion primitives this
gets, you know, thousands to 10s of times thousand times faster than the most
basic asymmetric encryption.
So our focus was on developing solutions and definitions and models in this
domain. Okay.
So the rest of my talk is a bunch of examples to illustrate these ideas more
concretely and talk about some specific results and I guess I'll go through as
many of them as you have patience for and then stop. The first one is about
encryption. So I want to first talk about the basic underlying perimeter which is
block cyphers. So block cypher is just a map which under the influence of a
question transforms the input of some block length B, say 128 bits into an output
of the same length, and if you have the key, you cannot only go forwards but
backwards. DS for example has certain parameters of key and block length, the
modern AES has different ones.
And how do these things work? Well, there are -- that's again a topic for a book
or something. But here, program, is a high level description of the AES cypher
and as you can see, it just kind of operates through rounds each of which
mangles the bits of the input and the influence of the key and here this one relies
on numerous subroutines that are not going to talk about. But maybe it's enough
to get some kind of favor.
Traditionally when people have discussed security what they mean by this is
security against key recovery. All the security comes from the key and what we
want is [inaudible] of input-output examples as the cypher you should have a
hard time figuring out the key.
One of the things I will do is update this view, and that's part of our push to
develop models for atomic perimeters which are useful to get -- to show security
the angles. We'll have to update this one.
Now, naively at least a block cypher allows you to encrypt. If I have a B bit
message I can encrypt it by applying the block cypher under this key and send it
to Bob. So why aren't we done? Well, just for a simple pragmatic reason that
you couldn't buy this method only encrypt 128 bit plain text. And that's not what
you want. You want to encrypt longer messages.
So we do that by something called modes of operation, and this is where we can
see the this sort of paradigm that have been discussing in March. In this process
we view the block cyphers and atomic perimeter and we are aiming to construct
by some transform some perimeter that's more directly useful for applications
and which we call a symmetric encryption scheme. So and that, too, is a process
that takes a key and process an input to an output but the difference if a block
cypher is that the message has arbitrary length and the process could actually be
randomized.
Now, there are numerous choices for how we might do this transform and build
the encryption scheme. And here are the most common ones. The electronic
code book one is the most obvious. You just break your message into blocks
and apply the block cypher in each block.
A little more involved is cypher block chaining and its most interesting feature is
that every time you encrypt you pick a random number and you -- and that
random number influences this process as chaining as shown in the picture. The
cypher text is longer than the plain text by including this random number and it
turns out although it's not shown here that if you have the cypher text and the key
you can decrypt this thing.
So then the questions we would have about these things are the secure is one
better than the other, so forth. Now, it turns out that CBC encryption is in some
sense the world's most used encryption scheme. That's the one that's deployed
or some extensions of variance of it are deployed pretty much everywhere and
that's how things got encrypted. So to -- so what Phil and I were interested in
was understanding how secure this is and its impact on real world's cryptography
is really pretty immense.
So to answer that question, we -- here is where we kind of step back to take a
theoretical perspective is we wanted to first know exactly what one means by
something being secure. The traditional idea was the same as for the block
cypher, which is that if you had some inputs and outputs you couldn't figure out
the key.
Now, under this metric electronic code book mode is actually secure because
having input and output examples and trying to figure out the key is no different
for the encryption scheme than from the block cypher. So if you believe you
have a good block cypher, this is a good encryption scheme. And yet
practitioners for a long time have already understood that electronic code book
mode is bad and looking at why this is is useful to illustrate that security goals are
things that you need to kind of formulate with more care. So let's do that.
So across the lake in Seattle they have [inaudible] for example on a proposition,
which is worth quite a bit of money, and let's say that the vote was being
encapsulated in the following way, so let's say you submitted your ballot at some
polling station and let's say this polling station shared a key with some tallying
center and when it caught your vote it encrypted it and sent it across and let's say
that they encoded votes is one block strings. So ECB now simply comes down
to an application of the block cypher, so if Elaine's vote was yes, this is what
would get transmitted. And let's say Jerry had some other vote V 2 we don't
know its value yet, and this is what will get transferred.
What you don't see though is even without knowing the key or without computing
it, it's very easy for this person to figure out what this person voted because this
process is deterministic and if V 2 was equal to Y, C1 would equal C2 and
otherwise it wouldn't because this is a permutation.
So just by examining whether or not these two things are the same, all security
here is lost. Elaine can completely figure out what Jerry's mode is. So this is the
kind of thing that we consider a flaw in the encryption scheme and would like to
avoid. So that kind of throws this encryption scheme out, but we'd like to analyze
other ones. Now, in order to go further with that, though, we'd like to pin down
more precisely what the security goal we just discussed is. And for that
cryptographers create formal models and I thought I'd try to illustrate one of
them.
So this is the definition that Phil and I gave for symmetric encryption, and it just
imagines a game in which you have an adversary and its interaction with the
encryption scheme is a certain oracle. The adversary can produce not one but
two messages of its choice and ask the oracle to encrypt. And the oracle will
encrypt fought both of them but one of them. The only thing is it won't tell the
adversary purely which of the two it's encrypting and the encryption is done
under the key the adversary doesn't know.
At the end of this process, the adversary can make many such queries. At the
end of that it's going to try to figure out which of the two was being encrypted.
That's all it's trying to figure out. Now this is a relatively simple extension of the
same definition given by Govash and Nicolli [phonetic] in the asymmetric setting.
But there are some differences in the symmetric setting, in particular the fact that
you need these oracles because the keys are hidden.
We assign a measure of success to the adversary. It's not the probability that B
prime equals B because that can always be a half by a simple guess, but some
reflection of the extent to which this probability exceeds one half. Already here
we're seeing a concrete security approach because in theory nobody defined this
function. They would just say that the difference of this probability to one half is
negligible or something like that and nearly writing this down will enable us to do
more of that.
So this advantage measure is going to depend on a number of things like
strategy but also will by how -- on how many queries it makes, how much
computing time it has, and so forth. And so when we talk about security, use this
terminology indistinguishability and the chosen plain text attack to reflect the type
of goal and loosely speaking say that security just means that this number is
small for any adversary whose resource usage is practical, doesn't exceed
practical amounts of running time.
This is not a formal definition because it doesn't define where small and practical
are. But that's kind of special to a concrete approach. In reality security is not a
Boolean attribute. It depends on the resources an attacker invests. In theory
you would say something like well the attacker success probably is negligible in
that security but then it's difficult to translate that to practice.
>>: [inaudible].
>> Mihir Bellare: Yeah.
>>: What if that factors [inaudible] zero and zero and then 1M1, then 0M1?
>> Mihir Bellare: Sure. So it could do that. And if it sends -- okay if it sends M0
M0 the attack you are talking about will work if the encryption is deterministic. So
that's a great point. And in particular it proves that that's the in some sense this
is why this captures ECB failing.
So one of the implications of this is that any good encryption scheme has to be
randomized. So when you send M zero, M zero the first time and then in your
third step you set to again send them zero and one, the coins used in the two
case would be different, and so even if you twice encrypt the M 0, it won't look
the same.
>>: Thank you.
>> Mihir Bellare: Okay? So that kind loosely says what we mean by secure
encryption, we need a similar definition for the block cypher and it won't be
security against [inaudible] coverage what's called being a pseudo random
permutation and here I'll skip the precise formulation, but the intuition is that the
input output behavior of the block cypher resembles that of a random
permutation. The important caveat is only to someone who doesn't know the key
but only sees input output examples.
And this is the definition that was kind of lucky in theory literature, but we pulled
out and made concrete and now analyze a large of block cypher usages. So we
saw that electronic code book mode is insecure, and we also saw that CBC is
highly used and potentially is more secure due to the fact that it's randomized.
But it would be nice to know whether there actually are attacks of the form that
they're only CB. And roughly speaking the answer we give in our work on the
subject was that it is secure, meaning that it meets the notion of security we just
outlined as long as you assume that the block cypher is itself good.
So this is -- this gives us some confidence that this notion is right and supports
the fact that if you are using it right now across, you know, hundreds of
thousands of platforms out there, it's actually -- it actually works. Now, just as a
recall underlining these two things here are the formal definitions we talked
about. This is the formal security goal for encryption which captures very strong
security requirements, and this is the assumption we make on the block cypher
which is stronger than usual but is necessary to get any kind of conclusions
about the users of the primitive.
Now, that's kind of an informal statement that doesn't give you the concrete view,
and this is how it would look in a concrete security setting. So here the theorem
doesn't say something about security or not, it just gives you a numerical relation
between the success probabilities of adversities. It says that if you give me an
attacker on the encryption scheme and it has some resource, it sees some
number of encryptions of messages of some length and has some running time, I
will build for you an attacker against the block cypher and their successes are
related in this way.
And you read that as saying that as long as this quantity is small, meaning the
block cypher's secure, then equality tells you that this is small as long as the
resource users of your attacker doesn't get to be too big. And the nice thing
about this is that you can get numbers out of it. So for example if you encrypt
this many messages of this length and you want security against an attacker with
this much running time, you can plug it into the formula and the appropriate
assumptions on the block cypher and let's say we're using AES so we are 128 bit
block length, the formula will tell you how much success probability your
adversity will have. Yes in.
>>: It seems that this job will look really bad if you [inaudible].
>> Mihir Bellare: That's right. Yeah. So I guess I say something about that.
There's a term here that in some sense becomes the bottle neck to getting good
security out of this. This term is not an artifact of the analysis as long as you are
targeting this type of security notion this reflects worth the attacks that can
actually happen. Now, you might debate whether those attacks are important in
practice, but if you did the position that encryption is something that needs to be
deployed in a way that's kind of application oblivious, it should work for any
application, then they're important.
And this term grows fast enough that we use DS, you'll get very little security out
of it. In fact, even with AES you probably get less out of this than the really like.
But anyway, so in conclusion this sort of exemplifies the whole path we followed.
It talks about how we use confusion diffusion primitives here, the block cypher
and made assumptions about them. We were able to analyze symmetric
cryptography used in practice, get provable security results about it and in
concrete security settings that give us back numbers that we could interpret.
Okay? My second example is about integrity of data so here what's happening is
that the message is being transmitted and Bob wants to make sure that when he
gets a message really originates with Alice and not someone else.
To do that, Alice attaches a tag called a MAC also computed under the secret
key that they share. Note that the message is transferred in the clear. We're not
trying to achieve security here. We won't go into this formally but roughly the
security goal is that it should be hard to produce a MAC of a message without
knowing the key. So this functions as a kind of fingerprint which only the holders
of the key can produce and vouches for the fact that the message is authentic.
Now, historically MACs are built based on block cyphers and in particular the
DES base CBC MAC was one of the first and most widely used you ones. But
later on hash functions started appearing and this character should be a
membership symbol. I guess my [inaudible] two machines are the same. So,
yeah, so hash functions had the nice property because they were faster than the
cyphers that were present at the time in software and so people wanted to look at
them for a base to use here.
Now, it may be a little useful for going to do to think -- say a little what hash
functions look like. Hash functions themselves are built on the principal we've
seen before of transforming some atomic primitive to a high level one. The
automatic primitive there is a compression function and it's repeated a number of
times in some way to hash data of arbitrary length. Their standard property of
the hash function is what's called collision resistance which means it should be
hard to find two different inputs with the same output even though mathematically
of course these kind of collisions are bound due to the fact that the hash function
output is a fixed length like 160 bits an inputs are arbitrary length.
So when you start thinking about using hash functions for the purpose of
message authentication, the basic bottle neck you have is that these primitives
don't take keys and message authentication depends on use of a secret key. So
how do we put a key into there? Well, various proposals like this were made but
eventually my colleagues at IBM Kenati and Krowchek [phonetic] and came up
with this proposal called HMAC, and it's quite simple. All it does is pretend a K to
input at hash except that it the repeats the process, so it hashes twice. And
there are a couple of things about this design that made it attractive. One is that
we could prove some sort of security properties. We could prove that it's a
secure message authentication code under approach assumptions and the
assumption here was what people were assuming typically of the hash function.
It's collision resistant. And secondly, we also needed an assumption, the
underlying compression function that it satisfied a notion called being a pseudo
random function which you don't have to know exactly what it means in depth at
this moment.
So additionally however HMAC was practical in the sense that it was efficient,
just two applications of the hash function, easy to implement because it made
only black box use of the hash function and possibly these are some
explanations barring lucky suppose of the fact that HMAC is now widely used.
Microsoft uses it and it's the only -- I understand it's called automatically
approved to implement MAC. It recently became a government standard. It was
used in IP SEC GMS, SSL, pretty much everywhere.
So with this kind of deployment security becomes crucial and the story which
interestingly continues into quite recent times with the fact that hash functions
turned out to be a lot less secure than we thought, so you already saw Professor
Wang on a previous slide and she showed that ND 5 which is a hash function
which HMAC is used quite broadly is not collision resistant and neither is share
one this may not be.
Now, when people try to extend those attacks to HMAC, they found that they
couldn't. So the attacks don't actually HMAC, the keying and the structure
somehow prevents that. But it had an interesting theoretical consequence which
is that the result justifying security effectively became vacuous, not because the
theorem was wrong but because one of the assumptions was false. You can
view as what Professor Wang is saying is that simply since the hash function is
not collision resistant, this theorem effectively says false, implies true which is
always true. So I returned to this a little bit after these attacks based on the fact
that people were kind of questioning, even though HMAC didn't have -- wasn't
broken whether the lack of a proof should mean that one should consider
removing it as a standard.
And what I did was proof that HMAC continues to be secure even if this
assumption isn't true. So nearly the second assumption is enough to guarantee
security. The good thing about that is that the second assumption is not refuted
by any known attacks and so this reestablished a approve based guarantee and
at least to some extent was influential in maintaining confidence in the standards.
But I think it would be unrealistic to end there. I should note that even given this
proof and even given the fact that HMAC with ND 5 was not completely
destroyed at this point, I definitely don't encourage its use. Cryptanalysis of it
continues and gets better an better, and I personally don't believe that it's going
to stand up in the future. So you do want to make sure that you have hash
functions which are likely to have the property you need for the proof to be true.
And this seems to much better with later hash functions such as share to 56.
Yeah?
>>: [inaudible] the proof now with HMAC and [inaudible] is it a security random
funding ->> Mihir Bellare: Oh, in that sense, the situation that was before comes back in
the sense that if you simply had some attack showing that MD 5, its compression
function is not pseudo random, you wouldn't necessarily break HMAC, so again
the proof is not capturing everything that's there. But conceivably, I would
imagine that HMAC ND 5 will eventually itself just be attacked. Somehow --
>>: [inaudible].
>> Mihir Bellare: In particular, yeah. Although I think that could be proved before
there's an attack. Yes?
>>: Since '96, hashes have got rather slower when they got more secure and of
course the ( [inaudible] implies that this happened [inaudible] would send you to
jail.
>> Mihir Bellare: That's right.
>>: [inaudible] do it again in this century, will you still use hashes for the base of
MAC?
>> Mihir Bellare: That's a good point. And sometimes even nowadays for
example even the performance gap is dropped so AES is much faster than DES
was. It's not clear there would be such a strong motivation anymore. So at this
point use of HMAC is largely entrenched and so okay.
So I guess I can quickly do my last example which is asymmetric encryption. So
here we in the public key setting and Bob -- Alice wants to encrypt a message.
She can do that given kind of public information about Bob in the form of you can
think of a like a public phone number which Bob can decrypt with a secret key
and again our goal is privacy. Largely speaking in practice we use RSC
encryption. The public key here is a number called a modulus and an encryption
exponent. It won't matter much if you don't know how these work. And there's a
corresponding secret key over here.
So when we tackle building encryption schemes with RSA, we knee to make use
of the mathematical RSA function. What cryptographers like to think of this as is
what's called a one way trap door function. This means that if I give you the
public key, the model S and exponent and I give you an input X, it's easy to
compute the value of the function which is defined by raising X to the power E
and then doing that modular N.
Similarly, if I give you the decryption exponent and the modulus, it's actually easy
to go backwards and go from F affects back to X. But as long as you don't have
this decryption key D here, it's currently not known how you can reverse this
process. Now, I'd like to add the one important technicality that our
understanding or at least the formal assumption about this relates to what X was
chosen at random. If I choose X at random and give you F of X, don't give you
the decryption key, no one knows how to go backwards.
Now, when RSA was introduced based on the element type paradigm, it was
generally thought that we solved public encryption because that is encryption just
like the encryption B this and well you can encrypt and decrypt and the adversary
can't reverse the encryption process without the secret key.
The difficulty is that this function although you cannot get M back from F of N,
can reveal partial information or some pieces of information about the message.
And that's not what we want for good encryption puts us back in the position
we've seen many times by now which is that we want to create an encryption
scheme viewing the RSA function as a low level primitive and the encryption
scheme as a high level one and the question is how do we actually do the
transform?
So one thing that will be necessary is randomization because without that we will
not meet the kind of strong security goals that I talked about in the symmetric
setting. Now, in theory this problem was solved using something called hard
core bits and they can tell you that they can provably encrypt with RSA in this
method. But when you look at this from a practical perspective where you hit
performance bottle neck, so every encryption here each RSA operation only
encrypts one message bit. If I were 128 bit message I have a hundred, over
100,000 bits of cypher text. And plus I need a lot of RSA operations. So what
practitioners said is let's do something very simple. We know that you can't let
the message be the object to which the RSA function F is applied, so let's throw
in a little bit of randomness and part out the message with that and then encrypt.
Well, across the fence the comment about this was not that we know how to
break it, they didn't know how to break it, but to be careful about this because it's
no longer the case that you can prove security of this me thought based on the
assumption we'd like to make about RSA is that it's one way. So if this works, we
don't really understand why and that's kind of a cautionary way to look at it.
Well, as long as -- nonetheless the performance reasons this turned out to be
widely deployed, was a standard introduced by RSA security and from then into
pretty much every standard out there and this is what gets used. It turned out
that the pessimists were right in this case, so eventually attacks emerged and
showed that there were different ways to compromise PKCS. One of these is
what's called a chosen cypher text attack whereby an attack with some sort of
limited access to a decryption box can break the scheme and this turned out to
be relevant to the user PKCS and SSL which is why the certain advisory went
out. But later even stronger protocols have chosen plain text attacks in March
where certain types of messages could simply be recovered from the cypher text.
What we proposed as an alternative was something called AEP, which follows
the PKCS paradigm in saying that we only want to apply F1s, and you want to be
able to put a large number of message bits into any -- in a single encryption. So
what it does is it takes the message, adds some redundancy and then takes a
random number here, there is a randomization, and processes are shown based
on a couple of public functions to produce some output and then the RSA
function is applied to that, okay.
So what was good about this is that it had some kind of provable support. Under
the assumptions that theoreticians like to make which is that RSA is one way and
under the -- and another assumption that I'll discuss more in more depth later
which are that these functions are what are called random oracles, we could
prove security against plain -- plain text attacks. It turns out you can also prove
security against chosen cypher text attacks which is what you need to prevent
the kind of thing that like Likenbacker [phonetic] talked about.
Now, the benefit of this is that it meets both the practical and theoretical
constraints. On the efficiency side, it's as efficient as the broken scheme that the
practitioners wanted but it had some kind of security proof. And again, that
turned out to be attractive for usage. So OAEPs also in whole bunch of
standards and software across the world and so forth.
Now, the story has a kind of embarrassing component as well. In our original
paper we had actually claimed not only this security but security against these
stronger attacks and we got that wrong. Luckily for us, the fact itself wasn't false,
so at the researchers filled the gap soon after it was pointed out, but I think it
reflects something about proofs and also the fact that in those days we just had
so much to do that we were going really, really fast and we kind of missed some
things.
So I'd like to talk a little bit about the methodology behind that result and
particular this fact about random oracles which have become another widely
used method. So the random oracle paradigm was something that Phil and I
created exactly in order to bridge this gap between theory and practice where
you didn't seem to be able to produce schemes of the kind of efficiency that
practitioners needed and yet have security proofs. And what we noticed is that
the building blocks used in practice had properties that were not captured by
theoretical definitions but seemed very strong, which is in particular that things
like hash functions were built to resemble, to have random behavior and we
wanted to try to capture that. So we created this model based on some
inspiration by Fiat and Shamere [phonetic] where you have access to a box
which implements a random function. That just means that when you call this,
think of it as a piece of software somewhere out there on the Internet. It will
simply return a random number except that it's nice enough to be consistent. If
you try asking the same question, it gives you the same thing back.
So this is in fact a complete noise box. It does nothing of any discernible value, it
just gives you random stuff. Nonetheless this turns out to be just about the most
useful cryptographic primitive you can imagine. And what we did is show how
large number of schemes can be proof secure in this model. Now, at first glance
that's quite useless because the random oracle is effectively a thought
experiment, so our next step was to say that when you wanted practical scheme
you replace this random oracle with the hash function. And in that way you were
able to get highly efficient schemes with security proofs in this model.
The caveat from a theoretical perspective is that the security proofs applied in the
random oracle model, they didn't apply to the instantiated final scheme. And this
aspect has led to the random oracle model being highly debated and
controversial, in particular people have shown that it's possible to find counter
example schemes which are secure in the random oracle model but once you
use the hash function they fail. And that might sound like a problem except that
the counter examples are all artificial. They kind of built to fail. And real
schemes that this doesn't seem to happen. The random oracle model is
probably one of the most popular things we've done. It's used enormously, well,
just one such instance it was used for the first ID scheme. By and large the
practical schemes based on it have not failed but the theoretical questions it
raises are quite interesting because nobody knows a really sound theoretical way
to bridge the gap between the random oracle model and instantiation. And this
kind of reflects to some extent Phil and my philosophy which is that when we had
a choose between choosing between theory and practice, we chose practice in
the sense that we were willing to sacrifice the proves to the largest extent, to the
minimal extent possible to bridge the efficiency gaps and there by we created this
kind of hybrid methods.
I don't have much to say about the where things are going but my particular
interests are in pushing cryptography to the point where it's even more aware of
what goes on in practice in software and systems than now, and another
direction I'm interested in is in making theory more understandable and proofs
more verifiable by tools to do these things.
I'm sorry I haven't had time to talk about my more recent work and but I worked a
lot on many of these topics and I'm to get into that any time offline. So I'll stop
there. Thank you.
[applause].
>> Mihir Bellare: Yes?
>>: You said several times get some randomness. Now, where do you
randomness in [inaudible].
>> Mihir Bellare: Yeah, that's certainly.
>>: [inaudible].
>> Mihir Bellare: That's right. So that's only one of these sort of problems
where, yeah, it's not clear how to do it. So of course there are all these standard
heuristics. You take system parameters and you hash them and you do things.
But, yeah, these things premium high quality randomness. So that's another one
of these gaps. Yes in.
>>: So you measure the random oracle, is that [inaudible] zero random numbers
[inaudible] potentially random [inaudible].
>> Mihir Bellare: So the random oracle is a thought experiment. So it's not
pseudo random, it's perfectly random. So when you use a pseudo random
generator, you are approximating it to a certain extent, but that approximation is
something that I don't know how to capture in any formal way. So heuristically it
may work, but somehow there are no guarantees about it. Okay. Yes?
>>: In the beginning you defined sort of the difference between a [inaudible]
security analysis and then the cryptography where the security was looking at
viruss and other ways to get things and you said you were going to concentrate
on the analysis although things later on you did mention some attacks that use
like the looking at the electricity changes. And so how much in practice can you
really separate those two?
>> Mihir Bellare: Yeah. That's a good point. So in practice, they're harder to
separate than in theory and but there's a lot of work at both ends, I think, in
pushing theoretical models deeper into systems to capture this. And on the other
side to make cryptography aware of what's going on in systems. For example
one thing I've worked on is protecting against break ins by former security where
the key evolves with time. So the system gets broken into a certain point in time
you only lose the current key. But this is a huge area of problems and issues for
security in general where largely things are open.
Yes, Charles?
>>: [inaudible] comment that [inaudible].
>> Mihir Bellare: Oh, yes. [laughter].
>> Mihir Bellare: It was a merger. So these things happen. Okay. I guess that's
it then.
[applause]