[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:03.84,Default,,0000,0000,0000,,Neste segmento, nós vamos construir sistemas de criptografia autenticados. Uma vez que nós
Dialogue: 0,0:00:03.84,0:00:08.25,Default,,0000,0000,0000,,já tem garantido de criptografia CPA, e temos MACs seguras, a pergunta natural
Dialogue: 0,0:00:08.25,0:00:12.82,Default,,0000,0000,0000,,é se podemos combinar os dois de alguma forma, a fim de obter criptografia autenticado.
Dialogue: 0,0:00:12.82,0:00:15.72,Default,,0000,0000,0000,,E se, que é exatamente o que vamos fazer neste segmento. Criptografia autenticado
Dialogue: 0,0:00:15.72,0:00:20.45,Default,,0000,0000,0000,,foi introduzido no ano de 2000, em dois artigos independentes que apontam para a
Dialogue: 0,0:00:20.45,0:00:25.92,Default,,0000,0000,0000,,final deste módulo. Mas antes disso, muitos crytpolibraries desde uma API que
Dialogue: 0,0:00:25.92,0:00:31.22,Default,,0000,0000,0000,,separadamente suporte a criptografia CPA seguro, amd MAC-ing. Então, houve uma
Dialogue: 0,0:00:31.22,0:00:36.18,Default,,0000,0000,0000,,função para implementar criptografia segura CPA. Por exemplo, a CVC com um aleatória
Dialogue: 0,0:00:36.18,0:00:41.14,Default,,0000,0000,0000,,IV. E outra função para a implementação de um MAC. E então todos os desenvolvedores que
Dialogue: 0,0:00:41.14,0:00:45.65,Default,,0000,0000,0000,,queria implementar a criptografia, teve que, ele próprio, chamar separadamente o seguro CPA
Dialogue: 0,0:00:45.65,0:00:50.55,Default,,0000,0000,0000,,esquema de criptografia eo sistema MAC. Em particular, todos os desenvolvedores tiveram que inventar
Dialogue: 0,0:00:50.55,0:00:55.70,Default,,0000,0000,0000,,maneira própria de combinar criptografia e MAC-ing para fornecer algum tipo de
Dialogue: 0,0:00:55.70,0:00:59.38,Default,,0000,0000,0000,,criptografia autenticado. Mas desde que os objetivos da criptografia combinando e MAC-ing
Dialogue: 0,0:00:59.38,0:01:03.69,Default,,0000,0000,0000,,não foi bem compreendida desde criptografia autenticado ainda não foi definida. Ele
Dialogue: 0,0:01:03.69,0:01:08.50,Default,,0000,0000,0000,,realmente não estava claro quais combinações de criptografia e MAC-ing estão corretas e
Dialogue: 0,0:01:08.50,0:01:13.24,Default,,0000,0000,0000,,que não são. E assim, cada projeto, como eu disse tinha de inventar sua própria combinação.
Dialogue: 0,0:01:13.24,0:01:17.20,Default,,0000,0000,0000,,E, de fato, nem todas as combinações eram corretas. E eu posso te dizer que o mais
Dialogue: 0,0:01:17.20,0:01:22.56,Default,,0000,0000,0000,,erro comum em projetos de software foram basicamente incorretamente combinando o
Dialogue: 0,0:01:22.56,0:01:27.02,Default,,0000,0000,0000,,criptografia e mecanismos de integridade. Portanto, esperamos que, até o final deste módulo, você
Dialogue: 0,0:01:27.02,0:01:31.26,Default,,0000,0000,0000,,saberá como combiná-los corretamente, e você não estará fazendo estes erros
Dialogue: 0,0:01:31.26,0:01:35.17,Default,,0000,0000,0000,,si mesmo. Então, vamos olhar para algumas combinações de criptografia segura e CPA
Dialogue: 0,0:01:35.17,0:01:39.30,Default,,0000,0000,0000,,MAC, que foram introduzidas por diferentes projetos. Então, aqui estão três exemplos. Assim,
Dialogue: 0,0:01:39.30,0:01:43.82,Default,,0000,0000,0000,,, antes de tudo, em todos os três exemplos, há uma chave separada para a criptografia, e
Dialogue: 0,0:01:43.82,0:01:47.77,Default,,0000,0000,0000,,uma chave separada para MACing. Estas duas chaves são independentes um do outro, e
Dialogue: 0,0:01:47.77,0:01:52.22,Default,,0000,0000,0000,,ambos são gerados em tempo de configuração da sessão. E nós vamos ver como gerar estes
Dialogue: 0,0:01:52.22,0:01:57.07,Default,,0000,0000,0000,,duas teclas mais tarde no curso. Assim, o primeiro exemplo é o protocolo SSL. Assim, o
Dialogue: 0,0:01:57.07,0:02:02.68,Default,,0000,0000,0000,,maneira SSL combina criptografia e MAC, na esperança de alcançar a criptografia autenticado
Dialogue: 0,0:02:02.68,0:02:07.66,Default,,0000,0000,0000,,é o seguinte. Basicamente, você toma o texto simples, m, e então você calcular um MAC
Dialogue: 0,0:02:07.66,0:02:13.42,Default,,0000,0000,0000,,no texto simples, m. Então você usar sua chave MAC, KI para calcular tag para esta mensagem
Dialogue: 0,0:02:13.42,0:02:17.79,Default,,0000,0000,0000,,m. E então você pode captionate a marca para a mensagem e então você criptografar o
Dialogue: 0,0:02:17.79,0:02:22.58,Default,,0000,0000,0000,,captionation da mensagem ea marca eo que sai é o texto cifrado final.
Dialogue: 0,0:02:22.58,0:02:26.71,Default,,0000,0000,0000,,Então essa é a opção número um. A segunda opção é o que faz seg IP. Assim
Dialogue: 0,0:02:26.71,0:02:31.16,Default,,0000,0000,0000,,aqui, você leva a mensagem. A primeira coisa que você faz é criptografar a mensagem.
Dialogue: 0,0:02:31.16,0:02:35.69,Default,,0000,0000,0000,,E então, você calcular um tag no texto cifrado resultante. Então você percebe o
Dialogue: 0,0:02:35.69,0:02:40.24,Default,,0000,0000,0000,,tag si mesmo é calculado sobre o texto cifrado resultante. Uma terceira opção é o que o
Dialogue: 0,0:02:40.24,0:02:45.43,Default,,0000,0000,0000,,protocolo SSH faz. Então, aqui, o SSH leva a mensagem e criptografa-lo usando um CPA
Dialogue: 0,0:02:45.43,0:02:50.94,Default,,0000,0000,0000,,esquema de criptografia segura. E então, para ele, concatenadas uma marca da mensagem. O
Dialogue: 0,0:02:50.94,0:02:55.57,Default,,0000,0000,0000,,diferença entre IPsec e SSH, é que em IPsec, a marca é calculado sobre o
Dialogue: 0,0:02:55.57,0:02:59.99,Default,,0000,0000,0000,,texto cifrado, que, em SSH, o tag no computadorizada sobre a mensagem. E assim estes
Dialogue: 0,0:02:59.99,0:03:04.54,Default,,0000,0000,0000,,são três maneiras completamente diferentes de combinar a criptografia e MAC. Eo
Dialogue: 0,0:03:04.54,0:03:09.09,Default,,0000,0000,0000,,pergunta é, qual destes é segura. Então, eu vou deixar você pensar sobre isso por um
Dialogue: 0,0:03:09.09,0:03:12.10,Default,,0000,0000,0000,,segundo, e então quando nós vamos continuar a fazer a análise em conjunto. Okay. Então, vamos
Dialogue: 0,0:03:13.20,0:03:17.16,Default,,0000,0000,0000,,início com o método SSH. Assim, o método SSH você notar que a marca é calculado
Dialogue: 0,0:03:17.16,0:03:21.63,Default,,0000,0000,0000,,na mensagem e então concatenado em claro para o texto cifrado. Agora, esta é
Dialogue: 0,0:03:21.63,0:03:26.41,Default,,0000,0000,0000,,realmente um grande problema porque MAC em si não são projetados para fornecer
Dialogue: 0,0:03:26.41,0:03:30.78,Default,,0000,0000,0000,,confidencialidade. Macs são projetados somente para integridade. E, de fato, não há
Dialogue: 0,0:03:30.78,0:03:36.01,Default,,0000,0000,0000,,nada de errado com um MAC que, como parte da marca gera alguns pedaços da planície
Dialogue: 0,0:03:36.01,0:03:41.46,Default,,0000,0000,0000,,texto. Saídas de alguns pedaços da mensagem M. Isso seria uma marca perfeitamente bem. E ainda se
Dialogue: 0,0:03:41.46,0:03:46.67,Default,,0000,0000,0000,,fizemos isso, que seria completamente quebrar a segurança CPA aqui, porque alguns pedaços de
Dialogue: 0,0:03:46.67,0:03:51.82,Default,,0000,0000,0000,,mensagem são divulgados no texto cifrado. E assim, a abordagem SSH, mesmo que o
Dialogue: 0,0:03:51.82,0:03:56.60,Default,,0000,0000,0000,,especificidades da SSH estão bem e do protocolo em si não é comprometida pela
Dialogue: 0,0:03:56.60,0:04:00.82,Default,,0000,0000,0000,,esta combinação específica, geralmente é aconselhável não usar essa abordagem. Simplesmente
Dialogue: 0,0:04:00.82,0:04:05.93,Default,,0000,0000,0000,,porque a saída do algoritmo de assinatura MAC pode vazar bits da mensagem. Assim
Dialogue: 0,0:04:05.93,0:04:11.48,Default,,0000,0000,0000,,agora vamos olhar para SSL e IPsec. Como se vê, o método recomendado, na verdade
Dialogue: 0,0:04:11.48,0:04:16.56,Default,,0000,0000,0000,,é o método de IPsec. Porque acontece que não importa o CPA sistema seguro e MAC
Dialogue: 0,0:04:16.56,0:04:21.13,Default,,0000,0000,0000,,chave que você use a combinação é sempre vai fornecer criptografia autenticado.
Dialogue: 0,0:04:21.13,0:04:26.07,Default,,0000,0000,0000,,Agora deixe-me muito, muito brevemente explicar o porquê. Basicamente o que acontece é que, uma vez que criptografar
Dialogue: 0,0:04:26.07,0:04:31.00,Default,,0000,0000,0000,,mensagem bem o conteúdo da mensagem agora está escondido no interior do texto cifrado e agora
Dialogue: 0,0:04:31.00,0:04:35.76,Default,,0000,0000,0000,,quando calculamos uma marca do texto cifrado, basicamente, estamos travando, esta tag bloqueios
Dialogue: 0,0:04:35.76,0:04:40.82,Default,,0000,0000,0000,,texto a cifra e garante que ninguém pode produzir um texto cifrado diferente que
Dialogue: 0,0:04:40.82,0:04:45.31,Default,,0000,0000,0000,,olhar válido. E como resultado desta abordagem garante que quaisquer modificações na
Dialogue: 0,0:04:45.31,0:04:49.56,Default,,0000,0000,0000,,texto cifrado será detectado pelo decrypter simplesmente porque o MAC não é
Dialogue: 0,0:04:49.56,0:04:54.03,Default,,0000,0000,0000,,vai verificar. Como se vê, para a abordagem SSL, há na verdade são uma espécie de
Dialogue: 0,0:04:54.03,0:04:59.35,Default,,0000,0000,0000,,exemplos patológicos, onde combinam CPA sistema de criptografia seguro com um seguro
Dialogue: 0,0:04:59.35,0:05:03.54,Default,,0000,0000,0000,,MAC. E o resultado é vulnerável a um ataque escolhido cifra texto, de modo que ele faz
Dialogue: 0,0:05:03.54,0:05:07.98,Default,,0000,0000,0000,,na verdade não fornece criptografia autenticado. E, basicamente, a razão que
Dialogue: 0,0:05:07.98,0:05:12.82,Default,,0000,0000,0000,,poderia acontecer, é que há algum tipo de interação ruim entre a criptografia
Dialogue: 0,0:05:12.82,0:05:17.32,Default,,0000,0000,0000,,esquema eo algoritmo MAC. De tal modo que, de fato, haverá uma cifra escolhida
Dialogue: 0,0:05:17.32,0:05:21.75,Default,,0000,0000,0000,,ataque texto. Então, se você está projetando um novo projeto a recomendação agora é
Dialogue: 0,0:05:21.75,0:05:26.16,Default,,0000,0000,0000,,sempre usar criptografar então MAC porque isso é seguro, não importa qual CPA seguro
Dialogue: 0,0:05:26.16,0:05:30.61,Default,,0000,0000,0000,,algoritmo de criptografia e MAC seguro você está combinando. Agora, só para definir o
Dialogue: 0,0:05:30.61,0:05:37.100,Default,,0000,0000,0000,,terminologia, o método SSL é às vezes chamado MAC-then-encrypt. Eo
Dialogue: 0,0:05:37.100,0:05:45.04,Default,,0000,0000,0000,,método IPsec é chamado encrypt-then-MAC. O método SSH mesmo que seu
Dialogue: 0,0:05:45.04,0:05:51.90,Default,,0000,0000,0000,,não deveria usá-lo, é chamado de criptografar e-MAC. Ok, então eu vou muitas vezes referem-se a
Dialogue: 0,0:05:51.90,0:05:57.00,Default,,0000,0000,0000,,encrypt-then-MAC e MAC-then-criptografar para diferenciar SSL e IPsec. Ok, então
Dialogue: 0,0:05:57.00,0:06:02.11,Default,,0000,0000,0000,,apenas para repetir o que acabei de dizer. O método de IPsec encrypt-e-mac sempre
Dialogue: 0,0:06:02.11,0:06:07.16,Default,,0000,0000,0000,,nos fornecer uma criptografia autenticado. Se você começar do CPA cifra segura e um MAC seguro
Dialogue: 0,0:06:07.16,0:06:11.11,Default,,0000,0000,0000,,Você sempre terá criptografia autenticado. Como eu disse, MAC-depois-criptografar em
Dialogue: 0,0:06:11.11,0:06:15.74,Default,,0000,0000,0000,,fato, há casos patológicos, onde o resultado é vulnerável a fatos CCA e
Dialogue: 0,0:06:15.74,0:06:20.31,Default,,0000,0000,0000,,, portanto, não fornece criptografia autenticado. No entanto, a história é um pouco
Dialogue: 0,0:06:20.31,0:06:24.65,Default,,0000,0000,0000,,pouco mais interessante do que isso, na medida em que, ao que parece, se você está realmente usando
Dialogue: 0,0:06:24.65,0:06:29.22,Default,,0000,0000,0000,,modo aleatório contador ou CBC randomizado, em seguida, ao que parece, para aqueles que especial
Dialogue: 0,0:06:29.22,0:06:33.62,Default,,0000,0000,0000,,CPA esquemas de criptografia seguras, MAC-then-criptografar realmente dá autenticado
Dialogue: 0,0:06:33.62,0:06:38.03,Default,,0000,0000,0000,,criptografia e por isso é seguro. De fato, há mesmo uma mais interessante
Dialogue: 0,0:06:38.03,0:06:42.33,Default,,0000,0000,0000,,torcer aqui em que se você estiver usando o modo de contador ao acaso. Então, é suficiente
Dialogue: 0,0:06:42.33,0:06:46.80,Default,,0000,0000,0000,,que o seu algoritmo de MAC apenas ser um tempo seguro. Ele não tem que ser um totalmente
Dialogue: 0,0:06:46.80,0:06:51.56,Default,,0000,0000,0000,,MAC seguro. Ele só tem que ser seguro quando uma tecla é usada para criptografar uma mensagem única,
Dialogue: 0,0:06:51.56,0:06:56.09,Default,,0000,0000,0000,,ok? E quando falamos sobre a integridade da mensagem, vimos que há realmente
Dialogue: 0,0:06:56.09,0:07:00.58,Default,,0000,0000,0000,,6:56.08\NMACs muito mais rápido que são um tempo seguro de MACs que são totalmente seguras. Como
Dialogue: 0,0:07:00.58,0:07:04.45,Default,,0000,0000,0000,,resultado, se você estiver usando o modo aleatório contra-MAC, em seguida, criptografar-pudesse realmente
Dialogue: 0,0:07:04.45,0:07:08.19,Default,,0000,0000,0000,,resultado em um mecanismo de criptografia mais eficiente. No entanto, eu vou repetir
Dialogue: 0,0:07:08.19,0:07:12.21,Default,,0000,0000,0000,,isso de novo. A recomendação é usar encrypt-then-MAC e estamos indo para ver um
Dialogue: 0,0:07:12.21,0:07:16.09,Default,,0000,0000,0000,,número de ataques a sistemas que não usam encrypt-then-MAC. E assim o fazem apenas
Dialogue: 0,0:07:16.09,0:07:20.12,Default,,0000,0000,0000,,que as coisas são seguras sem você ter que pensar muito sobre isso. Novamente, eu sou
Dialogue: 0,0:07:20.12,0:07:24.12,Default,,0000,0000,0000,,vai recomendar que você use sempre encrypt-then-MAC. Agora, uma vez que o conceito de
Dialogue: 0,0:07:24.12,0:07:27.76,Default,,0000,0000,0000,,criptografia autenticada tornou-se mais popular, um número de padronizada
Dialogue: 0,0:07:27.76,0:07:31.61,Default,,0000,0000,0000,,abordagens para a combinação de criptografia e MAC apareceu. E eram mesmo
Dialogue: 0,0:07:31.61,0:07:35.98,Default,,0000,0000,0000,,padronizado pelo Instituto Nacional de Padrões. Então eu só vou mencionar três
Dialogue: 0,0:07:35.98,0:07:41.03,Default,,0000,0000,0000,,destas normas. Dois deles foram padronizados pelo NIST. E estes são
Dialogue: 0,0:07:41.03,0:07:46.14,Default,,0000,0000,0000,,chamado Galois modo de contador e contador de modo CBC. E então deixe-me explicar o que fazem.
Dialogue: 0,0:07:46.14,0:07:51.24,Default,,0000,0000,0000,,modo Galois contador basicamente usa criptografia de modo contador, para um contador randomizado
Dialogue: 0,0:07:51.24,0:07:56.16,Default,,0000,0000,0000,,modo com um MAC Carter-Wegman, portanto, um fato muito Carter-Wagmon MAC. E a forma como o
Dialogue: 0,0:07:56.16,0:08:01.15,Default,,0000,0000,0000,,Carter-Wegman MAC trabalha em GCM é que é basicamente uma função hash da mensagem
Dialogue: 0,0:08:01.15,0:08:06.31,Default,,0000,0000,0000,,que está sendo MACed. E então o resultado é criptografada usando um PRF. Agora esse hash
Dialogue: 0,0:08:06.31,0:08:11.56,Default,,0000,0000,0000,,função em MGC é já bastante rápido até o ponto onde a maior parte do executando
Dialogue: 0,0:08:11.56,0:08:15.84,Default,,0000,0000,0000,,hora do GCM é dominada pelo modo de contador de criptografia e está ainda fez mais,
Dialogue: 0,0:08:15.84,0:08:22.37,Default,,0000,0000,0000,,em que a Intel introduz um PCLMULQDQ instrução especial especificamente
Dialogue: 0,0:08:22.37,0:08:27.43,Default,,0000,0000,0000,,projetado para a finalidade de fazer a função hash na GCM correr tão rápido quanto possível.
Dialogue: 0,0:08:27.43,0:08:32.95,Default,,0000,0000,0000,,Agora modo contador CCM é um outro padrão NIST ele usa um MAC CBC. E
Dialogue: 0,0:08:32.95,0:08:37.28,Default,,0000,0000,0000,,então criptografia modo de contador. Portanto, este mecanismo, você sabe, este usa MAC, então
Dialogue: 0,0:08:37.28,0:08:40.91,Default,,0000,0000,0000,,encrypt, como SSL faz. Portanto, este não é realmente a maneira recomendada de se fazer
Dialogue: 0,0:08:40.91,0:08:44.02,Default,,0000,0000,0000,,coisas, mas porque a criptografia modo contador é usado. Esta é realmente uma
Dialogue: 0,0:08:44.02,0:08:47.94,Default,,0000,0000,0000,,mecanismo de criptografia perfeitamente bem. Uma coisa que eu gostaria de ressaltar sobre
Dialogue: 0,0:08:47.94,0:08:53.80,Default,,0000,0000,0000,,CCM, é que tudo é baseado em AES. Você percebe, ele está usando AES para a CBC
Dialogue: 0,0:08:53.80,0:08:58.78,Default,,0000,0000,0000,,MAC, e ele está usando a criptografia AES de modo contador. E, como resultado, o CCM pode
Dialogue: 0,0:08:58.78,0:09:03.08,Default,,0000,0000,0000,,ser implementada com o código de relativamente pouco. Porque tudo que você precisa é um motor AES
Dialogue: 0,0:09:03.08,0:09:08.34,Default,,0000,0000,0000,,e nada mais. E por isso, CCM, na verdade foi adoptada pelo Wi-Fi
Dialogue: 0,0:09:08.34,0:09:13.96,Default,,0000,0000,0000,,aliança e, na verdade, provavelmente você está usando CCM em uma base diária, se você estiver usando
Dialogue: 0,0:09:13.96,0:09:19.09,Default,,0000,0000,0000,,criptografado Wi-Fi 802.11i então você está usando basicamente o tráfego do CCM encrypt
Dialogue: 0,0:09:19.09,0:09:23.45,Default,,0000,0000,0000,,entre o laptop eo ponto de acesso. Há um outro modo chamado EAX que
Dialogue: 0,0:09:23.45,0:09:28.92,Default,,0000,0000,0000,,usa criptografia de modo contador, e depois CMAC. Então, novamente você notar encrypt-de-mac
Dialogue: 0,0:09:28.92,0:09:31.91,Default,,0000,0000,0000,,e isso é um outro modo bem usar. Nós vamos fazer uma comparação de todos estes
Dialogue: 0,0:09:31.91,0:09:36.81,Default,,0000,0000,0000,,modos em apenas um minuto. Agora eu queria mencionar que, antes de tudo, todos estes são
Dialogue: 0,0:09:36.81,0:09:41.19,Default,,0000,0000,0000,,nonce-based. Em outras palavras, eles não usam qualquer aleatoriedade, mas eles tomam como
Dialogue: 0,0:09:41.19,0:09:46.36,Default,,0000,0000,0000,,entrada um nonce e nonce deve ser único por chave. Em outras palavras, como você
Dialogue: 0,0:09:46.36,0:09:50.60,Default,,0000,0000,0000,,lembre-se, a par nonce chave comum não deve nunca, nunca repetir. Mas o
Dialogue: 0,0:09:50.60,0:09:53.85,Default,,0000,0000,0000,,nonce si não precisa ser aleatória, por isso é perfeitamente possível usar um contador, para
Dialogue: 0,0:09:53.85,0:09:57.52,Default,,0000,0000,0000,,exemplo, como um uso único. E o outro ponto importante é que, na verdade, todos
Dialogue: 0,0:09:57.52,0:10:01.38,Default,,0000,0000,0000,,estes modos são o que se chama de criptografia autenticado com associados
Dialogue: 0,0:10:01.38,0:10:04.94,Default,,0000,0000,0000,,dados. Esta é uma extensão de criptografia autenticado, mas que vem
Dialogue: 0,0:10:04.94,0:10:10.88,Default,,0000,0000,0000,,-se muitas vezes em protocolos de rede. Portanto, a ideia entre AEAD é que, na verdade,
Dialogue: 0,0:10:10.88,0:10:15.22,Default,,0000,0000,0000,,a mensagem que é fornecido para o modo de criptografia não se destina a ser totalmente
Dialogue: 0,0:10:15.22,0:10:19.92,Default,,0000,0000,0000,,encriptado. Apenas uma parte da mensagem se destina a ser criptografada, mas todo o
Dialogue: 0,0:10:19.92,0:10:24.16,Default,,0000,0000,0000,,mensagem se destina a ser autenticado. Um bom exemplo disto é um pacote de rede.
Dialogue: 0,0:10:24.16,0:10:29.41,Default,,0000,0000,0000,,Pense como um pacote IP, onde há um cabeçalho. E depois há uma carga e
Dialogue: 0,0:10:29.41,0:10:33.16,Default,,0000,0000,0000,,normalmente o cabeçalho não vai ser criptografados. Por exemplo, o cabeçalho pode
Dialogue: 0,0:10:33.16,0:10:36.90,Default,,0000,0000,0000,,conter o destino do pacote, mas, em seguida, o cabeçalho é melhor que não seja
Dialogue: 0,0:10:36.90,0:10:40.95,Default,,0000,0000,0000,,criptografados de outra forma os roteadores ao longo do caminho não saberia por onde rotear o pacote.
Dialogue: 0,0:10:40.95,0:10:45.22,Default,,0000,0000,0000,,E assim, tipicamente o cabeçalho é enviado em claro, que a carga, é claro, é
Dialogue: 0,0:10:45.22,0:10:49.50,Default,,0000,0000,0000,,sempre criptografados, mas o que você gostaria de fazer é ter o cabeçalho ser autenticado.
Dialogue: 0,0:10:49.50,0:10:55.91,Default,,0000,0000,0000,,não criptografado, mas autenticado. Portanto, este é exatamente o que estes modos AEAD, fazer. Eles
Dialogue: 0,0:10:55.91,0:11:00.03,Default,,0000,0000,0000,,irá autenticar o cabeçalho e, em seguida, criptografar a carga. Mas o cabeçalho e
Dialogue: 0,0:11:00.03,0:11:04.18,Default,,0000,0000,0000,,carga a estão unidos na autenticação para a autenticação não pode
Dialogue: 0,0:11:04.18,0:11:07.80,Default,,0000,0000,0000,,realmente ser separados. Então isso não é difícil de fazer. O que acontece nestes
Dialogue: 0,0:11:07.80,0:11:14.17,Default,,0000,0000,0000,,três modos GCM, CCM, EAX e, basicamente, o MAC é aplicado para a totalidade dos dados. Mas
Dialogue: 0,0:11:14.17,0:11:18.85,Default,,0000,0000,0000,,criptografia é aplicada somente a parte dos dados que precisam ser criptografados.
Dialogue: 0,0:11:18.85,0:11:22.98,Default,,0000,0000,0000,,Então, eu queria mostrar o que uma API para criptografia autenticado com
Dialogue: 0,0:11:22.98,0:11:28.72,Default,,0000,0000,0000,,dados associados esquemas de criptografia semelhante. Então aqui está o que parece no OpenSSL
Dialogue: 0,0:11:28.72,0:11:33.61,Default,,0000,0000,0000,,Por exemplo, isto é, uma API para GCM. Então o que você faz é chamar a
Dialogue: 0,0:11:33.61,0:11:37.40,Default,,0000,0000,0000,,função de inicialização para inicializar o modo de criptografia, e você percebe que você dê a ele uma chave
Dialogue: 0,0:11:37.40,0:11:40.61,Default,,0000,0000,0000,,o nonce. O uso único de novo, não tem de ser aleatória, mas tem que
Dialogue: 0,0:11:40.61,0:11:44.40,Default,,0000,0000,0000,,ser único. E após a inicialização, você poderia chamar essa função encrypt, onde
Dialogue: 0,0:11:44.40,0:11:48.17,Default,,0000,0000,0000,,você vê que você dê a ele a dados associado que vai ser autenticadas, mas
Dialogue: 0,0:11:48.17,0:11:51.79,Default,,0000,0000,0000,,não criptografado. Você dá os dados, e vai ser autenticada e
Dialogue: 0,0:11:51.79,0:11:55.75,Default,,0000,0000,0000,,encriptado. E dá-lhe de volta o texto cifrado completo, que é uma criptografia da
Dialogue: 0,0:11:55.75,0:11:59.58,Default,,0000,0000,0000,,dados, mas é claro que não inclui o AAD, porque o DAA vai ser enviado em
Dialogue: 0,0:11:59.58,0:12:04.54,Default,,0000,0000,0000,,claro. Portanto, agora que entendemos esse modo de criptografar-then-MAC, que pode ir
Dialogue: 0,0:12:04.54,0:12:09.95,Default,,0000,0000,0000,,volta para a definição de MAC segurança e posso explicar-lhe algo que poderia
Dialogue: 0,0:12:09.95,0:12:13.97,Default,,0000,0000,0000,,ter sido um pouco obscura, quando olhamos para essa definição. Então, se você se lembra,
Dialogue: 0,0:12:13.97,0:12:18.57,Default,,0000,0000,0000,,um dos requisitos que se seguiram a nossa definição de MACs seguras significava que
Dialogue: 0,0:12:18.57,0:12:25.69,Default,,0000,0000,0000,,dada uma mensagem par MAC em uma mensagem M, o atacante não pode produzir outra tag na
Dialogue: 0,0:12:25.69,0:12:30.39,Default,,0000,0000,0000,,a mesma mensagem M. Em outras palavras, mesmo que o invasor já tem uma marca para
Dialogue: 0,0:12:30.39,0:12:34.77,Default,,0000,0000,0000,,M a mensagem, ele não deve ser capaz de produzir uma marca de novo para a mesma mensagem de M.
Dialogue: 0,0:12:34.77,0:12:39.38,Default,,0000,0000,0000,,E não é muito claro, por que isso importa? Quem se importa se o adversário já
Dialogue: 0,0:12:39.38,0:12:44.04,Default,,0000,0000,0000,,tem uma etiqueta na mensagem M? Quem se importa se ele pode produzir outra marca? Bem, acontece
Dialogue: 0,0:12:44.04,0:12:48.83,Default,,0000,0000,0000,,que o MAC não tem essa propriedade. Em outras palavras, dada uma mensagem
Dialogue: 0,0:12:48.83,0:12:53.62,Default,,0000,0000,0000,,par MAC, você pode produzir um outro MAC na mesma mensagem, então, que o MAC seria
Dialogue: 0,0:12:53.62,0:12:58.69,Default,,0000,0000,0000,,resultado em um modo de criptografar-then-MAC inseguro. E por isso, se queremos que o nosso MAC criptografado para
Dialogue: 0,0:12:58.69,0:13:03.96,Default,,0000,0000,0000,,ter auto-ajuste integridade, é crucial que a nossa Segurança MAC implicaria uma forte
Dialogue: 0,0:13:03.96,0:13:08.91,Default,,0000,0000,0000,,noção de segurança, o que, evidentemente, não faz porque definido-lo correctamente.
Dialogue: 0,0:13:08.91,0:13:13.61,Default,,0000,0000,0000,,Então vamos ver o que iria dar errado, se, de fato, era fácil de produzir este tipo de
Dialogue: 0,0:13:13.61,0:13:18.08,Default,,0000,0000,0000,,falsificação. Então o que vou fazer é que eu vou mostrar-lhe um ataque de texto cifrado escolhido no
Dialogue: 0,0:13:18.08,0:13:22.78,Default,,0000,0000,0000,,sistema encrypt-then-MAC resultante. E já que o sistema tem um texto cifrado escolhido
Dialogue: 0,0:13:22.78,0:13:27.19,Default,,0000,0000,0000,,ataque sobre ela, significa necessariamente que ele não fornece uma autenticado
Dialogue: 0,0:13:27.19,0:13:31.46,Default,,0000,0000,0000,,criptografia. Então vamos ver. Então começo do adversário gonnna enviando dois
Dialogue: 0,0:13:31.46,0:13:35.86,Default,,0000,0000,0000,,mensagens, M0 e M1. E ele vai receber, como de costume, a criptografia de um
Dialogue: 0,0:13:35.86,0:13:39.52,Default,,0000,0000,0000,,deles, a criptografia de M0 ou a criptografia de M1. E já que estamos
Dialogue: 0,0:13:39.52,0:13:44.91,Default,,0000,0000,0000,,usando encrypt-then-MAC, o adversário recebe um texto cifrado, vamos chamar um C0
Dialogue: 0,0:13:44.91,0:13:49.88,Default,,0000,0000,0000,,e MAC no texto cifrado C0. Bem, agora temos dito que, dada a MAC
Dialogue: 0,0:13:49.88,0:13:53.83,Default,,0000,0000,0000,,uma mensagem o adversário pode produzir um outro MAC na mesma mensagem. Então, o que
Dialogue: 0,0:13:53.83,0:13:57.99,Default,,0000,0000,0000,,ele vai fazer é que ele vai produzir um outro MAC na mensagem C0. Agora, ele tem
Dialogue: 0,0:13:57.99,0:14:03.53,Default,,0000,0000,0000,,um texto cifrado de novo (C0, T '), que é um texto cifrado perfeitamente válido. T 'é um
Dialogue: 0,0:14:03.53,0:14:09.56,Default,,0000,0000,0000,,MAC válido de C0. Portanto, o adversário agora pode enviar uma consulta de texto da cifra escolhida
Dialogue: 0,0:14:09.56,0:14:14.49,Default,,0000,0000,0000,,em C 'e esta é uma consulta de texto válido cifra escolhida porque é diferente
Dialogue: 0,0:14:14.49,0:14:19.29,Default,,0000,0000,0000,,de C. É um texto cifrado de novo. O desafiante pobre agora é obrigado a decifrar este
Dialogue: 0,0:14:19.29,0:14:23.28,Default,,0000,0000,0000,,texto cifrado C 'para que ele vai mandar de volta a descriptografia de C'. É uma
Dialogue: 0,0:14:23.28,0:14:29.09,Default,,0000,0000,0000,,texto cifrado válido, portanto, a decodificação de C é o principal Mb mensagem, mas agora o
Dialogue: 0,0:14:29.09,0:14:32.32,Default,,0000,0000,0000,,atacante acabou de aprender o valor de B, porque ele pode testar se Mb é igual a
Dialogue: 0,0:14:32.32,0:14:37.37,Default,,0000,0000,0000,,M0 ou MB é igual a M1. Como resultado, ele pode apenas output B e ele fica vantagem
Dialogue: 0,0:14:37.37,0:14:43.47,Default,,0000,0000,0000,,um. Na alimentação do sistema. E assim, novamente, se a nossa segurança MAC não implicava
Dialogue: 0,0:14:43.47,0:14:48.47,Default,,0000,0000,0000,,essa propriedade aqui. Em seguida, haverá um ataque de texto escolhido cifra para criptografar-then-MAC. E
Dialogue: 0,0:14:48.47,0:14:53.18,Default,,0000,0000,0000,,portanto, não seria seguro. Assim, o fato de que nós definir a segurança MAC corretamente
Dialogue: 0,0:14:53.18,0:14:57.24,Default,,0000,0000,0000,,significa que criptografam-then-MAC realmente fornecer criptografia autenticado. E
Dialogue: 0,0:14:57.24,0:15:01.73,Default,,0000,0000,0000,,durante todos os MACs que discutimos realmente satisfazer essa noção forte de
Dialogue: 0,0:15:01.73,0:15:06.15,Default,,0000,0000,0000,,unforgeability. Assim, curiosamente, este não é o fim da história. Então, como dissemos
Dialogue: 0,0:15:06.15,0:15:10.38,Default,,0000,0000,0000,,antes do conceito de criptografia autenticado foi introduzido todos estavam
Dialogue: 0,0:15:10.38,0:15:15.30,Default,,0000,0000,0000,,apenas combinando MACs e criptografia de várias maneiras, na esperança de alcançar
Dialogue: 0,0:15:15.30,0:15:19.20,Default,,0000,0000,0000,,alguns, alguns criptografia autenticado. Após a noção de criptografia autenticado
Dialogue: 0,0:15:19.20,0:15:23.55,Default,,0000,0000,0000,,tornou-se formalizado e rigorosa, as pessoas começaram a coçar a cabeça e disse:
Dialogue: 0,0:15:23.55,0:15:28.13,Default,,0000,0000,0000,,ei, espere um minuto. Talvez possamos alcançar a criptografia autenticada de forma mais eficiente
Dialogue: 0,0:15:28.13,0:15:32.72,Default,,0000,0000,0000,,do que pela combinação de um MAC e um esquema de criptografia. Na verdade, se você pensar em como
Dialogue: 0,0:15:32.72,0:15:37.37,Default,,0000,0000,0000,,esta combinação de MAC e criptografia funciona, vamos dizer que combinar o modo de contador
Dialogue: 0,0:15:37.37,0:15:42.13,Default,,0000,0000,0000,,com CMAC, em seguida, para cada bloco de texto simples, você primeiro de tudo tem que usar
Dialogue: 0,0:15:42.13,0:15:46.42,Default,,0000,0000,0000,,cifra de bloco para o seu modo de contador, e então você tem que usar a sua cifra de bloco
Dialogue: 0,0:15:46.42,0:15:51.36,Default,,0000,0000,0000,,novamente, para o CBC-MAC. Isto significa que se você combinar CPA criptografia segura com um
Dialogue: 0,0:15:51.36,0:15:55.94,Default,,0000,0000,0000,,MAC, para cada bloco de texto simples, você tem que avaliar o seu bloco cifrado duas vezes,
Dialogue: 0,0:15:55.94,0:16:00.54,Default,,0000,0000,0000,,uma vez para o MAC e uma vez para o esquema de criptografia. Então, a pergunta natural
Dialogue: 0,0:16:00.54,0:16:05.40,Default,,0000,0000,0000,,era, podemos construir um sistema de criptografia autenticado diretamente de um PRP,
Dialogue: 0,0:16:05.40,0:16:10.34,Default,,0000,0000,0000,,tal que teríamos que apenas avaliar o PRP, uma vez por bloco. E acontece
Dialogue: 0,0:16:10.34,0:16:14.12,Default,,0000,0000,0000,,, a resposta é sim, e há estes bela construção denominada OCB, que
Dialogue: 0,0:16:14.12,0:16:18.34,Default,,0000,0000,0000,,praticamente faz tudo que você quer, e é muito mais rápido do que construções que são
Dialogue: 0,0:16:18.34,0:16:22.47,Default,,0000,0000,0000,,separadamente construído a partir de uma criptografia e MAC. Então eu escrevi para baixo, tipo de um esquema
Dialogue: 0,0:16:22.47,0:16:26.29,Default,,0000,0000,0000,,da OCB. Eu não quero explicar em detalhes. Vou explicá-lo meio a uma
Dialogue: 0,0:16:26.29,0:16:30.02,Default,,0000,0000,0000,,de alto nível. Então aqui nós temos, de entrada de texto simples, aqui no topo. E você
Dialogue: 0,0:16:30.02,0:16:34.54,Default,,0000,0000,0000,,aviso de que, em primeiro lugar, OCB é paralelizável, completamente paralelizável.
Dialogue: 0,0:16:34.54,0:16:39.70,Default,,0000,0000,0000,,Assim, cada bloco pode ser criptografado separadamente de cada outro bloco. A outra coisa a
Dialogue: 0,0:16:39.70,0:16:44.34,Default,,0000,0000,0000,,aviso é que, como eu prometi, você só avaliar a sua cifra do bloco uma vez por simples
Dialogue: 0,0:16:44.34,0:16:49.32,Default,,0000,0000,0000,,bloco de texto. E então você avaliá-lo mais uma vez no fim de construir o seu
Dialogue: 0,0:16:49.32,0:16:53.89,Default,,0000,0000,0000,,tag autenticação e, em seguida, a sobrecarga de OCB além de apenas um bloco cifra é
Dialogue: 0,0:16:53.89,0:16:58.75,Default,,0000,0000,0000,,mínima. Tudo que você tem a fazer é avaliar uma determinada função P muito simples que o
Dialogue: 0,0:16:58.75,0:17:02.84,Default,,0000,0000,0000,,nonce vai para o P você notar, a chave vai para este P e, em seguida, há uma
Dialogue: 0,0:17:02.84,0:17:08.24,Default,,0000,0000,0000,,contra bloco que vai para este P. Então você só avaliar essa função P, duas vezes
Dialogue: 0,0:17:08.24,0:17:12.75,Default,,0000,0000,0000,,para cada bloco e você XOR o resultado antes e depois de criptografia usando o
Dialogue: 0,0:17:12.75,0:17:17.55,Default,,0000,0000,0000,,cifra de bloco e é isso. Isso é tudo que você tem que fazer e então você começa um muito rápido
Dialogue: 0,0:17:17.55,0:17:22.24,Default,,0000,0000,0000,,esquema de criptografia e de autenticação eficiente construído a partir de uma cifra de bloco. Então OCB
Dialogue: 0,0:17:22.24,0:17:26.06,Default,,0000,0000,0000,,realmente tem um teorema de segurança agradável associado com ele e eu vou apontar
Dialogue: 0,0:17:26.06,0:17:29.57,Default,,0000,0000,0000,,para um trabalho sobre OCB quando chegarmos ao final deste módulo onde eu vou listar algumas mais
Dialogue: 0,0:17:29.57,0:17:34.46,Default,,0000,0000,0000,,papéis de leitura que você pode dar uma olhada. Então você deve estar se perguntando se é tão OCB
Dialogue: 0,0:17:34.46,0:17:40.17,Default,,0000,0000,0000,,muito melhor do que tudo o que tenho visto até agora todas essas três padrões CCM, GCM e
Dialogue: 0,0:17:40.17,0:17:46.04,Default,,0000,0000,0000,,EAX porque não é OCB sendo usado ou porque não é OCB o padrão? E a resposta é um
Dialogue: 0,0:17:46.04,0:17:50.73,Default,,0000,0000,0000,,pouco triste. A resposta primária em que CBC não está sendo utilizado é porque na verdade
Dialogue: 0,0:17:50.73,0:17:54.57,Default,,0000,0000,0000,,de várias patentes. E eu vou deixar por isso mesmo. Portanto, para concluir esta seção I
Dialogue: 0,0:17:54.57,0:17:58.22,Default,,0000,0000,0000,,queria mostrar-lhe alguns números de desempenho. Então, aqui à direita listei
Dialogue: 0,0:17:58.22,0:18:02.37,Default,,0000,0000,0000,,números de desempenho para os modos que você não deve usar. Então isto é para
Dialogue: 0,0:18:02.37,0:18:07.88,Default,,0000,0000,0000,,modo casualizado contador, e isto é para CBC casualizado. E você pode ver também o
Dialogue: 0,0:18:07.88,0:18:12.46,Default,,0000,0000,0000,,desempenho de CBC MAC é basicamente o mesmo que o desempenho de criptografia CBC.
Dialogue: 0,0:18:12.46,0:18:16.22,Default,,0000,0000,0000,,Ok. E aqui são os modos de criptografia autenticados, por isso estes são os
Dialogue: 0,0:18:16.22,0:18:20.08,Default,,0000,0000,0000,,que você deveria usar, estes que você não deveria estar usando em sua
Dialogue: 0,0:18:20.08,0:18:23.80,Default,,0000,0000,0000,,próprio, direito. Estes dois, você nunca deve usar esses dois, porque eles só
Dialogue: 0,0:18:23.80,0:18:27.86,Default,,0000,0000,0000,,fornecer CPA segurança, eles realmente não oferecer segurança contra ativa
Dialogue: 0,0:18:27.86,0:18:31.67,Default,,0000,0000,0000,,ataques. Você só deve usar criptografia autenticado para criptografia.
Dialogue: 0,0:18:31.67,0:18:35.51,Default,,0000,0000,0000,,E por isso este é os seus números de desempenho para os três padrões. E deixe-me lembrá
Dialogue: 0,0:18:35.51,0:18:40.11,Default,,0000,0000,0000,,você que GCM basicamente usa um hash muito rápido. E então ele usa o modo de contador para
Dialogue: 0,0:18:40.11,0:18:43.77,Default,,0000,0000,0000,,criptografia real. E você pode ver que a sobrecarga de GCM sobre o modo de contador é
Dialogue: 0,0:18:43.77,0:18:49.55,Default,,0000,0000,0000,,relativamente pequeno. CCM e EAX tanto usar uma criptografia Sipher bloco base e um
Dialogue: 0,0:18:49.55,0:18:54.63,Default,,0000,0000,0000,,cifra de bloco para a base da MAC. E como resultado a sua duas vezes mais lento que o contador
Dialogue: 0,0:18:54.63,0:18:59.20,Default,,0000,0000,0000,,modos. Você vê que é realmente mais rápido OCB destes, principalmente porque
Dialogue: 0,0:18:59.20,0:19:03.82,Default,,0000,0000,0000,,só usar a cifra de bloco uma vez por bloco de mensagem. Assim, com base no desempenho desses
Dialogue: 0,0:19:03.82,0:19:08.33,Default,,0000,0000,0000,,números, você poderia pensar que GCM é exatamente o modo correto de usar sempre. Mas
Dialogue: 0,0:19:08.33,0:19:12.66,Default,,0000,0000,0000,,acontece se você está no hardware espaço restrito, GCM não é o ideal.
Dialogue: 0,0:19:12.66,0:19:16.71,Default,,0000,0000,0000,,Principalmente porque a sua aplicação requer um código maior que os outros dois
Dialogue: 0,0:19:16.71,0:19:21.32,Default,,0000,0000,0000,,modos. No entanto, como eu disse, a Intel especificamente acrescentou instruções para acelerar
Dialogue: 0,0:19:21.32,0:19:26.06,Default,,0000,0000,0000,,modo GCM para cima. E, como resultado, a implementação de GCM na arquitetura Intel leva
Dialogue: 0,0:19:26.06,0:19:30.32,Default,,0000,0000,0000,,muito pouco código. Mas em outras plataformas de hardware, visto em cartões inteligentes ou outros
Dialogue: 0,0:19:30.32,0:19:34.74,Default,,0000,0000,0000,,ambientes restritos, os sites de código para a implementação GCM seria consideravelmente
Dialogue: 0,0:19:34.74,0:19:39.39,Default,,0000,0000,0000,,maior do que para os outros dois modos. Mas se o tamanho do código não é uma restrição, então GCM
Dialogue: 0,0:19:39.39,0:19:43.93,Default,,0000,0000,0000,,é o modo correto de usar. Então, para resumir esse segmento que eu quero dizer mais uma
Dialogue: 0,0:19:43.93,0:19:48.27,Default,,0000,0000,0000,,tempo que, quando você quiser criptografar mensagens que você tem que usar uma autenticação
Dialogue: 0,0:19:48.27,0:19:52.72,Default,,0000,0000,0000,,modo de criptografia e a maneira recomendada para fazer isso é usar um dos padrões,
Dialogue: 0,0:19:52.72,0:19:57.04,Default,,0000,0000,0000,,principalmente um destes três modos para fornecer criptografia de autenticação. Não implementar o esquema de criptografia si mesmo.
Dialogue: 0,0:19:57.04,0:19:59.85,Default,,0000,0000,0000,,Em outras palavras, não implementar criptografar e-MAC-se.
Dialogue: 0,0:19:59.85,0:20:05.84,Default,,0000,0000,0000,,Basta usar um desses três padrões. Muitas bibliotecas criptografar
Dialogue: 0,0:20:05.84,0:20:10.51,Default,,0000,0000,0000,,agora fornecer API padrão para estes três modos e estes são os do que você deve
Dialogue: 0,0:20:10.51,0:20:14.35,Default,,0000,0000,0000,,estar usando e nada mais. No próximo segmento nós vamos ver o que mais pode
Dialogue: 0,0:20:14.35,0:20:17.50,Default,,0000,0000,0000,,dar errado quando você tentar implementar uma criptografia sonicado por si mesmo.