Welcome to office hours for week two. What questions do we have?
Wolfgang from the forum writes asking about random oracles and wanted to know more
why they're not realistic in practice.
This is a good question.
We use random oracles in ways to make it easier to reason about cryptography.
The definition of a random oracle is typically you've got this magic black box
that you can send an input to in some range,
and you get as output a random value in the output domain.
For it to be a random oracle, that value needs to be completely unpredictable.
We can think about building something like this.
You could have a lookup table where for every possible input
you've produced using some good physical source of randomness
the output for that input.
Then you would do the lookup and get that output.
That would behave like a random oracle
that those inputs would be totally random. There is no correlation.
The problem is if we try to make that function any smaller.
So instead of having a table where for every input we can look up the corresponding output,
we want something smaller. That's what we want with a hash function.
That's what we want for any practical use of a mapping between inputs and outputs.
We can't have a full table. That would be just a huge amount of memory.
The random oracle turns out to be a useful device for reasoning about cryptography
where we assume that this black box exists and has this perfect ideal behavior.
It's not something we can actually build.
We have to be really careful when we reason about cryptography
using this assumption about a random oracle, and then we, say, through in a hast function
that we think behaves sort of like one,
because no hash function actually behaves like a random oracle.
For our next question, Sayid Bashir wonders by looking at a ciphertext,
is it possible to figure out the encryption scheme that is used?
For most academic working cryptography, people assume they know
everything about  the scheme being used and are trying to find
some mathematical weakness that allows you to solve it more quickly than you could
by doing a brute force search on the key space.
for a lot of real world cryptography, that's not the case.
The first thing you've got to do is figure out the scheme being used.
That's sort of like the challenge question from homework two
where if I told you the scheme for the random number generation it would be easy
to figure out the next one.
That's more of a better model for most cryptographic work that academics do--
assuming you know the scheme and trying to find mathematical weaknesses in it.
For a lot of practical cryptography certainly going back further but even today
it's not the case that you know the scheme.
If the scheme is good, then even if you know what's one of a set of known schemes,
you shouldn't be able to tell from the ciphertext.
The cipher text should be purely random.
It should look like purely random values.
Unless there is some weaknesses in the encryption scheme used, you shouldn't be able to tell what it is.
But there are weaknesses in all encryption schemes used.
This is particularly an issue if someone invents their own encryption scheme.
They think, oh, it's going to be super secure since I've invented this custom scheme
just for my own use. Those schemes almost always have weaknesses in them.
Even if the scheme is not known, make it much easier than breaking a known scheme
where the key is not known.
It should be the case that you can't tell anything about the scheme from the ciphertext.
In practice, that's probably not the case unless the scheme is a good one.
Yeah. I guess it kind of goes back to the importance of keeping your keys secure.
This is going back to Kerckhoff principle,
which is you should be able to have a cipher that--
even if the adversary knows everything about the scheme you're using--
as long as they don't know your key, you have a good argument why that is secure.
Then the last question come from Pavel.
He has a question about invertibility.
It's not obvious why encrypting different messages with a fixed key cannot give you the same ciphertext.
Is this necessary for correctness?
The question if you have two messages that encrypt to the same ciphertext,
when you try to decrypt them you can't know which one to get.
This is why in order for a cipher to be invertible,
we need to have the property that each ciphertext corresponds to exactly one input.
There are probabilistic ciphers, so there could be more than one ciphertext
that corresponds to the same input under the same key,
but it can't be the case that there are multiple inputs with the same key
that map to the same ciphertext,
because then when you try to decrypt it, even though you've got the key,
you don't know which one of those two messages was the input.
We need this property that easy ciphertext can be decrypted to exactly one message.
Otherwise decryption doesn't work.
