0:00:00.000,0:00:04.010
Neste segmento, eu quero dar alguns exemplos de fluxo cifras que são usados na prática.

0:00:04.010,0:00:07.072
Vou começar com dois exemplos antigos que na verdade não são

0:00:07.072,0:00:11.017
suposto ser usado em sistemas novos. Mas, no entanto, eles ainda são bastante

0:00:11.017,0:00:14.164
amplamente utilizada, e assim que eu apenas quero mencionar os nomes para que você esteja familiarizado com

0:00:14.164,0:00:19.087
esses conceitos. A cifra de fluxo primeiro eu quero falar é chamado RC4, projetado

0:00:19.087,0:00:23.429
em 1987. E eu só vou te dar a descrição de alto nível e, em seguida

0:00:23.429,0:00:27.818
nós vamos falar sobre alguns pontos fracos do RC4 e deixar por isso mesmo. Assim RC4 leva um

0:00:27.818,0:00:32.702
sementes de tamanho variável, aqui eu só dei como um exemplo onde levaria 128

0:00:32.702,0:00:36.980
bits como o tamanho das sementes, que passaria então a ser utilizados como chave para a cifra de fluxo.

0:00:36.980,0:00:41.738
A primeira coisa que faz, é que se expande a chave de 128-bit segredo em 2.048 bits, que

0:00:41.738,0:00:46.382
vão ser usados como o estado interno para o gerador. E então, quando ele é feito

0:00:46.382,0:00:51.197
esta expansão, que basicamente executa um laço muito simples, onde cada iteração do

0:00:51.197,0:00:55.898
laço Isso gera um byte de saída. Então, basicamente, você pode executar o gerador de

0:00:55.898,0:01:00.653
, enquanto você quer, e gerar um byte de cada vez. Agora RC4 é, na verdade, como eu disse,

0:01:00.653,0:01:05.205
bastante popular. É usado no protocolo HTTPS é bastante comum, na verdade.

0:01:05.205,0:01:11.888
Estes dias, por exemplo, o Google usa RC4 em suas HTTPS. Também é usado no WEP como nós

0:01:11.888,0:01:15.686
discutido no último segmento, mas é claro que no WEP, ele é usado incorretamente e

0:01:15.686,0:01:18.861
é completamente inseguro da forma como ele é usado dentro do WEP. Assim, ao longo dos anos,

0:01:18.861,0:01:23.886
algumas deficiências foram encontradas no RC4, e como resultado, é recomendado que os novos projetos

0:01:23.886,0:01:28.793
na verdade não usar RC4, mas sim usar um mais moderno gerador pseudo-aleatório como veremos

0:01:28.793,0:01:34.059
discutir para a extremidade do segmento. Então deixe-me mencionar apenas dois dos pontos fracos.

0:01:34.059,0:01:39.561
Então a primeira é que é tipo de bizarra, basicamente, se você olhar para o segundo byte

0:01:39.561,0:01:44.630
da produção de RC4. Acontece que o segundo byte é um pouco tendencioso. Se RC4 foi

0:01:44.630,0:01:49.780
completamente aleatória, a probabilidade de que o segundo byte acontece ser igual a zero

0:01:49.780,0:01:54.744
seria exatamente um sobre 256. Existem 256 bytes possíveis, a probabilidade que

0:01:54.744,0:01:59.646
zero, deveria ser um sobre 256. Acontece que para RC4 a probabilidade é

0:01:59.646,0:02:04.486
realmente dois por 256, o que significa que se você usar a saída RC4 para criptografar uma

0:02:04.486,0:02:09.574
mensagem do segundo byte é provável que não seja encriptada de todo. Em outras palavras, ele vai

0:02:09.574,0:02:14.575
ser XOR-ed com zero com o dobro da probabilidade de que é suposto.

0:02:14.575,0:02:19.436
Assim, dois sobre 256, em vez de um sobre 256. E pelo jeito que eu deveria dizer que há

