1
00:00:00,000 --> 00:00:03,837
Neste segmento, nós vamos construir sistemas de criptografia autenticados. Uma vez que nós

2
00:00:03,837 --> 00:00:08,250
já tem garantido de criptografia CPA, e temos MACs seguras, a pergunta natural

3
00:00:08,250 --> 00:00:12,824
é se podemos combinar os dois de alguma forma, a fim de obter criptografia autenticado.

4
00:00:12,824 --> 00:00:15,721
E se, que é exatamente o que vamos fazer neste segmento. Criptografia autenticado

5
00:00:15,721 --> 00:00:20,447
foi introduzido no ano de 2000, em dois artigos independentes que apontam para a

6
00:00:20,447 --> 00:00:25,915
final deste módulo. Mas antes disso, muitos crytpolibraries desde uma API que

7
00:00:25,915 --> 00:00:31,215
separadamente suporte a criptografia CPA seguro, amd MAC-ing. Então, houve uma

8
00:00:31,215 --> 00:00:36,175
função para implementar criptografia segura CPA. Por exemplo, a CVC com um aleatória

9
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

10
00:00:41,136 --> 00:00:45,646
queria implementar a criptografia, teve que, ele próprio, chamar separadamente o seguro CPA

11
00:00:45,646 --> 00:00:50,552
esquema de criptografia eo sistema MAC. Em particular, todos os desenvolvedores tiveram que inventar

12
00:00:50,552 --> 00:00:55,697
maneira própria de combinar criptografia e MAC-ing para fornecer algum tipo de

13
00:00:55,697 --> 00:00:59,376
criptografia autenticado. Mas desde que os objetivos da criptografia combinando e MAC-ing

14
00:00:59,376 --> 00:01:03,690
não foi bem compreendida desde criptografia autenticado ainda não foi definida. Ele

15
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

16
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.

17
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

18
00:01:17,202 --> 00:01:22,556
erro comum em projetos de software foram basicamente incorretamente combinando o

19
00:01:22,556 --> 00:01:27,025
criptografia e mecanismos de integridade. Portanto, esperamos que, até o final deste módulo, você

20
00:01:27,025 --> 00:01:31,260
saberá como combiná-los corretamente, e você não estará fazendo estes erros

21
00:01:31,260 --> 00:01:35,174
si mesmo. Então, vamos olhar para algumas combinações de criptografia segura e CPA

22
00:01:35,174 --> 00:01:39,303
MAC, que foram introduzidas por diferentes projetos. Então, aqui estão três exemplos. Assim,

23
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

24
00:01:43,816 --> 00:01:47,774
uma chave separada para MACing. Estas duas chaves são independentes um do outro, e

25
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

26
00:01:52,224 --> 00:01:57,071
duas teclas mais tarde no curso. Assim, o primeiro exemplo é o protocolo SSL. Assim, o

27
00:01:57,071 --> 00:02:02,681
maneira SSL combina criptografia e MAC, na esperança de alcançar a criptografia autenticado

28
00:02:02,681 --> 00:02:07,656
é o seguinte. Basicamente, você toma o texto simples, m, e então você calcular um MAC

29
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

30
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

31
00:02:17,787 --> 00:02:22,580
captionation da mensagem ea marca eo que sai é o texto cifrado final.

32
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

33
00:02:26,710 --> 00:02:31,160
aqui, você leva a mensagem. A primeira coisa que você faz é criptografar a mensagem.

34
00:02:31,160 --> 00:02:35,692
E então, você calcular um tag no texto cifrado resultante. Então você percebe o

35
00:02:35,692 --> 00:02:40,238
tag si mesmo é calculado sobre o texto cifrado resultante. Uma terceira opção é o que o

36
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

37
00:02:45,429 --> 00:02:50,944
esquema de criptografia segura. E então, para ele, concatenadas uma marca da mensagem. O

38
00:02:50,944 --> 00:02:55,567
diferença entre IPsec e SSH, é que em IPsec, a marca é calculado sobre o

39
00:02:55,567 --> 00:02:59,988
texto cifrado, que, em SSH, o tag no computadorizada sobre a mensagem. E assim estes

