< Return to Video

Security for many-time key (23 min)

  • 0:00 - 0:05
    In this segment we will look at how to use
    block ciphers to encrypt multiple messages
  • 0:05 - 0:09
    using the same key. This comes up in
    practice for example in file systems where
  • 0:09 - 0:13
    the same key's used to encrypt multiple
    files. It comes up in networking protocols
  • 0:13 - 0:18
    where the same key is used to encrypt
    multiple packets. So let's see how to do
  • 0:18 - 0:22
    it. The first thing we need to do is to
    define what is mean for a cipher to be
  • 0:22 - 0:26
    secure when the same key is used to
    encrypt multiple messages. When we use the
  • 0:26 - 0:31
    key more than once the result of that is
    that the adversary gets to see many cyber
  • 0:31 - 0:36
    text encrypted using the same key. As a
    result, when we define security, we're
  • 0:36 - 0:41
    gonna allow the adversary to mount what's
    called a chosen plain text attack. In
  • 0:41 - 0:46
    other words, the adversary can obtain the
    encryption of arbitrary messages of his
  • 0:46 - 0:50
    choice. So, for example, if the
    adversary's interacting with Alice. The
  • 0:50 - 0:54
    adversary can ask Alice to encrypt
    arbitrary messages of the adversary's
  • 0:54 - 0:58
    choosing. And Alice will go ahead and
    encrypt those messages and give the
  • 0:58 - 1:03
    adversary the resulting cipher texts. You
    might wonder why would Alice ever do this.
  • 1:03 - 1:07
    How could this possibly happen in real
    life? But it turns out this is actually
  • 1:07 - 1:12
    very common in real life. And in fact,
    this modeling is quite a conservative
  • 1:12 - 1:16
    modeling of real life. For example, the
    adversary might send Alice an email. When
  • 1:16 - 1:21
    Alice receives the email, the writes it to
    her encrypted disk, thereby encrypting the
  • 1:21 - 1:26
    adversary's email using her secret key. If
    later the adversary steals this disc, then
  • 1:26 - 1:31
    he obtains the encryption of an email that
    he sent Alice under Alice's secret key. So
  • 1:31 - 1:36
    that's an example of a chosen plain text
    attack, where the adversary provided Alice
  • 1:36 - 1:41
    with a message and she encrypted that
    message using her own key. And then later
  • 1:41 - 1:45
    the attacker was able to obtain the
    resulting cipher text. So that's the
  • 1:45 - 1:50
    adversary's power. And then the
    adversary's goal is basically to break
  • 1:50 - 1:54
    semantic security. So let's define this
    more precisely. As usual, we're gonna
  • 1:54 - 1:59
    define semantic security under a chosen
    plain text attack using two experiments,
  • 1:59 - 2:05
    experiment zero and experiment one, that
    are modeled as a game between a challenger
  • 2:05 - 2:10
    and an adversary. When the game begins,
    the challenger is gonna choose a random
  • 2:10 - 2:14
    key K. And now the adversary basically
    gets to query the challenger. So the
  • 2:14 - 2:18
    adversary now begins by submitting a
    semantic security query, namely, he
  • 2:18 - 2:23
    submits two messages, M zero and M one. I
    added another index, but let me ignore
  • 2:23 - 2:27
    that extra index for a while. So the
    adversary submits two messages, M zero and
  • 2:27 - 2:32
    M one, that happen to be of the same
    length. And then the adversary receives
  • 2:32 - 2:36
    the encryption of one of those messages,
    either of M zero or of M one. In
  • 2:36 - 2:40
    experiment zero, he receives the
    encryption of M zero. In experiment one,
  • 2:40 - 2:45
    he receives the encryption of M one. So,
    so far this would look familiar this looks
  • 2:45 - 2:49
    exactly like a standard semantic security
    [inaudible]. However, plain text attack
  • 2:49 - 2:54
    the adversary can now repeat this query
    again. So now you can issue a query with
  • 2:54 - 2:58
    two other plain texts, again of the same
    length, and again you would receive the
  • 2:58 - 3:03
    encryption of one of them. In experiment
    zero you would receive the encryption of M
  • 3:03 - 3:08
    zero. In experiment one you would receive
    the encryption of M one. And the attacker
  • 3:08 - 3:13
    can continue issuing queries like this. In
    fact we'll say that he can issue up to Q
  • 3:13 - 3:17
    queries of this type. And then, remember,
    every time he issues a pair of messages.
  • 3:17 - 3:21
    That happen to be of the same length and
    every time he either gets the encryption
  • 3:21 - 3:26
    of the left side or the right side again
    in experiment zero he will always get the
  • 3:26 - 3:30
    encryption of the left message in
    experiment one he will always get the
  • 3:30 - 3:34
    encryption of the left message. And, then
    adversary's goal is, basically, to figure
  • 3:34 - 3:38
    out whether he's in experimental zero or
    in experiment one. In other words, whether
  • 3:38 - 3:43
    he was constantly receiving the encryption
    of the left message or the encryption of
  • 3:43 - 3:47
    the right message. So, in some sense, this
    is a standard semantic security game just
  • 3:47 - 3:51
    iterated over many queries that the
    attacker can issue to adaptively one after
  • 3:51 - 3:56
    the other. Now the chosen plain text
    attack is captured by the fact that if the
  • 3:56 - 4:01
    attacker wants the encryption of a
    particular message m. What he could do is,
  • 4:01 - 4:05
    for example, use query J for sum J, where
    in this query J he'll set both the zero
  • 4:05 - 4:10
    message and the one message to be the
    exactly same message M. In other words,
  • 4:10 - 4:14
    both the left message and the right
    message are the same, and both are set to
  • 4:14 - 4:19
    the message M. In this case, what he will
    receive, since both messages are the same,
  • 4:19 - 4:23
    he knows that he's gonna receive the
    encryption of this message M that he was
  • 4:23 - 4:28
    interested in. So this is exactly what we
    meant by a chosen [inaudible] attack.
  • 4:28 - 4:33
    Where the advisory can submit a message m
    and receive the encryption of that
  • 4:33 - 4:37
    particular message m of his choice. So
    some of his queries might be of this chose
  • 4:37 - 4:42
    plain text flavor where the message on the
    left is equal to the message on the right,
  • 4:42 - 4:47
    but some of the queries might be standard
    semantic security queries where the two
  • 4:47 - 4:51
    messages are distinct and that actually
    gives him information on whether he's in
  • 4:51 - 4:55
    experiment zero or in experiment one. Now
    by now you should be used to this
  • 4:55 - 5:00
    definition where we say that the system is
    semantically secure under a chosen plain
  • 5:00 - 5:04
    text attack. If, for all efficient
    adversaries, they cannot distinguish
  • 5:04 - 5:09
    experiment zero from experiment one. In
    other words, the probability that, at the
  • 5:09 - 5:13
    end, the output, B Prime, which we're
    gonna denote by the output of experiment
  • 5:13 - 5:18
    B. This output will be the same whether
    [inaudible] experiment zero or experiment
  • 5:18 - 5:22
    one. So the attacker couldn't distinguish
    between always receiving encryptions of
  • 5:22 - 5:27
    the left messages, versus always receiving
    encryptions of the right messages. So in
  • 5:27 - 5:31
    your mind, I'd like you to be thinking of
    an adversary that is able to mount a
  • 5:31 - 5:36
    chosen plaintext attack, namely, be given
    the encryption of arbitrary messages of
  • 5:36 - 5:40
    his choice, and his goal is to break
    semantic security for some other challenge
  • 5:40 - 5:44
    cipher texts. And as I said in this
    [inaudible] model of the real world the
  • 5:44 - 5:49
    attacker is able to fool Alice into
    encrypting for him messages of his choice
  • 5:49 - 5:53
    and then the attacker's goal is to somehow
    break some challenge cypher text. So I
  • 5:53 - 5:58
    claim that all the ciphers that we've seen
    up until now, namely deterministic counter
  • 5:58 - 6:03
    mode or the one time pad, are insecure
    under a chosen plain text attack. More
  • 6:03 - 6:07
    generally, suppose we have an encryption
    scheme that always outputs the same cipher
  • 6:07 - 6:12
    text for a particular message M. In other
    words, if I ask the encryption scheme to
  • 6:12 - 6:16
    encrypt the message M once. And then I ask
    the encryption scheme to encrypt the
  • 6:16 - 6:21
    message m again. If in both cases the
    encryption scheme outputs the same cypher
  • 6:21 - 6:27
    text, then that system cannot possibly be
    secure under a chosen plain text attack.
  • 6:27 - 6:31
    And both deterministic counter mode and
    the one time pad were of that flavor. They
  • 6:31 - 6:36
    always output the same cipher text, given
    the same message. And so let's see why
  • 6:36 - 6:41
    that cannot be chosen plain text secure.
    And the attack is fairly simple, what the
  • 6:41 - 6:46
    attacker is gonna do, is he's gonna output
    the same message twice. This just says.
  • 6:46 - 6:51
    That he really wants the encryption of M0.
    So here the attacker is given C0 which is
  • 6:51 - 6:56
    the encryption of M0. So this was his
    chosen plain text query where he actually
  • 6:56 - 7:01
    received the encryption of the message M0
    of his choice. And now he's going to break
  • 7:01 - 7:05
    semantic security. So what he does is he
    outputs two messages, M0 and M1 of the
  • 7:05 - 7:10
    same length, and he's going to be given
    the encryption of MB. But low and behold,
  • 7:10 - 7:16
    we said that the encryption system. Always
    outputs the same cipher text when its
  • 7:16 - 7:22
    encrypting the message, M0. Therefore, if
    B is=to zero, we know that C, this
  • 7:22 - 7:27
    challenged cipher text, is simply=to CO,
    because it's the encryption of M0.
  • 7:27 - 7:32
    However, if B is=to one. Then we know that
    this challenge cypher text is the
  • 7:32 - 7:38
    encryption of M1 which is something other
    than C zero so all the attacker does is he
  • 7:38 - 7:43
    just checks his C is = to C0 the output's
    zero in other words he outputs one. So, in
  • 7:43 - 7:48
    this case, the attacker is able to
    perfectly guess this bit B, so he knows
  • 7:48 - 7:52
    exactly [inaudible] given the encryption
    of M0, or the encryption of M1. And as a
  • 7:52 - 7:57
    result, his advantage in winning this game
    is one. Meaning that the system cannot
  • 7:57 - 8:01
    possibly be CPA secure. One is not a
    negligible number. So this shows that the
  • 8:01 - 8:06
    deterministic encryption schemes cannot
    possibly be CPA-secure, but you might
  • 8:06 - 8:09
    wonder well, what does this mean in
    practice? Well in practice this means
  • 8:09 - 8:13
    again that every message is always
    encrypted to the same cipher text. What
  • 8:13 - 8:17
    this means is if you're encrypting files
    on disk, and you happen to be encrypting
  • 8:17 - 8:21
    two files that happen to be the same, they
    will result in the same cipher text and
  • 8:21 - 8:25
    then the attacker by looking at the
    encrypted disk, will learn that these two
  • 8:25 - 8:29
    files actually contain the same content.
    The attacker might not learn what the
  • 8:29 - 8:33
    content is, but he will learn that these
    two encrypted files are an encryption of
  • 8:33 - 8:38
    the same content and he shouldn't be able
    to learn that. Similarly, if you send two
  • 8:38 - 8:41
    encrypted packets on the network that
    happen to be the same, the attacker will
  • 8:41 - 8:45
    not learn the content of those packets,
    but he will learn that those two packets
  • 8:45 - 8:49
    actually contain the same information.
    Think for example of an encrypted voice
  • 8:49 - 8:54
    conversation. Every time there's quiet on
    the line, the system will be sending
  • 8:54 - 8:58
    encryptions of zero. But since encryption
    of zero are always mapped to the same
  • 8:58 - 9:02
    cypher text. An attacker looking at the
    network will be able to identify exactly
  • 9:02 - 9:06
    the points in the conversation where
    there's quiet because he will always see
  • 9:06 - 9:11
    those exact same cypher text every time.
    So these are examples where deterministic
  • 9:11 - 9:15
    encryption cannot possibly be secure. And
    as I say formerly we say that the
  • 9:15 - 9:20
    terministic encryption can not be
    semantically secure under a chosen plain
  • 9:20 - 9:25
    text attack. So what do we do, well the
    lesson here is if the secret keys gonna be
  • 9:25 - 9:30
    used to encrypt multiple messages, it had
    better be the case that given the same
  • 9:30 - 9:34
    plain text to encrypt twice. The
    encryption algorithm must produce
  • 9:34 - 9:38
    different cipher texts. And so there are
    two ways to do that. The first method is
  • 9:38 - 9:43
    what's called randomized encryption. Here,
    the encryption algorithm itself is going
  • 9:43 - 9:47
    to choose some random string during the
    encryption process and it is going to
  • 9:47 - 9:52
    encrypt the message M using that random
    string. So what this means is that a
  • 9:52 - 9:56
    particular message, M0 for example, isn't
    just going to be mapped to one cipher text
  • 9:56 - 10:01
    but it's going to be mapped to a whole
    ball of cipher texts. Whereon every
  • 10:01 - 10:07
    encryption, basically, we output one point
    in this ball. So every time we encrypt, the
  • 10:07 - 10:11
    encryption algorithm chooses a random
    string, and that random string leads to
  • 10:11 - 10:16
    one point in this ball. Of course, the
    decryption algorithm, when it takes any
  • 10:16 - 10:21
    point in this ball, will always map the
    result to M zero. Similarly cipher text M
  • 10:21 - 10:25
    one will be mapped to a ball, and every
    time we encrypt M one, we basically output
  • 10:25 - 10:30
    one point in this ball. And these balls
    have to be disjoint, so that the
  • 10:30 - 10:34
    encryption algorithm, when it obtains a
    point in the ball corresponding to M one,
  • 10:34 - 10:39
    will always output the message M one. In
    this way, since the encryption algorithm
  • 10:39 - 10:43
    uses randomness, if we encrypt the same
    message twice, with high probability we'll
  • 10:43 - 10:47
    get different cipher texts. Unfortunately
    this means that the cipher text
  • 10:47 - 10:51
    necessarily has to be longer than the
    plain text because somehow the randomness
  • 10:51 - 10:56
    that was used to generate the cipher text
    is now encoded somehow in the cipher text.
  • 10:56 - 11:00
    So the cipher text takes more space. And
    roughly speaking, the cipher text size is
  • 11:00 - 11:05
    going to be larger than the plain text. By
    basically the number of random bits that
  • 11:05 - 11:09
    were used during encryption. So if the
    plain texts are very big, if the plain
  • 11:09 - 11:13
    texts are gigabytes long, the number of
    random bits is going to be on the order of
  • 11:13 - 11:17
    128. So maybe this extra space doesn't
    really matter. But if the plain texts are
  • 11:17 - 11:22
    very short, maybe they themselves are 128
    bits, then adding an extra 128 bits to
  • 11:22 - 11:26
    every cipher text is going to double the
    total cipher text size. And that could be
  • 11:26 - 11:31
    quite expensive. So as I say randomized
    encryption is a fine solution but in some
  • 11:31 - 11:36
    cases it actually introduces quite a bit
    of costs. So let's look at a simple example.
  • 11:36 - 11:41
    So imagine we have a pseudorandom
    function that takes inputs in a certain
  • 11:41 - 11:46
    space r which is gonna be called a nonce
    space. And outputs, outputs in the message
  • 11:46 - 11:51
    space. And, now, let's define the
    following randomize encryption scheme
  • 11:51 - 11:56
    where we want to encrypt the message m
    with the encryption of whatever it's gonna
  • 11:56 - 12:01
    do is first it's gonna generate a random r
    in this nonce space R. And then it's going
  • 12:01 - 12:06
    to open a cypher text that consist of two
    components, the first component is going
  • 12:06 - 12:11
    to be this value R and the second
    component is going to be an evaluation of
  • 12:11 - 12:16
    the pseudo-random function at the point R
    XOR with the message M. And my question to
  • 12:16 - 12:21
    you is, is this encryption system
    semantically secure under a chosen plain
  • 12:21 - 12:26
    text attack. So the correct answer is yes.
    But only if the nonce space R is large
  • 12:26 - 12:31
    enough so that little R never repeats with
    very, very high probability. And let's
  • 12:31 - 12:36
    quickly argue why that's true. So first of
    all, because F is a secure pseudo-random
  • 12:36 - 12:41
    function, we might as well replace it with
    a truly random function. In other words,
  • 12:41 - 12:46
    this is indistinguishable from the case
    where we encrypt the message M, using the
  • 12:46 - 12:51
    truly random function little F, evaluated
    to point R, and then XOR with M.
  • 12:51 - 12:57
    But since this little r never repeats every
    cypher text uses a different little r what
  • 12:57 - 13:03
    this means is that the values of F(r)
    are random uniform independent strings
  • 13:03 - 13:09
    every time. So every time we encrypt a
    message, we encrypt it essentially using a
  • 13:09 - 13:14
    new uniform random one time pad. And since
    XORing a uniform string with any string
  • 13:14 - 13:20
    simply generates a new uniform string, the
    resulting cipher text is distributed as
  • 13:20 - 13:25
    simply two random uniform strings. I'll
    call them r and r prime. And so both in
  • 13:25 - 13:30
    experiment zero and in experiment one, all
    the attacker gets to see are truly uniform
  • 13:30 - 13:36
    random strings r, r', and since in both
    experiments the attacker is seeing the same
  • 13:36 - 13:41
    distribution, he cannot distinguish the
    two distributions. And so since security
  • 13:41 - 13:46
    holds completely when we're using a truly
    random function it's also gonna hold when
  • 13:46 - 13:51
    we're using a pseudorandom function. Okay,
    so this is a nice example of how we use
  • 13:51 - 13:55
    the fact that the pseudo random function
    behaves like a random function to argue
  • 13:55 - 14:00
    security of this particular encryption
    scheme. Okay, so now we have a nice
  • 14:00 - 14:04
    example of randomized encryption. The
    other approach to building chosen plain
  • 14:04 - 14:09
    text secure encryption schemes is what's
    called a nonce based encryption. Now, in
  • 14:09 - 14:14
    a non-spaced encryption system, the
    encryption algorithm actually takes three
  • 14:14 - 14:19
    inputs rather than two. As usual it takes
    the key and the message. But it also takes
  • 14:19 - 14:24
    an additional input called a nonce. And
    similarly, the decryption algorithm also
  • 14:24 - 14:29
    takes the nonce as input, and then produces
    the resulting decrypted plain text. And
  • 14:29 - 14:34
    what is this nonce value n. This nonce is
    a public value. It does not need to be
  • 14:34 - 14:38
    hidden from the adversary but the only
    requirement is that the pair (k,n)
  • 14:38 - 14:43
    is only used to encrypt a single
    message. In other words, this pair (k,n)
  • 14:43 - 14:48
    must change from message to message. And
    there are two ways to change it. One way
  • 14:48 - 14:53
    to change it is by choosing a new random
    key for every message. And the other way
  • 14:53 - 14:58
    is to keep using the same key all the time
    but then we must choose a new nonce for
  • 14:58 - 15:03
    every message. And, and as I said, I wanna
    emphasize again, this nonce need not
  • 15:03 - 15:07
    be secret, and it need not be random. The
    only requirement is the nonce is unique.
  • 15:07 - 15:11
    And in fact, we're gonna use this
    term throughout the course. A nonce
  • 15:11 - 15:15
    for us, means a unique value that doesn't
    repeat. It does not have to be random. So
  • 15:15 - 15:20
    let's look at some examples of choosing an
    nonce, well the simplest option is
  • 15:20 - 15:24
    simply to make the nonce of the
    accounter so for example the networking
  • 15:24 - 15:29
    protocol you can imagine the nonce
    being a packet counter that's incremented
  • 15:29 - 15:34
    every time a packet is sent by a sender or
    received by the receiver this means that
  • 15:34 - 15:38
    the encrypter has to keep state from
    message to message mainly that he has to
  • 15:38 - 15:42
    keep this counter around and increment it
    after every message is transmitted.
  • 15:42 - 15:47
    Interestingly, if the decrypter actually
    has the same state then there is no need
  • 15:47 - 15:53
    to include the nuance in the cipher text
    since the nuance is implicit. Let's look
  • 15:53 - 15:58
    at an example. The https protocol is run
    over a reliable transport mechanism which
  • 15:58 - 16:03
    means that packets sent by the sender are
    assumed to be received in order at a
  • 16:03 - 16:08
    recipient. So if the sender sends packet #5 and then packet #6, the recipient
  • 16:08 - 16:12
    will receive packet #5 and then
    packet #6 in that order. This
  • 16:12 - 16:16
    means that if the sender maintains a
    packet counter, the recipient can also
  • 16:16 - 16:21
    maintain a packet counter and two counters
    basically increment in sync. In this case
  • 16:21 - 16:25
    there is no reason to include the
    nonce in the packets because the
  • 16:25 - 16:29
    nonce is implicit between the two
    sides. However, in other protocols, for
  • 16:29 - 16:35
    example, in IPsec, IPsec has a protocol
    designed to encrypt the IP layer. The IP
  • 16:35 - 16:39
    layer does not guarantee in order
    delivery. And so the sender might send
  • 16:39 - 16:45
    packet #5 and then packet #6, but
    those will be received in reverse order at
  • 16:45 - 16:49
    the recipient. In this case it's still
    fine to use a packet counter as a nonce
  • 16:49 - 16:54
    but now the nonce has to be included in
    the packet so that the recipient knows
  • 16:54 - 16:58
    which nonce to use to decrypt the
    received packet. So as I say, nonce based
  • 16:58 - 17:03
    encryption is a very efficient way to
    achieve CPA security. In particular if the
  • 17:03 - 17:07
    nonce is implicit, it doesn't even
    increase the cipher text length. Of course
  • 17:07 - 17:12
    another method to generate a unique nonce
    is simply to pick the nonce at random
  • 17:12 - 17:16
    assuming the nonce space is sufficiently
    large so that with high probability the
  • 17:16 - 17:22
    nonce will never repeat for the life of
    the key. Now in this case, nonce
  • 17:22 - 17:26
    based encryption simply reduces to
    randomized encryption. However, the
  • 17:26 - 17:32
    benefit here is that the sender does not
    need to maintain any state from message to
  • 17:32 - 17:36
    message. So this is very useful for
    example if encryption happens to take
  • 17:36 - 17:41
    place on multiple devices. For example, I
    might have both a laptop and a smart
  • 17:41 - 17:46
    phone. They might both use the same key.
    But in this case if I require state full
  • 17:46 - 17:50
    encryption, then my laptop and the
    smartphone would have to coordinate to
  • 17:50 - 17:54
    make sure that they never reuse the same
    nonces. Whereas if both of them simply take
  • 17:54 - 17:58
    nonces at random, they don't need to
    coordinate because it was very high
  • 17:58 - 18:02
    probability they'll simply never choose
    the same nonce. Again assuming the nonce
  • 18:02 - 18:06
    space is big enough. So there are some
    cases where stateless encryption is quite
  • 18:06 - 18:11
    important, in particular where the same
    key is used by multiple machines. So I
  • 18:11 - 18:14
    wanted to find, more precisely, what
    security means for nonce based
  • 18:14 - 18:19
    encryption. And in particular, I want to
    emphasize that the system must remain
  • 18:19 - 18:23
    secure when the nonce are chosen by
    the adversary. The reason it's important
  • 18:23 - 18:27
    to allow the adversary to choose the
    nonces is because the adversary can
  • 18:27 - 18:31
    choose which cipher text it wants to
    attack. So imagine the nonce happens to
  • 18:31 - 18:35
    be a counter and it so happens that when
    the couter hits the value fifteen, maybe
  • 18:35 - 18:39
    at that point it's easy for the adversary
    to break semantic security. So the
  • 18:39 - 18:44
    adversary will wait until the fifteenth
    packet is sent and only then he will ask
  • 18:44 - 18:48
    to break semantic security. So when we
    talk about nonce based encryption, we
  • 18:48 - 18:53
    generally allow the adversary to choose
    the nonce and the system should remain
  • 18:53 - 18:58
    secure even under those settings. So let's
    define the CPA game in this case and it's
  • 18:58 - 19:02
    actually very similar to the game before.
    Basically the attacker gets to submit
  • 19:02 - 19:07
    pairs of messages MI, MI0, and MI1.
    Obviously they both have to be of the same
  • 19:07 - 19:12
    length. And he gets to supply the nonce.
    And in response, the adversary is given
  • 19:12 - 19:16
    the encryption of either MI0, or MI1. But
    using the nonce that the adversary
  • 19:16 - 19:21
    chose. And of course, as usual, the
    adversary's goal is to tell whether he was
  • 19:21 - 19:25
    given the encryption of the left plain
    text or the right plain text. And as
  • 19:25 - 19:29
    before the adversary gets to iterate these
    queries and he can issue as, as many
  • 19:29 - 19:34
    queries as he wants, we usually let q
    denote the number of queries that the
  • 19:34 - 19:38
    adversary issues. Now the only restriction
    of course, which is crucial, is that
  • 19:38 - 19:42
    although the adversary gets to choose the
    nonces, he's restricted to choosing
  • 19:42 - 19:47
    distinct nonces. The reason we force him
    to choose distinct nonces is because
  • 19:47 - 19:51
    that's the requirement in practice. Even
    if the adversary fools Alice into
  • 19:51 - 19:55
    encrypting multiple messages for him,
    Alice will never use the same nonce
  • 19:55 - 19:59
    again. As a result, the adversary will
    never see messages encrypted using the
  • 19:59 - 20:04
    same nonce and therefore, even in the
    game, we require that all nonce be
  • 20:04 - 20:08
    distinct. And then as usual we say that
    the system is a nonce based encryption
  • 20:08 - 20:13
    system that's, semantically secure under a
    chosen plain text attack if the adversary
  • 20:13 - 20:18
    cannot distinguish experiment zero where
    he's given encryptions of the left
  • 20:18 - 20:23
    messages from experiment one where he's
    given encryptions of the right messages.
  • 20:23 - 20:27
    So let's look at an example of a nonce
    based encryption system. As before, we
  • 20:27 - 20:32
    have a secure PRF that takes inputs in the
    nonce space R and outputs strings in the
  • 20:32 - 20:37
    message space M. Now when a new key is
    chosen, we're going to reset our counter R
  • 20:37 - 20:41
    to be zero. And now we encrypt the
    particular message M, what we will do is
  • 20:41 - 20:45
    we will increment our counter R, and then
    encrypt the message M using the
  • 20:45 - 20:49
    pseudorandom function applied to this
    value R. And as before, the cipher text is
  • 20:49 - 20:54
    going to contain two components, our
    current value of the counter and then the
  • 20:54 - 20:59
    one time pad encryption of the message M.
    And so my question to you is whether this
  • 20:59 - 21:03
    is a secure, non-spaced encryption system.
    So the answer as before is yes, but only
  • 21:03 - 21:08
    if the nuance space is large enough. So as
    we increment the counter R, it will never
  • 21:08 - 21:13
    cycle back to zero so that the nuances
    will always, always be unique. We argue
  • 21:13 - 21:18
    security the same way as before. Because
    the PRF is secure, we know that this
  • 21:18 - 21:23
    encryption system is indistinguishable
    from using a truly random function. In
  • 21:23 - 21:27
    other words, if we apply a truly random
    function to the counter and XOR the
  • 21:27 - 21:33
    results with, the plain text M. But now
    since the nuance R never repeats, every
  • 21:33 - 21:37
    time we compute this F of R, we get a
    truly random uniform and independent
  • 21:37 - 21:43
    string so that we're actually encrypting
    every message using the one time pad. And
  • 21:43 - 21:48
    as a result, all the adversary gets to see
    in both experiments are basically just a
  • 21:48 - 21:53
    pair of random strings. So both the
    experiment zero and experiment one the
  • 21:53 - 21:57
    adversary get's to see exactly the same
    distribution, namely, the responses to all
  • 21:57 - 22:02
    this chosen plain text queries are just
    pairs of strings that are just uniformly
  • 22:02 - 22:07
    distributed and this is basically the same
    in experiment zero and experiment one and,
  • 22:07 - 22:12
    therefore, the attacker cannot distinguish
    the two experiments. And since he cannot
  • 22:12 - 22:16
    win the semantic security game with a
    truly random function he, also, cannot win
  • 22:16 - 22:21
    the semantics security game with the
    secure PRF, and, therefore, the scheme is
  • 22:21 - 22:25
    secure. So now we understand what it means
    for a symmetric system to be secure when
  • 22:25 - 22:30
    the keys used to encrypt multiple messages
    the requirement is that it be secure under
  • 22:30 - 22:35
    a chosen plan of attack. And we said that
    basically, the only way to be secure under
  • 22:35 - 22:39
    a chosen plain text attack is either to
    use randomized encryption, or to use, use
  • 22:39 - 22:43
    nonce spaced encryption where the
    nonce never repeats. And then in the
  • 22:43 - 22:48
    next two segments, we're gonna build two
    classic encryption systems that are secure
  • 22:48 - 22:50
    when the key is used multiple times.
Title:
Security for many-time key (23 min)
Video Language:
English

English subtitles

Revisions