WEBVTT 00:00:00.000 --> 00:00:03.837 Neste segmento, nós vamos construir sistemas de criptografia autenticados. Uma vez que nós 00:00:03.837 --> 00:00:08.250 já tem garantido de criptografia CPA, e temos MACs seguras, a pergunta natural 00:00:08.250 --> 00:00:12.824 é se podemos combinar os dois de alguma forma, a fim de obter criptografia autenticado. 00:00:12.824 --> 00:00:15.721 E se, que é exatamente o que vamos fazer neste segmento. Criptografia autenticado 00:00:15.721 --> 00:00:20.447 foi introduzido no ano de 2000, em dois artigos independentes que apontam para a 00:00:20.447 --> 00:00:25.915 final deste módulo. Mas antes disso, muitos crytpolibraries desde uma API que 00:00:25.915 --> 00:00:31.215 separadamente suporte a criptografia CPA seguro, amd MAC-ing. Então, houve uma 00:00:31.215 --> 00:00:36.175 função para implementar criptografia segura CPA. Por exemplo, a CVC com um aleatória 00:00:36.175 --> 00:00:41.136 IV. E outra função para a implementação de um MAC. E então todos os desenvolvedores que 00:00:41.136 --> 00:00:45.646 queria implementar a criptografia, teve que, ele próprio, chamar separadamente o seguro CPA 00:00:45.646 --> 00:00:50.552 esquema de criptografia eo sistema MAC. Em particular, todos os desenvolvedores tiveram que inventar 00:00:50.552 --> 00:00:55.697 maneira própria de combinar criptografia e MAC-ing para fornecer algum tipo de 00:00:55.697 --> 00:00:59.376 criptografia autenticado. Mas desde que os objetivos da criptografia combinando e MAC-ing 00:00:59.376 --> 00:01:03.690 não foi bem compreendida desde criptografia autenticado ainda não foi definida. Ele 00:01:03.690 --> 00:01:08.497 realmente não estava claro quais combinações de criptografia e MAC-ing estão corretas e 00:01:08.497 --> 00:01:13.243 que não são. E assim, cada projeto, como eu disse tinha de inventar sua própria combinação. 00:01:13.243 --> 00:01:17.202 E, de fato, nem todas as combinações eram corretas. E eu posso te dizer que o mais 00:01:17.202 --> 00:01:22.556 erro comum em projetos de software foram basicamente incorretamente combinando o 00:01:22.556 --> 00:01:27.025 criptografia e mecanismos de integridade. Portanto, esperamos que, até o final deste módulo, você 00:01:27.025 --> 00:01:31.260 saberá como combiná-los corretamente, e você não estará fazendo estes erros 00:01:31.260 --> 00:01:35.174 si mesmo. Então, vamos olhar para algumas combinações de criptografia segura e CPA 00:01:35.174 --> 00:01:39.303 MAC, que foram introduzidas por diferentes projetos. Então, aqui estão três exemplos. Assim, 00:01:39.303 --> 00:01:43.816 , antes de tudo, em todos os três exemplos, há uma chave separada para a criptografia, e 00:01:43.816 --> 00:01:47.774 uma chave separada para MACing. Estas duas chaves são independentes um do outro, e 00:01:47.774 --> 00:01:52.224 ambos são gerados em tempo de configuração da sessão. E nós vamos ver como gerar estes 00:01:52.224 --> 00:01:57.071 duas teclas mais tarde no curso. Assim, o primeiro exemplo é o protocolo SSL. Assim, o 00:01:57.071 --> 00:02:02.681 maneira SSL combina criptografia e MAC, na esperança de alcançar a criptografia autenticado 00:02:02.681 --> 00:02:07.656 é o seguinte. Basicamente, você toma o texto simples, m, e então você calcular um MAC 00:02:07.656 --> 00:02:13.415 no texto simples, m. Então você usar sua chave MAC, KI para calcular tag para esta mensagem 00:02:13.415 --> 00:02:17.787 m. E então você pode captionate a marca para a mensagem e então você criptografar o 00:02:17.787 --> 00:02:22.580 captionation da mensagem ea marca eo que sai é o texto cifrado final. 00:02:22.580 --> 00:02:26.710 Então essa é a opção número um. A segunda opção é o que faz seg IP. Assim 00:02:26.710 --> 00:02:31.160 aqui, você leva a mensagem. A primeira coisa que você faz é criptografar a mensagem. 00:02:31.160 --> 00:02:35.692 E então, você calcular um tag no texto cifrado resultante. Então você percebe o 00:02:35.692 --> 00:02:40.238 tag si mesmo é calculado sobre o texto cifrado resultante. Uma terceira opção é o que o 00:02:40.238 --> 00:02:45.429 protocolo SSH faz. Então, aqui, o SSH leva a mensagem e criptografa-lo usando um CPA 00:02:45.429 --> 00:02:50.944 esquema de criptografia segura. E então, para ele, concatenadas uma marca da mensagem. O 00:02:50.944 --> 00:02:55.567 diferença entre IPsec e SSH, é que em IPsec, a marca é calculado sobre o 00:02:55.567 --> 00:02:59.988 texto cifrado, que, em SSH, o tag no computadorizada sobre a mensagem. E assim estes 00:02:59.988 --> 00:03:04.536 são três maneiras completamente diferentes de combinar a criptografia e MAC. Eo 00:03:04.536 --> 00:03:09.090 pergunta é, qual destes é segura. Então, eu vou deixar você pensar sobre isso por um 00:03:09.090 --> 00:03:12.105 segundo, e então quando nós vamos continuar a fazer a análise em conjunto. Okay. Então, vamos 00:03:13.197 --> 00:03:17.164 início com o método SSH. Assim, o método SSH você notar que a marca é calculado 00:03:17.164 --> 00:03:21.629 na mensagem e então concatenado em claro para o texto cifrado. Agora, esta é 00:03:21.629 --> 00:03:26.407 realmente um grande problema porque MAC em si não são projetados para fornecer 00:03:26.407 --> 00:03:30.784 confidencialidade. Macs são projetados somente para integridade. E, de fato, não há 00:03:30.784 --> 00:03:36.008 nada de errado com um MAC que, como parte da marca gera alguns pedaços da planície 00:03:36.008 --> 00:03:41.458 texto. Saídas de alguns pedaços da mensagem M. Isso seria uma marca perfeitamente bem. E ainda se 00:03:41.458 --> 00:03:46.667 fizemos isso, que seria completamente quebrar a segurança CPA aqui, porque alguns pedaços de 00:03:46.667 --> 00:03:51.815 mensagem são divulgados no texto cifrado. E assim, a abordagem SSH, mesmo que o 00:03:51.815 --> 00:03:56.595 especificidades da SSH estão bem e do protocolo em si não é comprometida pela 00:03:56.595 --> 00:04:00.818 esta combinação específica, geralmente é aconselhável não usar essa abordagem. Simplesmente 00:04:00.818 --> 00:04:05.928 porque a saída do algoritmo de assinatura MAC pode vazar bits da mensagem. Assim 00:04:05.928 --> 00:04:11.481 agora vamos olhar para SSL e IPsec. Como se vê, o método recomendado, na verdade 00:04:11.481 --> 00:04:16.556 é o método de IPsec. Porque acontece que não importa o CPA sistema seguro e MAC 00:04:16.556 --> 00:04:21.134 chave que você use a combinação é sempre vai fornecer criptografia autenticado. 00:04:21.134 --> 00:04:26.070 Agora deixe-me muito, muito brevemente explicar o porquê. Basicamente o que acontece é que, uma vez que criptografar 00:04:26.070 --> 00:04:31.005 mensagem bem o conteúdo da mensagem agora está escondido no interior do texto cifrado e agora 00:04:31.005 --> 00:04:35.761 quando calculamos uma marca do texto cifrado, basicamente, estamos travando, esta tag bloqueios 00:04:35.761 --> 00:04:40.815 texto a cifra e garante que ninguém pode produzir um texto cifrado diferente que 00:04:40.815 --> 00:04:45.314 olhar válido. E como resultado desta abordagem garante que quaisquer modificações na 00:04:45.314 --> 00:04:49.555 texto cifrado será detectado pelo decrypter simplesmente porque o MAC não é 00:04:49.555 --> 00:04:54.026 vai verificar. Como se vê, para a abordagem SSL, há na verdade são uma espécie de 00:04:54.026 --> 00:04:59.348 exemplos patológicos, onde combinam CPA sistema de criptografia seguro com um seguro 00:04:59.348 --> 00:05:03.542 MAC. E o resultado é vulnerável a um ataque escolhido cifra texto, de modo que ele faz 00:05:03.542 --> 00:05:07.978 na verdade não fornece criptografia autenticado. E, basicamente, a razão que 00:05:07.978 --> 00:05:12.824 poderia acontecer, é que há algum tipo de interação ruim entre a criptografia 00:05:12.824 --> 00:05:17.319 esquema eo algoritmo MAC. De tal modo que, de fato, haverá uma cifra escolhida 00:05:17.319 --> 00:05:21.752 ataque texto. Então, se você está projetando um novo projeto a recomendação agora é 00:05:21.752 --> 00:05:26.162 sempre usar criptografar então MAC porque isso é seguro, não importa qual CPA seguro 00:05:26.162 --> 00:05:30.607 algoritmo de criptografia e MAC seguro você está combinando. Agora, só para definir o 00:05:30.607 --> 00:05:37.995 terminologia, o método SSL é às vezes chamado MAC-then-encrypt. Eo 00:05:37.995 --> 00:05:45.039 método IPsec é chamado encrypt-then-MAC. O método SSH mesmo que seu 00:05:45.039 --> 00:05:51.898 não deveria usá-lo, é chamado de criptografar e-MAC. Ok, então eu vou muitas vezes referem-se a 00:05:51.898 --> 00:05:57.002 encrypt-then-MAC e MAC-then-criptografar para diferenciar SSL e IPsec. Ok, então 00:05:57.002 --> 00:06:02.112 apenas para repetir o que acabei de dizer. O método de IPsec encrypt-e-mac sempre 00:06:02.112 --> 00:06:07.160 nos fornecer uma criptografia autenticado. Se você começar do CPA cifra segura e um MAC seguro 00:06:07.160 --> 00:06:11.110 Você sempre terá criptografia autenticado. Como eu disse, MAC-depois-criptografar em 00:06:11.110 --> 00:06:15.737 fato, há casos patológicos, onde o resultado é vulnerável a fatos CCA e 00:06:15.737 --> 00:06:20.308 , portanto, não fornece criptografia autenticado. No entanto, a história é um pouco 00:06:20.308 --> 00:06:24.653 pouco mais interessante do que isso, na medida em que, ao que parece, se você está realmente usando 00:06:24.653 --> 00:06:29.224 modo aleatório contador ou CBC randomizado, em seguida, ao que parece, para aqueles que especial 00:06:29.224 --> 00:06:33.625 CPA esquemas de criptografia seguras, MAC-then-criptografar realmente dá autenticado 00:06:33.625 --> 00:06:38.028 criptografia e por isso é seguro. De fato, há mesmo uma mais interessante 00:06:38.028 --> 00:06:42.334 torcer aqui em que se você estiver usando o modo de contador ao acaso. Então, é suficiente 00:06:42.334 --> 00:06:46.804 que o seu algoritmo de MAC apenas ser um tempo seguro. Ele não tem que ser um totalmente 00:06:46.804 --> 00:06:51.561 MAC seguro. Ele só tem que ser seguro quando uma tecla é usada para criptografar uma mensagem única, 00:06:51.561 --> 00:06:56.088 ok? E quando falamos sobre a integridade da mensagem, vimos que há realmente 00:06:56.088 --> 00:07:00.575 6:56.08 MACs muito mais rápido que são um tempo seguro de MACs que são totalmente seguras. Como 00:07:00.575 --> 00:07:04.454 resultado, se você estiver usando o modo aleatório contra-MAC, em seguida, criptografar-pudesse realmente 00:07:04.454 --> 00:07:08.187 resultado em um mecanismo de criptografia mais eficiente. No entanto, eu vou repetir 00:07:08.187 --> 00:07:12.213 isso de novo. A recomendação é usar encrypt-then-MAC e estamos indo para ver um 00:07:12.213 --> 00:07:16.093 número de ataques a sistemas que não usam encrypt-then-MAC. E assim o fazem apenas 00:07:16.093 --> 00:07:20.120 que as coisas são seguras sem você ter que pensar muito sobre isso. Novamente, eu sou 00:07:20.120 --> 00:07:24.118 vai recomendar que você use sempre encrypt-then-MAC. Agora, uma vez que o conceito de 00:07:24.118 --> 00:07:27.759 criptografia autenticada tornou-se mais popular, um número de padronizada 00:07:27.759 --> 00:07:31.609 abordagens para a combinação de criptografia e MAC apareceu. E eram mesmo 00:07:31.609 --> 00:07:35.978 padronizado pelo Instituto Nacional de Padrões. Então eu só vou mencionar três 00:07:35.978 --> 00:07:41.031 destas normas. Dois deles foram padronizados pelo NIST. E estes são 00:07:41.031 --> 00:07:46.138 chamado Galois modo de contador e contador de modo CBC. E então deixe-me explicar o que fazem. 00:07:46.138 --> 00:07:51.245 modo Galois contador basicamente usa criptografia de modo contador, para um contador randomizado 00:07:51.245 --> 00:07:56.164 modo com um MAC Carter-Wegman, portanto, um fato muito Carter-Wagmon MAC. E a forma como o 00:07:56.164 --> 00:08:01.146 Carter-Wegman MAC trabalha em GCM é que é basicamente uma função hash da mensagem 00:08:01.146 --> 00:08:06.311 que está sendo MACed. E então o resultado é criptografada usando um PRF. Agora esse hash 00:08:06.311 --> 00:08:11.562 função em MGC é já bastante rápido até o ponto onde a maior parte do executando 00:08:11.562 --> 00:08:15.845 hora do GCM é dominada pelo modo de contador de criptografia e está ainda fez mais, 00:08:15.845 --> 00:08:22.371 em que a Intel introduz um PCLMULQDQ instrução especial especificamente 00:08:22.371 --> 00:08:27.432 projetado para a finalidade de fazer a função hash na GCM correr tão rápido quanto possível. 00:08:27.432 --> 00:08:32.950 Agora modo contador CCM é um outro padrão NIST ele usa um MAC CBC. E 00:08:32.950 --> 00:08:37.276 então criptografia modo de contador. Portanto, este mecanismo, você sabe, este usa MAC, então 00:08:37.276 --> 00:08:40.906 encrypt, como SSL faz. Portanto, este não é realmente a maneira recomendada de se fazer 00:08:40.906 --> 00:08:44.023 coisas, mas porque a criptografia modo contador é usado. Esta é realmente uma 00:08:44.023 --> 00:08:47.945 mecanismo de criptografia perfeitamente bem. Uma coisa que eu gostaria de ressaltar sobre 00:08:47.945 --> 00:08:53.799 CCM, é que tudo é baseado em AES. Você percebe, ele está usando AES para a CBC 00:08:53.799 --> 00:08:58.778 MAC, e ele está usando a criptografia AES de modo contador. E, como resultado, o CCM pode 00:08:58.778 --> 00:09:03.084 ser implementada com o código de relativamente pouco. Porque tudo que você precisa é um motor AES 00:09:03.084 --> 00:09:08.343 e nada mais. E por isso, CCM, na verdade foi adoptada pelo Wi-Fi 00:09:08.343 --> 00:09:13.963 aliança e, na verdade, provavelmente você está usando CCM em uma base diária, se você estiver usando 00:09:13.963 --> 00:09:19.093 criptografado Wi-Fi 802.11i então você está usando basicamente o tráfego do CCM encrypt 00:09:19.093 --> 00:09:23.450 entre o laptop eo ponto de acesso. Há um outro modo chamado EAX que 00:09:23.450 --> 00:09:28.922 usa criptografia de modo contador, e depois CMAC. Então, novamente você notar encrypt-de-mac 00:09:28.922 --> 00:09:31.906 e isso é um outro modo bem usar. Nós vamos fazer uma comparação de todos estes 00:09:31.906 --> 00:09:36.806 modos em apenas um minuto. Agora eu queria mencionar que, antes de tudo, todos estes são 00:09:36.806 --> 00:09:41.190 nonce-based. Em outras palavras, eles não usam qualquer aleatoriedade, mas eles tomam como 00:09:41.190 --> 00:09:46.360 entrada um nonce e nonce deve ser único por chave. Em outras palavras, como você 00:09:46.360 --> 00:09:50.600 lembre-se, a par nonce chave comum não deve nunca, nunca repetir. Mas o 00:09:50.600 --> 00:09:53.851 nonce si não precisa ser aleatória, por isso é perfeitamente possível usar um contador, para 00:09:53.851 --> 00:09:57.520 exemplo, como um uso único. E o outro ponto importante é que, na verdade, todos 00:09:57.520 --> 00:10:01.384 estes modos são o que se chama de criptografia autenticado com associados 00:10:01.384 --> 00:10:04.936 dados. Esta é uma extensão de criptografia autenticado, mas que vem 00:10:04.936 --> 00:10:10.884 -se muitas vezes em protocolos de rede. Portanto, a ideia entre AEAD é que, na verdade, 00:10:10.884 --> 00:10:15.223 a mensagem que é fornecido para o modo de criptografia não se destina a ser totalmente 00:10:15.223 --> 00:10:19.924 encriptado. Apenas uma parte da mensagem se destina a ser criptografada, mas todo o 00:10:19.924 --> 00:10:24.157 mensagem se destina a ser autenticado. Um bom exemplo disto é um pacote de rede. 00:10:24.157 --> 00:10:29.408 Pense como um pacote IP, onde há um cabeçalho. E depois há uma carga e 00:10:29.408 --> 00:10:33.157 normalmente o cabeçalho não vai ser criptografados. Por exemplo, o cabeçalho pode 00:10:33.157 --> 00:10:36.905 conter o destino do pacote, mas, em seguida, o cabeçalho é melhor que não seja 00:10:36.905 --> 00:10:40.950 criptografados de outra forma os roteadores ao longo do caminho não saberia por onde rotear o pacote. 00:10:40.950 --> 00:10:45.225 E assim, tipicamente o cabeçalho é enviado em claro, que a carga, é claro, é 00:10:45.225 --> 00:10:49.500 sempre criptografados, mas o que você gostaria de fazer é ter o cabeçalho ser autenticado. 00:10:49.500 --> 00:10:55.907 não criptografado, mas autenticado. Portanto, este é exatamente o que estes modos AEAD, fazer. Eles 00:10:55.907 --> 00:11:00.033 irá autenticar o cabeçalho e, em seguida, criptografar a carga. Mas o cabeçalho e 00:11:00.033 --> 00:11:04.177 carga a estão unidos na autenticação para a autenticação não pode 00:11:04.177 --> 00:11:07.803 realmente ser separados. Então isso não é difícil de fazer. O que acontece nestes 00:11:07.803 --> 00:11:14.170 três modos GCM, CCM, EAX e, basicamente, o MAC é aplicado para a totalidade dos dados. Mas 00:11:14.170 --> 00:11:18.852 criptografia é aplicada somente a parte dos dados que precisam ser criptografados. 00:11:18.852 --> 00:11:22.983 Então, eu queria mostrar o que uma API para criptografia autenticado com 00:11:22.983 --> 00:11:28.716 dados associados esquemas de criptografia semelhante. Então aqui está o que parece no OpenSSL 00:11:28.716 --> 00:11:33.609 Por exemplo, isto é, uma API para GCM. Então o que você faz é chamar a 00:11:33.609 --> 00:11:37.404 função de inicialização para inicializar o modo de criptografia, e você percebe que você dê a ele uma chave 00:11:37.404 --> 00:11:40.609 o nonce. O uso único de novo, não tem de ser aleatória, mas tem que 00:11:40.609 --> 00:11:44.402 ser único. E após a inicialização, você poderia chamar essa função encrypt, onde 00:11:44.402 --> 00:11:48.169 você vê que você dê a ele a dados associado que vai ser autenticadas, mas 00:11:48.169 --> 00:11:51.794 não criptografado. Você dá os dados, e vai ser autenticada e 00:11:51.794 --> 00:11:55.752 encriptado. E dá-lhe de volta o texto cifrado completo, que é uma criptografia da 00:11:55.752 --> 00:11:59.582 dados, mas é claro que não inclui o AAD, porque o DAA vai ser enviado em 00:11:59.582 --> 00:12:04.535 claro. Portanto, agora que entendemos esse modo de criptografar-then-MAC, que pode ir 00:12:04.535 --> 00:12:09.951 volta para a definição de MAC segurança e posso explicar-lhe algo que poderia 00:12:09.951 --> 00:12:13.970 ter sido um pouco obscura, quando olhamos para essa definição. Então, se você se lembra, 00:12:13.970 --> 00:12:18.570 um dos requisitos que se seguiram a nossa definição de MACs seguras significava que 00:12:18.570 --> 00:12:25.689 dada uma mensagem par MAC em uma mensagem M, o atacante não pode produzir outra tag na 00:12:25.689 --> 00:12:30.386 a mesma mensagem M. Em outras palavras, mesmo que o invasor já tem uma marca para 00:12:30.386 --> 00:12:34.771 M a mensagem, ele não deve ser capaz de produzir uma marca de novo para a mesma mensagem de M. 00:12:34.771 --> 00:12:39.382 E não é muito claro, por que isso importa? Quem se importa se o adversário já 00:12:39.382 --> 00:12:44.038 tem uma etiqueta na mensagem M? Quem se importa se ele pode produzir outra marca? Bem, acontece 00:12:44.038 --> 00:12:48.828 que o MAC não tem essa propriedade. Em outras palavras, dada uma mensagem 00:12:48.828 --> 00:12:53.618 par MAC, você pode produzir um outro MAC na mesma mensagem, então, que o MAC seria 00:12:53.618 --> 00:12:58.694 resultado em um modo de criptografar-then-MAC inseguro. E por isso, se queremos que o nosso MAC criptografado para 00:12:58.694 --> 00:13:03.961 ter auto-ajuste integridade, é crucial que a nossa Segurança MAC implicaria uma forte 00:13:03.961 --> 00:13:08.910 noção de segurança, o que, evidentemente, não faz porque definido-lo correctamente. 00:13:08.910 --> 00:13:13.613 Então vamos ver o que iria dar errado, se, de fato, era fácil de produzir este tipo de 00:13:13.613 --> 00:13:18.081 falsificação. Então o que vou fazer é que eu vou mostrar-lhe um ataque de texto cifrado escolhido no 00:13:18.081 --> 00:13:22.784 sistema encrypt-then-MAC resultante. E já que o sistema tem um texto cifrado escolhido 00:13:22.784 --> 00:13:27.193 ataque sobre ela, significa necessariamente que ele não fornece uma autenticado 00:13:27.193 --> 00:13:31.458 criptografia. Então vamos ver. Então começo do adversário gonnna enviando dois 00:13:31.458 --> 00:13:35.861 mensagens, M0 e M1. E ele vai receber, como de costume, a criptografia de um 00:13:35.861 --> 00:13:39.522 deles, a criptografia de M0 ou a criptografia de M1. E já que estamos 00:13:39.522 --> 00:13:44.907 usando encrypt-then-MAC, o adversário recebe um texto cifrado, vamos chamar um C0 00:13:44.907 --> 00:13:49.883 e MAC no texto cifrado C0. Bem, agora temos dito que, dada a MAC 00:13:49.883 --> 00:13:53.827 uma mensagem o adversário pode produzir um outro MAC na mesma mensagem. Então, o que 00:13:53.827 --> 00:13:57.994 ele vai fazer é que ele vai produzir um outro MAC na mensagem C0. Agora, ele tem 00:13:57.994 --> 00:14:03.532 um texto cifrado de novo (C0, T '), que é um texto cifrado perfeitamente válido. T 'é um 00:14:03.532 --> 00:14:09.558 MAC válido de C0. Portanto, o adversário agora pode enviar uma consulta de texto da cifra escolhida 00:14:09.558 --> 00:14:14.492 em C 'e esta é uma consulta de texto válido cifra escolhida porque é diferente 00:14:14.492 --> 00:14:19.288 de C. É um texto cifrado de novo. O desafiante pobre agora é obrigado a decifrar este 00:14:19.288 --> 00:14:23.278 texto cifrado C 'para que ele vai mandar de volta a descriptografia de C'. É uma 00:14:23.278 --> 00:14:29.093 texto cifrado válido, portanto, a decodificação de C é o principal Mb mensagem, mas agora o 00:14:29.093 --> 00:14:32.318 atacante acabou de aprender o valor de B, porque ele pode testar se Mb é igual a 00:14:32.318 --> 00:14:37.371 M0 ou MB é igual a M1. Como resultado, ele pode apenas output B e ele fica vantagem 00:14:37.371 --> 00:14:43.468 um. Na alimentação do sistema. E assim, novamente, se a nossa segurança MAC não implicava 00:14:43.468 --> 00:14:48.471 essa propriedade aqui. Em seguida, haverá um ataque de texto escolhido cifra para criptografar-then-MAC. E 00:14:48.471 --> 00:14:53.181 portanto, não seria seguro. Assim, o fato de que nós definir a segurança MAC corretamente 00:14:53.181 --> 00:14:57.241 significa que criptografam-then-MAC realmente fornecer criptografia autenticado. E 00:14:57.241 --> 00:15:01.728 durante todos os MACs que discutimos realmente satisfazer essa noção forte de 00:15:01.728 --> 00:15:06.146 unforgeability. Assim, curiosamente, este não é o fim da história. Então, como dissemos 00:15:06.146 --> 00:15:10.385 antes do conceito de criptografia autenticado foi introduzido todos estavam 00:15:10.385 --> 00:15:15.295 apenas combinando MACs e criptografia de várias maneiras, na esperança de alcançar 00:15:15.295 --> 00:15:19.201 alguns, alguns criptografia autenticado. Após a noção de criptografia autenticado 00:15:19.201 --> 00:15:23.553 tornou-se formalizado e rigorosa, as pessoas começaram a coçar a cabeça e disse: 00:15:23.553 --> 00:15:28.130 ei, espere um minuto. Talvez possamos alcançar a criptografia autenticada de forma mais eficiente 00:15:28.130 --> 00:15:32.722 do que pela combinação de um MAC e um esquema de criptografia. Na verdade, se você pensar em como 00:15:32.722 --> 00:15:37.366 esta combinação de MAC e criptografia funciona, vamos dizer que combinar o modo de contador 00:15:37.366 --> 00:15:42.134 com CMAC, em seguida, para cada bloco de texto simples, você primeiro de tudo tem que usar 00:15:42.134 --> 00:15:46.419 cifra de bloco para o seu modo de contador, e então você tem que usar a sua cifra de bloco 00:15:46.419 --> 00:15:51.357 novamente, para o CBC-MAC. Isto significa que se você combinar CPA criptografia segura com um 00:15:51.357 --> 00:15:55.943 MAC, para cada bloco de texto simples, você tem que avaliar o seu bloco cifrado duas vezes, 00:15:55.943 --> 00:16:00.535 uma vez para o MAC e uma vez para o esquema de criptografia. Então, a pergunta natural 00:16:00.535 --> 00:16:05.396 era, podemos construir um sistema de criptografia autenticado diretamente de um PRP, 00:16:05.396 --> 00:16:10.345 tal que teríamos que apenas avaliar o PRP, uma vez por bloco. E acontece 00:16:10.345 --> 00:16:14.117 , a resposta é sim, e há estes bela construção denominada OCB, que 00:16:14.117 --> 00:16:18.343 praticamente faz tudo que você quer, e é muito mais rápido do que construções que são 00:16:18.343 --> 00:16:22.467 separadamente construído a partir de uma criptografia e MAC. Então eu escrevi para baixo, tipo de um esquema 00:16:22.467 --> 00:16:26.290 da OCB. Eu não quero explicar em detalhes. Vou explicá-lo meio a uma 00:16:26.290 --> 00:16:30.025 de alto nível. Então aqui nós temos, de entrada de texto simples, aqui no topo. E você 00:16:30.025 --> 00:16:34.540 aviso de que, em primeiro lugar, OCB é paralelizável, completamente paralelizável. 00:16:34.540 --> 00:16:39.700 Assim, cada bloco pode ser criptografado separadamente de cada outro bloco. A outra coisa a 00:16:39.700 --> 00:16:44.338 aviso é que, como eu prometi, você só avaliar a sua cifra do bloco uma vez por simples 00:16:44.338 --> 00:16:49.318 bloco de texto. E então você avaliá-lo mais uma vez no fim de construir o seu 00:16:49.318 --> 00:16:53.887 tag autenticação e, em seguida, a sobrecarga de OCB além de apenas um bloco cifra é 00:16:53.887 --> 00:16:58.749 mínima. Tudo que você tem a fazer é avaliar uma determinada função P muito simples que o 00:16:58.749 --> 00:17:02.844 nonce vai para o P você notar, a chave vai para este P e, em seguida, há uma 00:17:02.844 --> 00:17:08.238 contra bloco que vai para este P. Então você só avaliar essa função P, duas vezes 00:17:08.238 --> 00:17:12.748 para cada bloco e você XOR o resultado antes e depois de criptografia usando o 00:17:12.748 --> 00:17:17.553 cifra de bloco e é isso. Isso é tudo que você tem que fazer e então você começa um muito rápido 00:17:17.553 --> 00:17:22.241 esquema de criptografia e de autenticação eficiente construído a partir de uma cifra de bloco. Então OCB 00:17:22.241 --> 00:17:26.065 realmente tem um teorema de segurança agradável associado com ele e eu vou apontar 00:17:26.065 --> 00:17:29.567 para um trabalho sobre OCB quando chegarmos ao final deste módulo onde eu vou listar algumas mais 00:17:29.567 --> 00:17:34.457 papéis de leitura que você pode dar uma olhada. Então você deve estar se perguntando se é tão OCB 00:17:34.457 --> 00:17:40.168 muito melhor do que tudo o que tenho visto até agora todas essas três padrões CCM, GCM e 00:17:40.168 --> 00:17:46.037 EAX porque não é OCB sendo usado ou porque não é OCB o padrão? E a resposta é um 00:17:46.037 --> 00:17:50.729 pouco triste. A resposta primária em que CBC não está sendo utilizado é porque na verdade 00:17:50.729 --> 00:17:54.567 de várias patentes. E eu vou deixar por isso mesmo. Portanto, para concluir esta seção I 00:17:54.567 --> 00:17:58.216 queria mostrar-lhe alguns números de desempenho. Então, aqui à direita listei 00:17:58.216 --> 00:18:02.368 números de desempenho para os modos que você não deve usar. Então isto é para 00:18:02.368 --> 00:18:07.879 modo casualizado contador, e isto é para CBC casualizado. E você pode ver também o 00:18:07.879 --> 00:18:12.460 desempenho de CBC MAC é basicamente o mesmo que o desempenho de criptografia CBC. 00:18:12.460 --> 00:18:16.221 Ok. E aqui são os modos de criptografia autenticados, por isso estes são os 00:18:16.221 --> 00:18:20.083 que você deveria usar, estes que você não deveria estar usando em sua 00:18:20.083 --> 00:18:23.795 próprio, direito. Estes dois, você nunca deve usar esses dois, porque eles só 00:18:23.795 --> 00:18:27.858 fornecer CPA segurança, eles realmente não oferecer segurança contra ativa 00:18:27.858 --> 00:18:31.669 ataques. Você só deve usar criptografia autenticado para criptografia. 00:18:31.669 --> 00:18:35.509 E por isso este é os seus números de desempenho para os três padrões. E deixe-me lembrá 00:18:35.509 --> 00:18:40.109 você que GCM basicamente usa um hash muito rápido. E então ele usa o modo de contador para 00:18:40.109 --> 00:18:43.770 criptografia real. E você pode ver que a sobrecarga de GCM sobre o modo de contador é 00:18:43.770 --> 00:18:49.554 relativamente pequeno. CCM e EAX tanto usar uma criptografia Sipher bloco base e um 00:18:49.554 --> 00:18:54.627 cifra de bloco para a base da MAC. E como resultado a sua duas vezes mais lento que o contador 00:18:54.627 --> 00:18:59.196 modos. Você vê que é realmente mais rápido OCB destes, principalmente porque 00:18:59.196 --> 00:19:03.820 só usar a cifra de bloco uma vez por bloco de mensagem. Assim, com base no desempenho desses 00:19:03.820 --> 00:19:08.328 números, você poderia pensar que GCM é exatamente o modo correto de usar sempre. Mas 00:19:08.328 --> 00:19:12.659 acontece se você está no hardware espaço restrito, GCM não é o ideal. 00:19:12.659 --> 00:19:16.709 Principalmente porque a sua aplicação requer um código maior que os outros dois 00:19:16.709 --> 00:19:21.323 modos. No entanto, como eu disse, a Intel especificamente acrescentou instruções para acelerar 00:19:21.323 --> 00:19:26.064 modo GCM para cima. E, como resultado, a implementação de GCM na arquitetura Intel leva 00:19:26.064 --> 00:19:30.315 muito pouco código. Mas em outras plataformas de hardware, visto em cartões inteligentes ou outros 00:19:30.315 --> 00:19:34.745 ambientes restritos, os sites de código para a implementação GCM seria consideravelmente 00:19:34.745 --> 00:19:39.387 maior do que para os outros dois modos. Mas se o tamanho do código não é uma restrição, então GCM 00:19:39.387 --> 00:19:43.928 é o modo correto de usar. Então, para resumir esse segmento que eu quero dizer mais uma 00:19:43.928 --> 00:19:48.267 tempo que, quando você quiser criptografar mensagens que você tem que usar uma autenticação 00:19:48.267 --> 00:19:52.716 modo de criptografia e a maneira recomendada para fazer isso é usar um dos padrões, 00:19:52.716 --> 00:19:57.037 principalmente um destes três modos para fornecer criptografia de autenticação. Não implementar o esquema de criptografia si mesmo. 00:19:57.037 --> 00:19:59.846 Em outras palavras, não implementar criptografar e-MAC-se. 00:19:59.846 --> 00:20:05.842 Basta usar um desses três padrões. Muitas bibliotecas criptografar 00:20:05.842 --> 00:20:10.513 agora fornecer API padrão para estes três modos e estes são os do que você deve 00:20:10.513 --> 00:20:14.347 estar usando e nada mais. No próximo segmento nós vamos ver o que mais pode 00:20:14.347 --> 00:20:17.500 dar errado quando você tentar implementar uma criptografia sonicado por si mesmo.