40
00:02:59,988 --> 00:03:04,536
são três maneiras completamente diferentes de combinar a criptografia e MAC. Eo

41
00:03:04,536 --> 00:03:09,090
pergunta é, qual destes é segura. Então, eu vou deixar você pensar sobre isso por um

42
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

43
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

44
00:03:17,164 --> 00:03:21,629
na mensagem e então concatenado em claro para o texto cifrado. Agora, esta é

45
00:03:21,629 --> 00:03:26,407
realmente um grande problema porque MAC em si não são projetados para fornecer

46
00:03:26,407 --> 00:03:30,784
confidencialidade. Macs são projetados somente para integridade. E, de fato, não há

47
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

48
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

49
00:03:41,458 --> 00:03:46,667
fizemos isso, que seria completamente quebrar a segurança CPA aqui, porque alguns pedaços de

50
00:03:46,667 --> 00:03:51,815
mensagem são divulgados no texto cifrado. E assim, a abordagem SSH, mesmo que o

51
00:03:51,815 --> 00:03:56,595
especificidades da SSH estão bem e do protocolo em si não é comprometida pela

52
00:03:56,595 --> 00:04:00,818
esta combinação específica, geralmente é aconselhável não usar essa abordagem. Simplesmente

53
00:04:00,818 --> 00:04:05,928
porque a saída do algoritmo de assinatura MAC pode vazar bits da mensagem. Assim

54
00:04:05,928 --> 00:04:11,481
agora vamos olhar para SSL e IPsec. Como se vê, o método recomendado, na verdade

55
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

56
00:04:16,556 --> 00:04:21,134
chave que você use a combinação é sempre vai fornecer criptografia autenticado.

57
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

58
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

59
00:04:31,005 --> 00:04:35,761
quando calculamos uma marca do texto cifrado, basicamente, estamos travando, esta tag bloqueios

60
00:04:35,761 --> 00:04:40,815
texto a cifra e garante que ninguém pode produzir um texto cifrado diferente que

61
00:04:40,815 --> 00:04:45,314
olhar válido. E como resultado desta abordagem garante que quaisquer modificações na

62
00:04:45,314 --> 00:04:49,555
texto cifrado será detectado pelo decrypter simplesmente porque o MAC não é

63
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

64
00:04:54,026 --> 00:04:59,348
exemplos patológicos, onde combinam CPA sistema de criptografia seguro com um seguro

65
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

66
00:05:03,542 --> 00:05:07,978
na verdade não fornece criptografia autenticado. E, basicamente, a razão que

67
00:05:07,978 --> 00:05:12,824
poderia acontecer, é que há algum tipo de interação ruim entre a criptografia

68
00:05:12,824 --> 00:05:17,319
esquema eo algoritmo MAC. De tal modo que, de fato, haverá uma cifra escolhida

69
00:05:17,319 --> 00:05:21,752
ataque texto. Então, se você está projetando um novo projeto a recomendação agora é

70
00:05:21,752 --> 00:05:26,162
sempre usar criptografar então MAC porque isso é seguro, não importa qual CPA seguro

71
00:05:26,162 --> 00:05:30,607
algoritmo de criptografia e MAC seguro você está combinando. Agora, só para definir o

72
00:05:30,607 --> 00:05:37,995
terminologia, o método SSL é às vezes chamado MAC-then-encrypt. Eo

73
00:05:37,995 --> 00:05:45,039
método IPsec é chamado encrypt-then-MAC. O método SSH mesmo que seu

74
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

75
00:05:51,898 --> 00:05:57,002
encrypt-then-MAC e MAC-then-criptografar para diferenciar SSL e IPsec. Ok, então

76
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

77
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

78
00:06:07,160 --> 00:06:11,110
Você sempre terá criptografia autenticado. Como eu disse, MAC-depois-criptografar em

79
00:06:11,110 --> 00:06:15,737
fato, há casos patológicos, onde o resultado é vulnerável a fatos CCA e