0:02:19.436,0:02:22.849
nada de especial sobre o segundo byte. Acontece que a primeira e os bytes terceiros

0:02:22.849,0:02:27.818
também são tendenciosos. E de fato ele é agora recomendado que se você vai usar RC4,

0:02:27.818,0:02:32.800
que você deve fazer é ignorar, basicamente, os primeiros 256 bytes da saída e apenas

0:02:32.800,0:02:37.246
começar a utilizar a saída do gerador a partir de byte 257. O primeiro casal

0:02:37.246,0:02:41.241
de bytes acabou por ser tendencioso, então você simplesmente ignorá-los. O segundo ataque que

0:02:41.241,0:02:48.482
foi descoberto é que de fato se você olhar para uma saída muito longo de RC4 que acontece

0:02:48.482,0:02:53.863
que você é mais provável conseguir o 00 de seqüência. Em outras palavras, você é mais

0:02:53.863,0:02:58.970
probabilidade de obter dezesseis bits, dois bytes de zero, zero, do que deveria. Novamente, se RC4

0:02:58.970,0:03:03.948
foi completamente aleatória a probabilidade de ver zero, zero seria exatamente 1/256

0:03:03.948,0:03:08.556
quadrado. Acontece RC4 é um pouco tendencioso eo viés é 1/256 cubos. Ele

0:03:08.556,0:03:13.718
Acontece que este viés realmente começa depois de vários gigabytes de dados são produzidos por

0:03:13.718,0:03:18.634
RC4. Mas, no entanto, este é algo que pode ser utilizado para prever o gerador

0:03:18.634,0:03:23.120
e, definitivamente, ele pode ser usado para distinguir a saída do gerador

0:03:23.120,0:03:28.097
partir de uma seqüência verdadeiramente aleatória. Basicamente o fato de que zero, zero aparece com mais freqüência

0:03:28.097,0:03:32.414
do que deveria é o Distinguisher. E então, no último segmento que falamos

0:03:32.414,0:03:36.313
relacionado-chave ataques que foram usados para atacar WEP, que basicamente dizem que

0:03:36.313,0:03:41.078
se teclas de um utilizações que estão intimamente relacionadas entre si, então é realmente possível

0:03:41.078,0:03:45.732
para recuperar a chave raiz. Assim, estes são os pontos fracos que são conhecidos de RC4 e, como um

0:03:45.732,0:03:50.217
resultado, é recomendado que os novos sistemas não realmente usar RC4 e utilizar um

0:03:50.217,0:03:54.421
gerador pseudo-aleatório moderna. Ok, segundo exemplo que quero dar-lhe é um

0:03:54.421,0:03:59.131
cifra de fluxo gravemente quebrado que é usada para criptografar filmes em DVD. Quando você compra um DVD

0:03:59.131,0:04:03.504
na loja, o próprio filme é criptografada usando uma cifra de fluxo chamado de

0:04:03.504,0:04:07.933
Content Scrambling System, CSS. CSS acaba por ser uma cifra de fluxo gravemente quebrado

0:04:07.933,0:04:12.523
e podemos muito facilmente quebrá-lo, e eu quero mostrar-lhe como o algoritmo de ataque

0:04:12.523,0:04:16.894
obras. Estamos fazendo isso para que você possa ver um exemplo de um algoritmo de ataque, mas em

0:04:16.894,0:04:21.435
verdade, existem muitos sistemas por aí que, basicamente, usar este ataque para descriptografar

0:04:21.435,0:04:25.749
DVDs criptografados. Assim, a cifra de fluxo CSS é baseada em algo que o hardware

0:04:25.749,0:04:30.291
projetistas gosta. Ele foi projetado para ser uma cifra de fluxo de hardware que é suposto

0:04:30.291,0:04:34.491
ser fácil de implementar em hardware, e baseia-se um mecanismo chamado linear

