Loading
Nota de Estudos
Study Reminders
Support
Text Version

Modos de Operações do Bloco Cifradores

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

Fundamentos de CryptographyProf. Dr. Ashish Choudhury (Ex-) Infosys Foundation Career Development Cátedra Instituto Professor de Technology-BangaloreLecture-16Modes de Operações do Bloco Cifradores Parte IOlá, todos, bem-vindos à palestra 15. Esta será a primeira parte dos modos de operações de cifras de blocos. (Consulte o Tempo de deslizamento: 00 :34) E o roteiro para esta palestra é o seguinte. Veremos como obter cifras seguras eficientes de CPA via 2 modos de operações, a saber, o modo BCE e o modo CBC; os modos de operações restantes veremos no módulo seguinte. (Consulte o Tempo do slide: 00 :49) Então, só para relembrar, na última palestra, tínhamos visto um processo de criptografia segura do candidato CPA para criptografar?-bit mensagens e as 2 desvantagens que identificamos neste processo de criptografia são que o tamanho do texto cifrado é grande comparado com o texto simples. Especificamente se? e l são iguais então o texto cifrado é o dobro do tamanho do texto à plaina. E a segunda desvantagem aqui é que cada instância do processo de criptografia requer uma aleatoriedade fresca de pouco l-bits. (Consulte o Tempo do slide: 01 :21) Então, isso nos leva ao que chamamos como modos de operações de cifração de blocos. E basicamente o objetivo aqui é o seguinte. Imagine que você recebe uma função chaveada que poderia ser uma função aleatória pseudo ou uma pseudo permutação aleatória ou uma forte permutação pseudoaleatória. E a construção que você é dada com, é uma função de preservação de comprimento. A saber, o tamanho do bloco e o tamanho da saída são os mesmos, digamos?. E pela simplicidade assumimos isso? =?, mas poderia ser qualquer função polinomial do seu parâmetro de segurança. Então você é dada a descrição de tal função?. E o objetivo aqui é o seguinte. Temos agora uma grande mensagem formada por vários blocos de?-bits. Ou seja, imagine que você tem l número de blocos. E nosso objetivo é chegar a um processo de criptografia onde eu possa criptografar mensagens tão grandes, tal que resulte em processo de criptografia deve ser CPA-seguro. E o processo de criptografia resultante deve ter o uso de aleatoriedade o mínimo possível. A expansão do texto cifrado deve ser o mínimo possível e deve haver um apoio para o paralelismo. Isso significa, se houver um escopo onde eu possa criptografar vários blocos em paralelo, dado que tenho vários processos de computação disponíveis comigo, então o processo de miccriptação deve fornecer esse suporte. E o mais importante, a segurança geral do meu processo de criptografia deve depender da mínima suposição de segurança da função?. Isso significa que deve bastar se a minha função? é apenas uma função pseudo-aleatória. Esse é o nosso objetivo geral. (Consulte o Slide Time: 03 :09) Então, vamos ver uma das formas de fazer isso. E então vamos analisar, quais dessas propriedades a seguir que listei aqui são alcanadas e quais não são alcanadas. Assim, este modo é chamado como o livro de código eletrônico, ou BCE em resumo. E para demonstrá-lo, imagine que eu tenho uma mensagem formada por 3 blocos de?-bits. Então a forma como eu vou criptografar no modo BCE aqui é a seguinte: já que eu tenho 3 blocos de?-bits, cada um deles vai ser criptografado usando a mesma chave?. Então eu alimento o mesmo? a 3 invocações da minha função subjacente?, então essa é a chave. E bloquear entrada para as invocações subjacentes da função? são na verdade os blocos da mensagem, isso significa? 1 vai como está, como o bloco para a primeira invocação. Da mesma forma, para a segunda chamada,? 2 goesas it is, como a entrada de blocos. E na terceira chamada,? 3serves como a entrada de blocos e a saída resultante? 1,? 2,? 3is basicamente o que é o meu texto cifrado. Isso significa que o texto cifrado será a concatenação de? 1,? 2,? 3. Então, em geral o processo de criptografia aqui é a avaliação da função keyed?? na entrada do bloco??. E o processo de decriptografia aqui é basicamente o inverso da função keyed?? sob a mesma chave?, no bloco? ?hciphertext??, para recuperar de volta o bloco? ?h plaintexto. Isso significa, você pode ver que neste caso minha função?? deve ser uma permutação pseudo-aleatória chaveada, não deve ser de muitos a uma só função senão a decriptografia se tornará ambígua. Também outra propriedade interessante aqui é que meu tamanho de texto cifrado é exatamente o mesmo que o tamanho da mensagem. Então, se eu tenho 3 blocos de?-bits cada um, então eu tenho um texto cifrado composto por 3 blocos de?-bits each.Além disso, esse processo de criptografia ou modo de criptografia suporta paralelismo. Isso significa, se eu tenho 3 processadores de computação disponíveis comigo, então? 1 podem ser computados independentemente de? 2, que podem ser computados independentemente de? 3. Isso significa, ao mesmo tempo, em paralelo, eu posso computar? 1,? 2,? 3, mesmo sustos para a criptografia e para o descrição.Agora, vamos responder a parte mais importante, se este modo de BCE é CPA-seguro ou não? E a resposta é absolutamente não, porque como se pode ver aqui, que este modo de BCE é um esquema determinístico de encriptação. Isso significa onde quer que os blocos de mensagens estejam se repetendo, e se eu criptografar aqueles repetidos bloqueio de mensagem sob a mesma chave?, vou ver o mesmo bloco de texto cifrado, que é fundamentalmente contra o princípio de que, para atingir a segurança CPA, meu processo de criptografia deve ser randomizado. Uma vez que esse processo de criptografia é determinista, de forma alguma eu posso afirmar que esse processo de criptografia é CPA-secure. (Consulte o Tempo do slide: 05 :59) Para lhe dar uma sensação de como esse modo de BCE pode ser inseguro, vejamos um exemplo prático. Então, suponhamos que eu queira criptografar uma imagem usando o modo BCE. E já que uma imagem é basicamente uma coleção de pixels, o que eu posso fazer é que eu possa imaginar um grupo de pixels na minha imagem como um bloco e alimentá-lo como o bloco de mensagens durante a chamada do modo BCE. Então considere a imagem em preto e branco (a primeira imagem acima), que eu quero criptografar. E se eu criptografá-lo usando o modo BCE, a imagem criptografada ficará como a segunda imagem acima. E como você pode ver a partir da imagem criptografada, você tem um padrão absolutamente claro que está disponível na imagem criptografada. E a razão pela qual está acontecendo é, onde quer que você tenha um grupo de pixels pretos, ele sempre produzirá o mesmo tipo de texto cifrado e onde quer que você tenha um grupo de pixels brancos que sempre produzirá o mesmo tipo de texto cifrado. E esse padrão será claramente visível na imagem criptografada. E se eu enviar esse tipo de imagem criptografada sobre o canal inseguro interceptado por um adversário, o adversário pode facilmente descobrir o que exatamente é o image.Idealmente, se eu quiser criptografar a imagem em preto e branco, usando algum assim chamado de modo seguro, ele deve produzir uma imagem criptografada, semelhante à terceira imagem acima, onde não há absolutamente nenhum padrão disponível na imagem criptografada, independentemente de ser um pixel branco que eu estou criptografando ou se é um pixel preto, eu estou criptografando. Depois veremos como exatamente aqueles modos seguros se parecem. Mas, por enquanto, se eu focar apenas no modo BCE, ele é completamente inútil. A lição que aprendemos com este exemplo é que uma cifra de blocos, a saber, a função??, não deve ser usada diretamente para criptografar uma mensagem. E se você ver a sintaxe do modo BCE, o que estávamos realmente fazendo, estávamos fazendo esse erro, fomos criptografar diretamente a mensagem usando as invocações de??, em que a mesma chave estava se acostumando em todas as invocações. Então, não devemos fazer isso. E se você relembrar o nosso esquema seguro candidato CPA, nunca criptografamos a mensagem diretamente alimentando-a para a função??. Nós realmente alimentamos um aleatório?-entrada para a função??, geramos o pad, que foi XORed com a mensagem, para produzir o texto cifrado real. Sendo assim, esse é o modo BCE, e claramente, ele não é CPA-secure. (Consulte o Slide Time: 08 :10) Agora vamos para o segundo modo, que também chamamos como chaining block block, ou modo CBC. E este modo foi usado em algumas versões mais antigas do protocolo real do mundo TLS. Novamente, para demonstração, assume que você tem 3 blocos, cada um consistindo em?-bytes. Assim, a forma como criptografamos aqui é a seguinte. Nós primeiro escolhemos um aleatório??, que denotamos como? 0 e que vai ser uma parte do texto cifrado. E o comprimento de? 0será o mesmo que a entrada de tamanho de bloco da minha função subjacente??, isso significa?-bytes. E agora eu vou criptografar 3 blocos individuais invocando 3 invocações da minha função??, com a mesma chave?. A primeira invocação da função?? é basicamente sobre o XOR da mensagem? 1 com o??, servindo como o bloco. Eu obtenho a saída? 1 e a razão pela qual este modo é chamado como o bloco de texto cifrado chaining é que agora vamos fazer uma espécie de processo de chaining. O bloco de texto cifrado? 1 que eu obtive agora, ele vai ser acorrentado e XORed com o segundo bloco da minha mensagem. E o resultante XOR, serve como entrada de bloco para a minha segunda chamada da minha função?? e me dá a saída? 2. E agora isso serve como cadeia para o próximo bloco da mensagem, XORed com o terceiro bloco, alimentado como um bloco para a terceira invocação da minha função? ?.E eu paro com o bloco de texto cifrado 3, e meu texto geral cifrado será? 0 concatenado com? 1,? 3,? 3. Então em geral, se eu quiser fazer a criptografia do bloco? ?h, então é basicamente a avaliação da função chaveada de??, em que a entrada de blocos é XOR do bloco de mensagens atual e o bloco cifrado anterior. É por isso que o nome ciphertext block chaining. E o aleatório??? que estamos selecionando aqui no início da criptografia tem que ser uma parte do texto cifrado. Se eu quiser decriptografar? ?hbloco de texto cifrado, a forma como faço isso é computar o inverso da função chaveada?? com respeito à mesma chave. E se por exemplo, se eu quiser decriptografar digamos? 3, eu computo o inverso de? 3 com relação à função??, e se eu inverter, eu basicamente obtento XOR de? 3 e? 2. E para cancelar o efeito de? 2, eu só tenho que levar o XOR de? 2 com a saída recuperada. Sendo assim, é o que é a decriptografia genérica do bloco? ?h. Isso significa minha função??? deve ser uma permutação chave se eu quiser inequivocamente fazer a decriptografia part.Agora, qual é o tamanho do texto cifrado geral aqui, bem o número de blocos no texto cifrado é exatamente o mesmo que o número de blocos na mensagem mais um bloco adicional para o?? parte. Isso significa em termos de expansão de mensagens, isso é um mínimo que você pode pensar. Isso é significativamente melhor em comparação com o candidato, esquema seguro de CPA baseado em PRF, que tínhamos visto na última palestra. No entanto, uma das desvantagens desse modo é que ela não suporta paralelismo. Então isso significa que a criptografia do segundo bloco pode acontecer somente quando a criptografia do primeiro bloco aconteceu. Porque eu preciso disso para o propósito de chaining e assim por diante. Mais importante, esse processo de criptografia é um processo de criptografia randomizado, porque toda vez que eu tenho uma nova mensagem, o?? será colhida aleatoriamente, e que basicamente aciona a aleatoriedade em todo o processo de chaining. Na verdade, podemos provar formalmente que se a função subjacente?? é um PRP seguro conforme a definição de distinguibilidade, então este modo de operação é realmente CPA-seguro. E você pode ver qualquer uma das referências, a saber, o livro de Katz-Lindell ou Boneh et al, para a prova real. Não vou dar a prova real aqui. (Consulte o Slide Time: 12 :16) Agora vamos ver um aspecto interessante do modo CBC. Então a forma como eu discuti o modo CBC até agora é que eu assumi que o número de blocos na mensagem é basicamente um múltiplo do comprimento do bloco do seu subjacente??. Então imagine que o comprimento do bloco da função subjacente?? is?-bytes. Portanto, pode haver 2 casos com relação à mensagem subjacente, que eu quero criptografar. Se o número de bytes na minha mensagem subjacente que eu quero criptografar já é um múltiplo de?-bytes, então eu posso simplesmente dividir minha mensagem em vários chunks de?-bytes e fazer o modo CBC de criptografia como eu discuti. (Consulte o Tempo do slide: 13 :01) Mas e se a minha mensagem subjacente não for um múltiplo de?-bytes. O comprimento da mensagem não é um múltiplo de grandes L bytes. Isso significa que eu tenho que agora fazer algum tipo de preenchimento antes de realmente criptografar minha mensagem. Pois se eu não fizer o preenchimento, não posso aplicar o modo CBC de criptografia. Porque mesmo que eu divida minha mensagem em blocos de?-bytes, o último bloco não será de comprimento?-bytes. E daí, não posso aplicar uma instância da minha função subjacente??. Então o que o Iam vai fazer aqui é eu vou discutir que tipo de preenchimento temos que usar e aplicar a mensagem mysubjacente antes de fazer o modo CBC de criptografia. Por isso, meu mecanismo de preenchimento tem que ser invertível. E tem que ser um direito inequívoco. Então, deixe-me discutir um dos importantes mecanismo de preenchimento que chamamos como PKCS versão 5 padding. E a ideia aqui é deixar? denotar o número de bytes que eu preciso adicionar no último bloco na minha mensagem?. Para que a mensagem geral de preenchidos, seu comprimento torne-se um múltiplo de?-bytes. Então uma vez que eu identifiquei o valor de pouco?, o que eu basicamente faço é anexar? número de bytes no último bloco, e cada um deles representa o valor inteiro?. Uma vez que eu fizer isso, o comprimento da minha mensagem padicionada será um múltiplo de?-bytes, o qual eu posso dividir em vários blocos de?-bytes. E agora eu posso fazer o meu modo CBC de encriptação usual Como eu vou fazer a decriptografia. Bem, no final da decriptografia, o receptor tentará descriptografar o último bloco de texto cifrado conforme o modo CBC usual. E então o que vai fazer é que uma vez que recupere o padicionado último bloco, a saber? 2 ′ neste exemplo, vai-se ler o último valor de byte. E a partir desse último valor de byte, ele vai aprender o valor de?. E vai ver se o último recuperado? bytes realmente representa o valor de byte?. Se for esse o caso, basta retirar aqueles últimos? bytes e a coisa restante será a mensagem real que foi criptografada e comunicada pelo remetente. Por outro lado, se o último? bytes para não representar o valor inteiro?, isso significa que algum erro ocorreu enquanto envia a mensagem criptografada e daí o receptor vai para a saída bad padding.Agora, com base no processo de criptografia e decriptografia, você pode estar se perguntando que qual deve ser o alcance de?? Isso significa quantos bytes precisam ser anexados, de modo que minha mensagem acolchada, seu comprimento se torne um múltiplo de big?-bytes. E a intuição diz que o alcance de? deve de 0? − 1. 0 porque eu posso ter uma mensagem cujo comprimento já é um múltiplo de?-bytes e? − 1 porque eu posso ter uma mensagem, onde na verdade eu preciso anexar? − 1 bytes. Mas acontece que o alcance de? não pode ser de 0? − 1, porque isso não vai levar a enchimento invertível. Porque isso pode levar à ambiguidade se o preenchimento ocorreu ou o preenchimento não ocorreu. O caso problemático é? = 0, um receptor não pode distinguir se algum preenchimento aconteceu ou não aconteceu quando ele está decriptografando. Então, é por isso que quando? = 0, na verdade nós fazemos? =?. Isso significa se no final do remetente ’ não for necessário nenhum preenchimento, então para indicar de forma inequívoca para o receptor, o remetente vai adicionar um bloco completo de?-bytes, cada um deles representando o valor inteiro?. Isso é uma indicação para o receptor que na verdade nenhum preenchimento ocorreu, e todo o último bloco tem que ser despoado. Então o alcance de? não é 0? − 1, mas na verdade 1 para?. Sendo assim, é assim que podemos realmente fazer uma criptografia de mensagens longas arbitrárias usando o modo CBC de criptografia fazendo esse preenchimento. (Consulte O Slide Time: 17 :09) Agora, deixe-me também discutir aspecto muito interessante do modo CBC, o que chamamos como variante stateful do modo CBC. Se você vê a forma como o modo CBC é definido, se temos 2 mensagens diferentes, digamos? e? ′ em sequência, uma após a outra, claro de comprimentos diferentes, digamos por exemplo, mensagem? consistindo de 3 blocos, seguido por outra mensagem? ′ consistindo de 2 blocos, então este é o senador de maneira ideal deve ter criptografado? e? ′. Para criptografar?, o remetente deveria ter escolhido algum independente??, denotado como? ?1. E deveria ter feito a parte chavante. E então se houver outra mensagem, diga uma mensagem de acompanhamento? ′, o remetente deve preferencialmente escolher outro independente??, digamos? ?2 e deveria ter feito o modo CBC de criptografia. Mas um implementador inteligente pode imaginar que, se emissor e receptor estiverem sincronizados, e se o mesmo emissor e o mesmo receptor vão fazer uma sequência de várias comunicações criptografadas, então por que dom ’ t nós mantemos estado?E o que eu sustento significa manter o estado aqui é que, por que não podemos reter o último bloco de texto cifrado da última mensagem entre o emissor e o receptor e utilizá-lo como o?? para a próxima mensagem em que o remetente vai criptografar e comunicar ao receptor. Então isso é o que eu quero dizer mantendo o Estado aqui. E na verdade se nós fizermos isso, há uma vantagem que chegamos aqui. Em primeiro lugar, para a próxima mensagem, a saber? ′, qual remetente quer comunicar,??? não precisa ter que ser escolhido; tanto o emissor quanto o receptor saberão que, já que estão usando uma variante estadual,? 3is vai servir como o??. Assim, isso salva a parte de aleatoriedade. E também proporciona vantagem em termos de largura de banda, pois agora? 3 não precisa ser comunicado novamente quando? ′ é criptografado. Será conhecido anyhow para o receptor que a decriptografia precisa acontecer com relação a? 3, então?-bytes não precisam ser comunicados porque o tamanho de? 3 teria sido?-bytes. Por isso, dessa forma, estamos realmente economizando largura de banda. E agora você pode estar se perguntando se a variante stateful é realmente CPA-segura ou não e intuitivamente você pode sentir que a variante do estado deve ser CPA-segura. Porque se realmente o remetente teria uma mensagem maior?, que é uma concatenação de? e? ′, então esta é a forma como o emissor e o receptor teriam realmente realizado o modo CBC de criptografia e decriptografia:? 3 teria servido como o?? e teria sido usado para criptografar o bloco de mensagens? 4 e assim por diante, essa é a intuição. Mas com base na intuição não podemos dizer formalmente que se um esquema modificado é seguro ou não. (Consulte o Slide Time: 19 :51) O que vamos agora demonstrar é que a variante do estado definitivamente não é CPA-segura já que há um ataque aqui. O ataque basicamente decorre do fato de que na variante estadual, adversário já está ciente do??? que vai ser usado para a mensagem futura, o que não é o caso, se o remetente teria realmente criptografado uma mensagem longa, uma única mensagem formada por ambos? e? ′. Nesse caso, o adversário não teria conhecimento do???, que de fato vai ser usado para? 4. Mas no caso quando? e? ′ são tratados como 2 mensagens diferentes, a saber, uma sequência de mensagens, o adversário já está ciente do??, que vai ser usado para fazer a parte de chaining para criptografar a mensagem? ′. Isso significa que, em certo sentido, tem o controle sobre a aleatoriedade, que o adversário pode explorar. E, ao fazer consultas de oracle de criptografia, ele pode identificar completamente qualquer que seja o bloco de mensagens que ele deseje identificar. Por isso, vejamos o cenário de ataque aqui. Imagine que temos um remetente. E dizer que a primeira mensagem que ela quer criptografar é uma concatenação de 3 blocos, cada um de?-bytes. Ele faz isso usando uma variante stateful do modo CBC. Então, desde a mensagem? é a primeira mensagem que ela estava enviando para o receptor, o?? será colhida aleatoriamente. E? 1,? 2,? 3 será basicamente criptografia de? 1,? 2,? 3 e dizem que há um atacante CPA, que intercepta esses pacotes criptografados. E agora o adversário sabe a relação ou o jeito? 1,? 2,? 3 foram computados. O adversário não sabe a chave?, ele é desconhecido para o atacante, mas o adversário conhece a matemática subjacente que é usada para computar? 1,? 2,? 3.Now imagine que o atacante CPA está sob o seguinte estado: ele de alguma forma sabe que a mensagem? 1 ou o primeiro bloco da mensagem? é na verdade ou seja? 10 ou? 11. Essa é uma informação prévia de alguma forma disponível com adversário. Agora se a variante stateful do modo CBC é de fato a CPA segura, então mesmo que o adversário tenha esse conhecimento prévio e o adversário veja essa comunicação criptografada, ao apenas ver o bloco cifrado? 1, adversário não deve ser capaz de descobrir se é uma criptografia de fato? 10 ou? 11, exceto com probabilidade 12, mesmo que o adversário obtenha acesso ao serviço de oracle de criptografia. Mas agora o que vamos demonstrar aqui é que se o emissor e o receptor estão usando uma variante stateful do modo CBC de criptografia, como um atacante de CPA inteligente pode obter serviço de oráculo de criptografia e identificar se ele é? 10 que é criptografado em? 1 ou se é? 11 que é criptografado. Então é isso que vamos demonstrar. Suponha que o CPA-atacante pede um serviço de criptografia-oracle para uma nova mensagem? ′, que consiste em 2 blocos, digamos? 4 e? 5 e? 4is selecionados de tal forma que? 4 =? ?⨁?10? 3. A razão pela qual? 4is selecionados como este, ficará claro para você muito em breve. ? 5 poderia ser qualquer bloco arbitrário de?-bytes, não me importo? 5, mas? 4is selecionados assim. E já que estamos no regime de CPA, não podemos impedir que um atacante CPA faça consulta de oracle de criptografia para este tipo de mensagem. Agora, em resposta, suponhamos que o remetente não esteja ciente do fato de estar interagindo com um adversário e ele é influenciado para realmente criptografar a mensagem? ′, consistindo destes 2 blocos? 4 e? 5 com a mesma chave?, mas usando uma variante stateful do modo CBC de criptomo.Então, a criptografia agora não será mais composta de um??, porque o?? para criptografar a mensagem? ′ será o bloco de texto cifrado? 3. Então adversário saberá que o bloco de texto cifrado? 4is o valor da função keyed?? sobre o XOR de? 4 e? 3. Ou seja,? 4 =?? (?4.? 3). E agora se eu substituir o valor de? 4, o caminho? 4 foi colhida pelo adversário, o efeito de? 3 cancela fora. E basicamente? 4turns fora para ser o valor da função keyed no XOR de?? e? 10.Now, adversário também já viu o valor de? 1. Porque essa foi a comunicação criptografada, que adversário interceptou. E desde o meu? é uma permutação, é um chaveamento de um-para-um sobre mapeamento. Então adversário sabe que? 4is vai ser igual a? 1, se e somente se o bloco de mensagens? 1is o mesmo? 10, então tem todas as informações disponíveis com ele para saber se o bloco cifrado? 1 foi uma criptografia de? 10, ou se é uma criptografia de? 11. E com probabilidade um, o nosso adversário vai identificar o que exatamente é o caso. É por isso que não podemos mais afirmar que a variante stateful do modo CBC de criptografia é CPA-secure. E este ataque foi de fato lançado em uma da versão anterior do protocolo TLS onde os implementadores por engano achavam que a variante de estado do modo CBC será CPA-segura, e eles acabaram implantando isso. E essa fraqueza foi explorada pelos atacantes para lançar o que nos chamamos de ataque de besta. E só mais tarde é que este ataque foi formalmente identificado e as pessoas percebem que o que exatamente é a importância da prova formal. Por isso, a lição que aprendemos com este exemplo é que você não deve fazer absolutamente nenhuma modificação em um esquema de cripto que tenha sido formalmente provado ser seguro, mesmo que as modificações parecidas benignas a você até e a menos que você tenha uma prova formal para a segurança do esquema modificado. Então, isso nos leva ao final desta palestra. Só para resumir, tínhamos visto 2 modos de operações das permutações pseudo-aleatórias, a saber, o modo BCE, e o modo CBC. O modo BCE definitivamente não é CPA-seguro e não recomendado para usar na prática e o modo CBC é o CPA seguro. Porém, não vimos a prova, mas é preciso acreditar que é CPA segura. A desvantagem do modo CBC é que ele não é stateful, isso significa que não podemos manter o estado através de várias mensagens, e não se sustenta para o paralelismo. Na próxima palestra, vamos ver 2 outros modos de função pseudo-aleatória e permutações pseudoaleatórias que são a CPA segura, e que de fato se livam das restrições que estão aí ou das desvantagens que estão lá com relação ao modo CBC.