80
00:06:15,737 --> 00:06:20,308
, portanto, não fornece criptografia autenticado. No entanto, a história é um pouco

81
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

82
00:06:24,653 --> 00:06:29,224
modo aleatório contador ou CBC randomizado, em seguida, ao que parece, para aqueles que especial

83
00:06:29,224 --> 00:06:33,625
CPA esquemas de criptografia seguras, MAC-then-criptografar realmente dá autenticado

84
00:06:33,625 --> 00:06:38,028
criptografia e por isso é seguro. De fato, há mesmo uma mais interessante

85
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

86
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

87
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,

88
00:06:51,561 --> 00:06:56,088
ok? E quando falamos sobre a integridade da mensagem, vimos que há realmente

89
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

90
00:07:00,575 --> 00:07:04,454
resultado, se você estiver usando o modo aleatório contra-MAC, em seguida, criptografar-pudesse realmente

91
00:07:04,454 --> 00:07:08,187
resultado em um mecanismo de criptografia mais eficiente. No entanto, eu vou repetir

92
00:07:08,187 --> 00:07:12,213
isso de novo. A recomendação é usar encrypt-then-MAC e estamos indo para ver um

93
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

94
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

95
00:07:20,120 --> 00:07:24,118
vai recomendar que você use sempre encrypt-then-MAC. Agora, uma vez que o conceito de

96
00:07:24,118 --> 00:07:27,759
criptografia autenticada tornou-se mais popular, um número de padronizada

97
00:07:27,759 --> 00:07:31,609
abordagens para a combinação de criptografia e MAC apareceu. E eram mesmo

98
00:07:31,609 --> 00:07:35,978
padronizado pelo Instituto Nacional de Padrões. Então eu só vou mencionar três

99
00:07:35,978 --> 00:07:41,031
destas normas. Dois deles foram padronizados pelo NIST. E estes são

100
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.

101
00:07:46,138 --> 00:07:51,245
modo Galois contador basicamente usa criptografia de modo contador, para um contador randomizado

102
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

103
00:07:56,164 --> 00:08:01,146
Carter-Wegman MAC trabalha em GCM é que é basicamente uma função hash da mensagem

104
00:08:01,146 --> 00:08:06,311
que está sendo MACed. E então o resultado é criptografada usando um PRF. Agora esse hash

105
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

106
00:08:11,562 --> 00:08:15,845
hora do GCM é dominada pelo modo de contador de criptografia e está ainda fez mais,

107
00:08:15,845 --> 00:08:22,371
em que a Intel introduz um PCLMULQDQ instrução especial especificamente

108
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.

109
00:08:27,432 --> 00:08:32,950
Agora modo contador CCM é um outro padrão NIST ele usa um MAC CBC. E

110
00:08:32,950 --> 00:08:37,276
então criptografia modo de contador. Portanto, este mecanismo, você sabe, este usa MAC, então

111
00:08:37,276 --> 00:08:40,906
encrypt, como SSL faz. Portanto, este não é realmente a maneira recomendada de se fazer

112
00:08:40,906 --> 00:08:44,023
coisas, mas porque a criptografia modo contador é usado. Esta é realmente uma

113
00:08:44,023 --> 00:08:47,945
mecanismo de criptografia perfeitamente bem. Uma coisa que eu gostaria de ressaltar sobre

114
00:08:47,945 --> 00:08:53,799
CCM, é que tudo é baseado em AES. Você percebe, ele está usando AES para a CBC

115
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

116
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

117
00:09:03,084 --> 00:09:08,343
e nada mais. E por isso, CCM, na verdade foi adoptada pelo Wi-Fi

118
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

119
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

120
00:09:19,093 --> 00:09:23,450
entre o laptop eo ponto de acesso. Há um outro modo chamado EAX que

121
00:09:23,450 --> 00:09:28,922
usa criptografia de modo contador, e depois CMAC. Então, novamente você notar encrypt-de-mac

122
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

123
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

124
00:09:36,806 --> 00:09:41,190
nonce-based. Em outras palavras, eles não usam qualquer aleatoriedade, mas eles tomam como