0:04:34.491,0:04:38.749
mudança comentários registar. Assim, um registrador de deslocamento linear feedback é basicamente um registo

0:04:38.749,0:04:43.801
que consiste em células em que cada célula contém um bit. Então, basicamente,

0:04:43.801,0:04:49.046
que acontece é que existem estas torneiras em certas células, não todas as células, certos

0:04:49.046,0:04:54.134
posições são chamados torneiras. E então essas torneiras alimentar em um XOR e, em seguida, em

0:04:54.134,0:04:59.053
cada ciclo de clock, o registrador de deslocamento desloca para a esquerda. O último pedaço cair

0:04:59.053,0:05:04.345
e, em seguida, o primeiro bit torna-se o resultado deste XOR. Assim você pode ver que

0:05:04.345,0:05:08.703
este é um mecanismo muito simples de implementar, e em hardware tem muito poucos

0:05:08.703,0:05:13.622
transistores. Apenas o deslocamento para a direita, o último bit cai e apenas o primeiro bit

0:05:13.622,0:05:18.541
torna-se o XOR dos bits anteriores. Assim, a semente para este LFSR

0:05:18.541,0:05:23.460
, basicamente, é o estado inicial do LFSR.

0:05:23.650,0:05:28.538
E é a base de uma série de codificações de fluxo. Então, aqui estão alguns exemplos. Assim, como

0:05:28.538,0:05:33.362
eu disse, a criptografia utiliza duas LFSRs DVD. Eu vou te mostrar como isso funciona em apenas um

0:05:33.362,0:05:38.060
segundo. Criptografia GSM, estes são chamados algoritmos A51 e A52. E isso

0:05:38.060,0:05:43.456
utiliza três LFSRs. Criptografia Bluetooth é um algoritmo chamado, E zero. Estes são todos

0:05:43.456,0:05:48.534
cifras de fluxo, e que utiliza quatro LFSRs. Acontece que todos eles são gravemente quebrado

0:05:48.534,0:05:53.245
e na verdade realmente não deve ser confiável para criptografar o tráfego, mas todos eles são

0:05:53.245,0:05:56.705
implementado em hardware, por isso é um pouco difícil agora para mudar o que o hardware

0:05:56.705,0:06:01.047
faz. Mas o mais simples deles, CSS, na verdade, tem um ataque bonito nele, então vamos

0:06:01.047,0:06:05.459
me mostrar-lhe como o ataque funciona. Então, vamos descrever como o CSS realmente funciona. Assim,

0:06:05.459,0:06:11.073
chave para o CSS é de cinco bytes, ou seja, 40 bits, cinco vezes oito é de 40 bits. O

0:06:11.073,0:06:15.587
razão eles tinham que se limitar a apenas 40 bits é que a criptografia do DVD foi

0:06:15.587,0:06:19.941
concebidos numa altura em que os regulamentos de exportação dos Estados Unidos só é permitido para a exportação de

0:06:19.941,0:06:25.086
algoritmos crpyto onde estava a chave apenas 40 bits. Assim, os designers de CSS foram

0:06:25.086,0:06:30.206
já limitados a chaves muito, muito curtos. Apenas 40 teclas bit. Assim, seu projeto trabalha

0:06:30.206,0:06:35.398
como se segue. Basicamente, o CSS usa duas LFSR do. Um é um LFSR de 17-bit. Em outras palavras,

0:06:35.398,0:06:40.806
registo a contém 17 bits. Eo outro é um LFSR 25-bit,

0:06:40.806,0:06:46.647
é um pouco mais, 25 bits LFSR. E a forma como estas são semeadas LFSRs

0:06:46.647,0:06:51.870
é como se segue. Portanto, a chave para a criptografia, basicamente, tem a seguinte aparência.

0:06:51.870,0:06:57.669
Você começa com um, e você concatenar a ele os dois primeiros bytes de

0:06:57.669,0:07:02.947
chave. E esse é o estado inicial do LFSR.