125
00:09:41,190 --> 00:09:46,360
entrada um nonce e nonce deve ser único por chave. Em outras palavras, como você

126
00:09:46,360 --> 00:09:50,600
lembre-se, a par nonce chave comum não deve nunca, nunca repetir. Mas o

127
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

128
00:09:53,851 --> 00:09:57,520
exemplo, como um uso único. E o outro ponto importante é que, na verdade, todos

129
00:09:57,520 --> 00:10:01,384
estes modos são o que se chama de criptografia autenticado com associados

130
00:10:01,384 --> 00:10:04,936
dados. Esta é uma extensão de criptografia autenticado, mas que vem

131
00:10:04,936 --> 00:10:10,884
-se muitas vezes em protocolos de rede. Portanto, a ideia entre AEAD é que, na verdade,

132
00:10:10,884 --> 00:10:15,223
a mensagem que é fornecido para o modo de criptografia não se destina a ser totalmente

133
00:10:15,223 --> 00:10:19,924
encriptado. Apenas uma parte da mensagem se destina a ser criptografada, mas todo o

134
00:10:19,924 --> 00:10:24,157
mensagem se destina a ser autenticado. Um bom exemplo disto é um pacote de rede.

135
00:10:24,157 --> 00:10:29,408
Pense como um pacote IP, onde há um cabeçalho. E depois há uma carga e

136
00:10:29,408 --> 00:10:33,157
normalmente o cabeçalho não vai ser criptografados. Por exemplo, o cabeçalho pode

137
00:10:33,157 --> 00:10:36,905
conter o destino do pacote, mas, em seguida, o cabeçalho é melhor que não seja

138
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.

139
00:10:40,950 --> 00:10:45,225
E assim, tipicamente o cabeçalho é enviado em claro, que a carga, é claro, é

140
00:10:45,225 --> 00:10:49,500
sempre criptografados, mas o que você gostaria de fazer é ter o cabeçalho ser autenticado.

141
00:10:49,500 --> 00:10:55,907
não criptografado, mas autenticado. Portanto, este é exatamente o que estes modos AEAD, fazer. Eles

142
00:10:55,907 --> 00:11:00,033
irá autenticar o cabeçalho e, em seguida, criptografar a carga. Mas o cabeçalho e

143
00:11:00,033 --> 00:11:04,177
carga a estão unidos na autenticação para a autenticação não pode

144
00:11:04,177 --> 00:11:07,803
realmente ser separados. Então isso não é difícil de fazer. O que acontece nestes

145
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

146
00:11:14,170 --> 00:11:18,852
criptografia é aplicada somente a parte dos dados que precisam ser criptografados.

147
00:11:18,852 --> 00:11:22,983
Então, eu queria mostrar o que uma API para criptografia autenticado com

148
00:11:22,983 --> 00:11:28,716
dados associados esquemas de criptografia semelhante. Então aqui está o que parece no OpenSSL

149
00:11:28,716 --> 00:11:33,609
Por exemplo, isto é, uma API para GCM. Então o que você faz é chamar a

150
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

151
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

152
00:11:40,609 --> 00:11:44,402
ser único. E após a inicialização, você poderia chamar essa função encrypt, onde

153
00:11:44,402 --> 00:11:48,169
você vê que você dê a ele a dados associado que vai ser autenticadas, mas

154
00:11:48,169 --> 00:11:51,794
não criptografado. Você dá os dados, e vai ser autenticada e

155
00:11:51,794 --> 00:11:55,752
encriptado. E dá-lhe de volta o texto cifrado completo, que é uma criptografia da

156
00:11:55,752 --> 00:11:59,582
dados, mas é claro que não inclui o AAD, porque o DAA vai ser enviado em

157
00:11:59,582 --> 00:12:04,535
claro. Portanto, agora que entendemos esse modo de criptografar-then-MAC, que pode ir

158
00:12:04,535 --> 00:12:09,951
volta para a definição de MAC segurança e posso explicar-lhe algo que poderia

159
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,

160
00:12:13,970 --> 00:12:18,570
um dos requisitos que se seguiram a nossa definição de MACs seguras significava que