0:07:02.947,0:07:08.256
E então o segundo LFSR basicamente é intitialized da mesma maneira.

0:07:08.256,0:07:14.012
Uma concatenado os últimos três bytes da chave. E isso é

0:07:14.012,0:07:19.889
carregado para o estado inicial do LFSR. Você pode ver que os dois primeiros bytes são

0:07:19.889,0:07:25.411
16 bits, mais um líder, que tem dezessete pedaços geral, enquanto o segundo

0:07:25.411,0:07:31.217
LFSR é de 24 bits, mais um que é de 25 bits. E você percebe usamos todos os cinco pedaços de

0:07:31.217,0:07:36.881
chave. Então essas são basicamente LFSRs correr para oito ciclos, de modo que elas geram

0:07:36.881,0:07:42.333
oito bits de saída. E então eles passam por este componente que faz basicamente

0:07:42.333,0:07:48.197
adição módulo 256. É assim que esta é uma caixa disso, módulo 256. Há mais uma

0:07:48.197,0:07:54.325
coisa técnica que acontece. Na verdade vamos realmente, também adicionada é o transporte do

0:07:54.325,0:07:59.723
bloco anterior. Mas isso não é tão importante. Isso é um detalhe que não é tão

0:07:59.723,0:08:04.761
relevante. OK, então todos os blocos, você percebe que estamos fazendo além modulo 256 e

0:08:04.761,0:08:09.982
estamos ignorando o transporte, mas o transporte é basicamente adicionado como um zero ou um um ao

0:08:09.982,0:08:15.147
além do bloco seguinte. Ok? E então, basicamente, esta saída um byte por round.

0:08:15.147,0:08:20.411
Ok, e então este byte é usado, então é claro, XOR-ed com o adequado

0:08:20.411,0:08:25.167
byte do filme que está sendo criptografado. Ok, então é um fluxo muito simples

0:08:25.167,0:08:29.986
cifra, é preciso hardware muito pouco para implementar. Ele irá correr rápido, mesmo em muito

0:08:29.986,0:08:35.830
hardware barato e vai criptografar filmes. Então, acontece que este é fácil de quebrar

0:08:35.830,0:08:41.222
no tempo cerca de dois a 17. Agora deixe-me mostrar-lhe como.

0:08:41.222,0:08:45.734
Então, suponha que você interceptar os filmes, então aqui nós temos um

0:08:45.734,0:08:50.647
filme criptografado que você deseja descriptografar. Então, digamos que tudo isso é criptografado para

0:08:50.647,0:08:55.279
você não tem idéia do que está dentro de aqui. No entanto, acontece que só porque

0:08:55.279,0:08:59.970
criptografia DVD está usando arquivos MPEG, acontece se você souber de um prefixo da

0:08:59.970,0:09:04.250
texto simples, vamos apenas dizer que talvez esta é de vinte bytes. Bem, sabemos que se você

0:09:04.250,0:09:08.589
XOR essas duas coisas juntas, então, em outras palavras, você faz o XOR aqui,

0:09:08.589,0:09:13.523
que você vai conseguir é o segmento inicial do PRG. Assim, você terá a

0:09:13.523,0:09:18.472
primeiros vinte bytes de a saída do CSS, a saída do presente PRG. Ok, então agora

0:09:18.472,0:09:23.986
aqui é o que nós vamos fazer. Assim, temos os primeiros vinte bytes de saída. Agora

0:09:23.986,0:09:31.405
nós fazemos o seguinte. Nós experimentar todos dois para os valores possíveis de 17 a primeira

0:09:31.405,0:09:37.088
LFSR. Ok? Assim, duas aos dezassete valores possíveis. Assim, para cada valor, portanto, para

0:09:37.088,0:09:42.622
cada um destes dois aos dezassete valores iniciais do LFSR, vamos executar o

0:09:42.622,0:09:47.953
LFSR por vinte bytes, ok? Então, vamos gerar de vinte bytes de saídas a partir deste

0:09:47.953,0:09:53.284
LFSR primeiro, assumindo-para cada um dos dois para os dezassete configurações possíveis.

0:09:53.284,0:09:58.615
Agora, lembre-se que temos o resultado completo do sistema de CSS. Então o que podemos fazer é nos

0:09:58.615,0:10:03.814
pode tomar esta saída que temos. E subtrair os vinte mordidas que nós

0:10:03.814,0:10:08.928
obtido a partir do LFSR primeiro, e se de fato o nosso palpite para o estado inicial do primeiro

0:10:08.928,0:10:14.042
LFSR está correta, o que devemos começar é a saída 20-primeiro byte do

0:10:14.042,0:10:19.222
LFSR segundo. Certo? Porque isso é, por definição, o que a saída do CSS

0:10:19.222,0:10:24.501
sistema é. Agora, descobre-se que olhar para uma seqüência de 20 bytes, é muito fácil

0:10:24.501,0:10:29.763
dizer se essa seqüência de 20-byte veio de um LFSR 25-bit ou não. Se

0:10:29.763,0:10:33.561
não, então sabemos que o nosso palpite para o LFSR 17-bit foi

0:10:33.561,0:10:37.416
incorreto e, em seguida, passamos para o próximo palpite para o LFSR 17-bit e

0:10:37.416,0:10:41.904
suposição o seguinte e assim por diante e assim por diante. Até que finalmente chegamos ao direito inicial

0:10:41.904,0:10:46.937
estado para o LFSR 17-bit, e depois vamos realmente começar, vamos ver que

0:10:46.937,0:10:51.969
os 20 bytes que obtemos como a saída candidato para o LFSR 25-bit é

0:10:51.969,0:10:56.936
, de facto, uma saída possível para um LFSR 25-bit. E então, não só teremos

0:10:56.936,0:11:02.164
aprendeu o estado inicial correto para o LFSR 17-bit, nós também teremos

0:11:02.164,0:11:07.523
aprendeu o estado inicial correto do LFSR 25-bit. E então podemos prever o

0:11:07.523,0:11:12.796
saídas restantes do CSS, e é claro, usar isso, podemos, então, decifrar o resto

0:11:12.796,0:11:17.565
o filme. Na verdade, podemos recuperar o texto restante. Okay. Isto é

0:11:17.565,0:11:22.335
coisas que falamos antes. Então, eu disse isso um pouco rápido, mas espero que,

0:11:22.335,0:11:27.331
ficou claro. Nós também vamos estar fazendo um exercício de dever de casa neste tipo de fluxo

0:11:27.331,0:11:31.444
cifras e você vai espécie de chegar ao ponto de como esses algoritmos de ataque

0:11:31.444,0:11:36.018
trabalho. E devo mencionar que existem muitos sistemas open-source, agora que realmente

0:11:36.018,0:11:41.453
usar esse método para descriptografar CSS dados criptografados. Ok, então agora que já vimos dois

0:11:41.453,0:11:45.888
fracos exemplos, vamos passar para exemplos melhores, e em particular o melhor

0:11:45.888,0:11:49.370
pseudo-aleatórios geradores vêm do que é chamado de Projeto eSTREAM. Esta é uma

0:11:49.370,0:11:55.556
projeto que concluiu em 2008, e que se qualifiquem, basicamente, cinco fluxo diferente

0:11:55.556,0:12:00.207
cifras, mas aqui quero apresentar apenas um. Então, primeiro de todos os parâmetros para

0:12:00.207,0:12:04.029
essas cifras de fluxo é um pouco diferente do que estamos acostumados. Então, essas

0:12:04.029,0:12:08.340
fluxo cifras normalmente eles têm uma semente. Mas, além disso eles também têm, o que é

0:12:08.340,0:12:12.821
chamado nonce e vamos ver o que é um nonce é usada em apenas um minuto. Assim