161
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

162
00:12:25,689 --> 00:12:30,386
a mesma mensagem M. Em outras palavras, mesmo que o invasor já tem uma marca para

163
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.

164
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á

165
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

166
00:12:44,038 --> 00:12:48,828
que o MAC não tem essa propriedade. Em outras palavras, dada uma mensagem

167
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

168
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

169
00:12:58,694 --> 00:13:03,961
ter auto-ajuste integridade, é crucial que a nossa Segurança MAC implicaria uma forte

170
00:13:03,961 --> 00:13:08,910
noção de segurança, o que, evidentemente, não faz porque definido-lo correctamente.

171
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

172
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

173
00:13:18,081 --> 00:13:22,784
sistema encrypt-then-MAC resultante. E já que o sistema tem um texto cifrado escolhido

174
00:13:22,784 --> 00:13:27,193
ataque sobre ela, significa necessariamente que ele não fornece uma autenticado

175
00:13:27,193 --> 00:13:31,458
criptografia. Então vamos ver. Então começo do adversário gonnna enviando dois

176
00:13:31,458 --> 00:13:35,861
mensagens, M0 e M1. E ele vai receber, como de costume, a criptografia de um

177
00:13:35,861 --> 00:13:39,522
deles, a criptografia de M0 ou a criptografia de M1. E já que estamos

178
00:13:39,522 --> 00:13:44,907
usando encrypt-then-MAC, o adversário recebe um texto cifrado, vamos chamar um C0

179
00:13:44,907 --> 00:13:49,883
e MAC no texto cifrado C0. Bem, agora temos dito que, dada a MAC

180
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

181
00:13:53,827 --> 00:13:57,994
ele vai fazer é que ele vai produzir um outro MAC na mensagem C0. Agora, ele tem