0:12:12.821,0:12:17.487
tomam duas entradas de uma semente e um nonce. Vamos ver o que o nonce é usada no

0:12:17.487,0:12:21.274
apenas um segundo. E claro que o de produzir uma saída muito grande, então n é aqui

0:12:21.274,0:12:26.603
muito, muito, muito maior do que s. Agora, quando eu digo nonce, o que quero dizer é um valor que é

0:12:26.603,0:12:31.218
nunca indo para repetir enquanto a chave é fixo. E eu vou explicar isso em mais

0:12:31.218,0:12:35.400
detalhe em apenas um segundo. Mas, por agora, basta pensar nisso como um valor único que nunca

0:12:35.400,0:12:40.527
repete, desde que a chave é a mesma. E então é claro que quando você tem este PRG,

0:12:40.527,0:12:45.357
você criptografar, você obtém uma cifra de fluxo tal como antes, só que agora como você vê, o

0:12:45.357,0:12:49.955
PRG toma como entrada tanto a chave eo nonce. E a propriedade do nonce é

0:12:49.955,0:12:56.350
que o par, k vírgula r, de modo a vírgula chave nonce, é nunca, nunca se repete. É

0:12:56.350,0:13:03.096
nunca usou mais de uma vez. Assim a linha inferior é que você pode reutilizar a chave, reutilizar

0:13:03.096,0:13:09.710
a chave, porque o uso único faz com que o par único, porque K e R são apenas

0:13:09.710,0:13:16.135
usado uma vez. Eu vou dizer que é único. Ok então este nonce é uma espécie de truque bonito que

0:13:16.135,0:13:21.541
nos salva a dificuldade de se mudar para uma nova chave de cada vez. Ok, então o particular

0:13:21.541,0:13:26.000
exemplo do eSTREAM que eu quero lhe mostrar é chamado Salsa 20. É uma

0:13:26.000,0:13:30.292
cifra de fluxo que é projetado para implementações de software e hardware

0:13:30.292,0:13:33.385
implementações. É uma espécie de interessante. Você percebe que algumas cifras de fluxo são

0:13:33.385,0:13:38.763
projetado para software, como RC4. Tudo que ele faz é projetado para fazer

0:13:38.763,0:13:42.689
implementação de software de correr rápido, enquanto o fluxo cifras outros são projetados para

0:13:42.689,0:13:48.143
hardware, como CSS, utilizando um LFSR que está particularmente desenhado para fazer hardware

0:13:48.143,0:13:50.963
implementações muito baratos. É também, a única coisa boa disso é que é

0:13:50.963,0:13:55.008
projetado de modo que seja fácil de implementar em hardware e seu software

0:13:55.008,0:13:59.747
implementação também é muito rápido. Então deixe-me explicar como Salsa obras. Bem, Salsa

0:13:59.747,0:14:05.130
leva ou 128 ou 256-bit chaves. Eu só vou explicar a versão de 128 bits do Salsa.

0:14:05.130,0:14:11.244
Então esta é a semente. E então ele também leva um nonce, tal como antes, que

0:14:11.244,0:14:15.425
passa a ser de 64 bits. E então ele vai gerar uma grande saída. Agora, como faz

0:14:15.425,0:14:21.060
realmente funciona? Bem, a própria função é definida como se segue. Basicamente, dado

0:14:21.060,0:14:26.378
chave eo nonce, ele irá gerar um tempo muito longo, bem, pseudorandom uma longa

0:14:26.378,0:14:31.222
sequência, enquanto for necessário. E vai fazê-lo usando essa função que eu vou denotar por

0:14:31.222,0:14:35.653
H. Este H função recebe três entradas. Basicamente a chave. Bem, a semente k,

0:14:35.653,0:14:40.498
o r nonce, e, em seguida, um contador que incrementa a partir do passo a passo. Assim vai

0:14:40.498,0:14:45.263
de zero a um, dois, três, quatro, contanto que inaudível] [ser. Ok? Então, basicamente,

0:14:45.263,0:14:49.956
avaliando este H nesta kr, mas usando este contador incrementar, podemos obter uma

0:14:49.956,0:14:54.882
seqüência que é tão longo como nós queremos. Então, tudo o que tenho a fazer é descrever como esta função

0:14:54.882,0:14:59.460
H funciona. Agora, deixe-me fazer isso aqui para você. O modo como funciona é o seguinte. Bem, nós

0:14:59.460,0:15:04.693
começar pela expansão dos estados em algo muito grande que é de 64 bytes

0:15:04.693,0:15:10.156
longo, e fazemos isso da seguinte forma. Basicamente, manter uma constante no início, de modo

0:15:10.156,0:15:15.552
há tao zero, estes são quatro bytes, é uma de quatro bytes constante, de modo a especificação para

0:15:15.552,0:15:20.611
Salsa, basicamente dá-lhe o valor tao zero. Então nós colocamos k em que é

0:15:20.611,0:15:25.467
bytes dezesseis. Então nós colocamos uma outra constante. Novamente, isto é quatro bytes. E

0:15:25.467,0:15:30.795
como eu disse, a especificação basicamente especifica o que esta constante é fixo. Então nós colocamos

0:15:30.795,0:15:37.435
nonce o que é de oito bytes. Então vamos colocar o índice. Este é o zero do contador,

0:15:37.435,0:15:43.063
um, dois, três, quatro, que é mais oito bytes. Então nós colocamos uma outra constante

0:15:43.063,0:15:49.056
tau dois, que é mais quatro bytes. Então nós colocamos novamente a tecla, este é outro

0:15:49.056,0:15:54.714
bytes dezesseis. E então, finalmente, colocar a terceira constante, tau três, que é

0:15:54.714,0:15:59.948
mais quatro bytes. Ok então, como eu disse, se você somar estes acima, você vê que você tem 64

0:15:59.948,0:16:05.249
bytes. Então, basicamente, nós expandimos a chave eo nonce eo contador em 64

0:16:05.249,0:16:10.886
bytes. Basicamente a chave é repetido duas vezes, eu acho. E então o que fazemos é aplicar uma

0:16:10.886,0:16:16.321
função, eu vou chamar isso de h pouco funcional. Ok, então nós aplicamos essa função, h pouco.

0:16:16.321,0:16:21.659
E esta é uma função que é 12:59 assim que mapeia 64 bytes para 64 bytes. É uma

0:16:21.659,0:16:26.005
função completamente invertida, ok? Portanto, esta função é h, o que eu digo, é uma

0:16:26.005,0:16:30.260
função invertable. Assim, dada a entrada que você pode obter o resultado e dada a

0:16:30.260,0:16:34.906
saída você pode voltar para a entrada. E ele é projetado especificamente por isso é um fácil

0:16:34.906,0:16:39.553
de implementar em hardware e b-on um x86, é extremamente fácil de implementar, porque

0:16:39.553,0:16:44.199
x86 tem este conjunto de instruções SSE2 que suporta todas as operações que você precisa fazer

0:16:44.199,0:16:48.622
para esta função. É muito, muito rápido. Como resultado, salsa tem um fluxo muito rápido

0:16:48.622,0:16:52.764
cifra. E então ele faz isso, basicamente, uma e outra vez. Por isso, aplica-se este

0:16:52.764,0:16:57.744
função h de novo e fica outros 64 bytes. E assim por diante e assim por diante, basicamente

0:16:57.744,0:17:05.318
ele faz isso dez vezes. Ok então a coisa toda aqui, dizer repete dez vezes, de forma

0:17:05.318,0:17:17.961
basicamente aplicar h dez vezes. E, em seguida, por si só, isto não é na verdade muito aleatória.

0:17:17.961,0:17:22.144
Não vai parecer aleatória, pois como dissemos, H é completamente invertable. Portanto, dado

0:17:22.144,0:17:25.521
este resultado final, é muito fácil basta inverter h e depois voltar para o original

0:17:25.521,0:17:31.831
insumos e faça o teste que a de entrada tem a estrutura correta. Então você faz mais um

0:17:31.831,0:17:36.979
coisa, que é basicamente XOR as entradas e as saídas finais. Na verdade,

0:17:36.979,0:17:42.405
pena. Não é um XOR. É realmente uma adição. Então você faz uma palavra além de

0:17:42.405,0:17:47.762
palavra. Então, se existem 64 bytes, você faz uma adição palavra por palavra e quatro bytes de cada

0:17:47.762,0:17:52.980
tempo e, finalmente, chegar a saída 64-byte, e é isso. Esse é o todo

0:17:52.980,0:17:57.175
gerador pseudo-aleatório. Então, isso, isso é toda a função, h pouco. E como eu

0:17:57.175,0:18:01.758
explicou, esta construção inteira aqui é a grande função H. E então você avaliar

0:18:01.758,0:18:06.009
H grande, incrementando o I contador de zero, um, dois, três em diante. E isso

0:18:06.009,0:18:10.408
lhe dará uma seqüência pseudo-aleatório que é o tempo que você precisa que ele seja. E

0:18:10.408,0:18:15.325
basicamente, não há ataques signifigant sobre isso. Isto tem a segurança que é

0:18:15.325,0:18:20.371
muito perto de duas para o 128. Vamos ver o que isso significa mais precisamente mais tarde.

0:18:20.371,0:18:25.417
É uma cifra de fluxo muito rápido, tanto em hardware e em software. E, na medida do

0:18:25.417,0:18:30.431
podemos dizer, parece ser imprevisível como necessário para uma cifra de fluxo. Então, eu

0:18:30.431,0:18:34.797
deve dizer que o projeto eSTREAM realmente tem cinco cifras de fluxo como

0:18:34.797,0:18:39.395
presente. Eu só escolhi Salsa porque eu acho que é o mais elegante. Mas posso dar-lhe

0:18:39.395,0:18:44.053
alguns números desempenho aqui. Assim você pode ver, estes são os números de desempenho em um

0:18:44.053,0:18:48.768
gigahertz 2.2, você sabe, tipo de máquina x86. E você pode ver que na verdade é o RC4

0:18:48.768,0:18:53.017
mais lento. Porque, essencialmente, bem, realmente não tirar proveito da

0:18:53.017,0:18:57.475
hardware. Ele só faz operações de byte. E por isso há uma grande quantidade de ciclos de desperdício que

0:18:57.475,0:19:01.182
não estão sendo utilizados. Mas os candidatos E-Stream, tanto Salsa e outros

0:19:01.182,0:19:05.202
candidato chamado Sosemanuk. Devo dizer que estes são finalistas eSTREAM. Estes são

0:19:05.202,0:19:09.588
realmente fluxo cifras que são aprovados pelo projeto eSTREAM. Você pode ver que

0:19:09.588,0:19:13.712
de terem atingido uma taxa significativa. Esta é a 643 megabytes por segundo nesta

0:19:13.712,0:19:18.150
arquitetura, mais do que suficiente para um filme e estas são realmente muito impressionante

0:19:18.150,0:19:22.432
taxas. E agora que você já viu exemplos de duas cifras de fluxo antigos que não devem ser

0:19:22.432,0:19:26.661
utilizado, incluindo ataques a essas cifras de fluxo. Você viu o que as cifras de fluxo modernos

0:19:26.661,0:19:30.480
parecido com este nonce. E você vê os números de desempenho para estes

0:19:30.480,0:19:34.546
fluxo cifras modernas por isso, se acontecer de você precisar de uma cifra de fluxo, você poderia usar um dos

0:19:34.546,0:19:37.991
os finalistas eSTREAM. Em particular, você poderia usar algo como Salsa.