182
00:13:57,994 --> 00:14:03,532
um texto cifrado de novo (C0, T '), que é um texto cifrado perfeitamente válido. T 'é um

183
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

184
00:14:09,558 --> 00:14:14,492
em C 'e esta é uma consulta de texto válido cifra escolhida porque é diferente

185
00:14:14,492 --> 00:14:19,288
de C. É um texto cifrado de novo. O desafiante pobre agora é obrigado a decifrar este

186
00:14:19,288 --> 00:14:23,278
texto cifrado C 'para que ele vai mandar de volta a descriptografia de C'. É uma

187
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

188
00:14:29,093 --> 00:14:32,318
atacante acabou de aprender o valor de B, porque ele pode testar se Mb é igual a

189
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

190
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

191
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

192
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

193
00:14:53,181 --> 00:14:57,241
significa que criptografam-then-MAC realmente fornecer criptografia autenticado. E

194
00:14:57,241 --> 00:15:01,728
durante todos os MACs que discutimos realmente satisfazer essa noção forte de

195
00:15:01,728 --> 00:15:06,146
unforgeability. Assim, curiosamente, este não é o fim da história. Então, como dissemos

196
00:15:06,146 --> 00:15:10,385
antes do conceito de criptografia autenticado foi introduzido todos estavam

197
00:15:10,385 --> 00:15:15,295
apenas combinando MACs e criptografia de várias maneiras, na esperança de alcançar

198
00:15:15,295 --> 00:15:19,201
alguns, alguns criptografia autenticado. Após a noção de criptografia autenticado

199
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:

200
00:15:23,553 --> 00:15:28,130
ei, espere um minuto. Talvez possamos alcançar a criptografia autenticada de forma mais eficiente

201
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

202
00:15:32,722 --> 00:15:37,366
esta combinação de MAC e criptografia funciona, vamos dizer que combinar o modo de contador

203
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

204
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

205
00:15:46,419 --> 00:15:51,357
novamente, para o CBC-MAC. Isto significa que se você combinar CPA criptografia segura com um

206
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,

207
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

208
00:16:00,535 --> 00:16:05,396
era, podemos construir um sistema de criptografia autenticado diretamente de um PRP,

209
00:16:05,396 --> 00:16:10,345
tal que teríamos que apenas avaliar o PRP, uma vez por bloco. E acontece

210
00:16:10,345 --> 00:16:14,117
, a resposta é sim, e há estes bela construção denominada OCB, que

211
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

212
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

213
00:16:22,467 --> 00:16:26,290
da OCB. Eu não quero explicar em detalhes. Vou explicá-lo meio a uma

214
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ê

215
00:16:30,025 --> 00:16:34,540
aviso de que, em primeiro lugar, OCB é paralelizável, completamente paralelizável.

216
00:16:34,540 --> 00:16:39,700
Assim, cada bloco pode ser criptografado separadamente de cada outro bloco. A outra coisa a

217
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

218
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

219
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 é

220
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

221
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

222
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

223
00:17:08,238 --> 00:17:12,748
para cada bloco e você XOR o resultado antes e depois de criptografia usando o

224
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

225
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

226
00:17:22,241 --> 00:17:26,065
realmente tem um teorema de segurança agradável associado com ele e eu vou apontar

227
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

228
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

229
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

230
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

231
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

232
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

233
00:17:54,567 --> 00:17:58,216
queria mostrar-lhe alguns números de desempenho. Então, aqui à direita listei

234
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

235
00:18:02,368 --> 00:18:07,879
modo casualizado contador, e isto é para CBC casualizado. E você pode ver também o

236
00:18:07,879 --> 00:18:12,460
desempenho de CBC MAC é basicamente o mesmo que o desempenho de criptografia CBC.

237
00:18:12,460 --> 00:18:16,221
Ok. E aqui são os modos de criptografia autenticados, por isso estes são os

238
00:18:16,221 --> 00:18:20,083
que você deveria usar, estes que você não deveria estar usando em sua

239
00:18:20,083 --> 00:18:23,795
próprio, direito. Estes dois, você nunca deve usar esses dois, porque eles só

240
00:18:23,795 --> 00:18:27,858
fornecer CPA segurança, eles realmente não oferecer segurança contra ativa

241
00:18:27,858 --> 00:18:31,669
ataques. Você só deve usar criptografia autenticado para criptografia.

242
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á

243
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

244
00:18:40,109 --> 00:18:43,770
criptografia real. E você pode ver que a sobrecarga de GCM sobre o modo de contador é

245
00:18:43,770 --> 00:18:49,554
relativamente pequeno. CCM e EAX tanto usar uma criptografia Sipher bloco base e um

246
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

247
00:18:54,627 --> 00:18:59,196
modos. Você vê que é realmente mais rápido OCB destes, principalmente porque

248
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

249
00:19:03,820 --> 00:19:08,328
números, você poderia pensar que GCM é exatamente o modo correto de usar sempre. Mas

250
00:19:08,328 --> 00:19:12,659
acontece se você está no hardware espaço restrito, GCM não é o ideal.

251
00:19:12,659 --> 00:19:16,709
Principalmente porque a sua aplicação requer um código maior que os outros dois

252
00:19:16,709 --> 00:19:21,323
modos. No entanto, como eu disse, a Intel especificamente acrescentou instruções para acelerar

253
00:19:21,323 --> 00:19:26,064
modo GCM para cima. E, como resultado, a implementação de GCM na arquitetura Intel leva

254
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

255
00:19:30,315 --> 00:19:34,745
ambientes restritos, os sites de código para a implementação GCM seria consideravelmente

256
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

257
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

258
00:19:43,928 --> 00:19:48,267
tempo que, quando você quiser criptografar mensagens que você tem que usar uma autenticação

259
00:19:48,267 --> 00:19:52,716
modo de criptografia e a maneira recomendada para fazer isso é usar um dos padrões,

260
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.

261
00:19:57,037 --> 00:19:59,846
Em outras palavras, não implementar criptografar e-MAC-se.

262
00:19:59,846 --> 00:20:05,842
Basta usar um desses três padrões. Muitas bibliotecas criptografar

263
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

264
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

265
00:20:14,347 --> 00:20:17,500
dar errado quando você tentar implementar uma criptografia sonicado por si mesmo.