WEBVTT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

00:05:18.541 --> 00:05:23.460
, basicamente, é o estado inicial do LFSR.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

00:06:57.669 --> 00:07:02.947
chave. E esse é o estado inicial do LFSR.

00:07:02.947 --> 00:07:08.256
E então o segundo LFSR basicamente é intitialized da mesma maneira.

00:07:08.256 --> 00:07:14.012
Uma concatenado os últimos três bytes da chave. E isso é

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

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

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

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

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

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

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

00:07:54.325 --> 00:07:59.723
bloco anterior. Mas isso não é tão importante. Isso é um detalhe que não é tão

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

00:12:08.340 --> 00:12:12.821
chamado nonce e vamos ver o que é um nonce é usada em apenas um minuto. Assim

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

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

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

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

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

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

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

00:12:45.357 --> 00:12:49.955
PRG toma como entrada tanto a chave eo nonce. E a propriedade do nonce é

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

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

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

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

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

00:13:21.541 --> 00:13:26.000
exemplo do eSTREAM que eu quero lhe mostrar é chamado Salsa 20. É uma

00:13:26.000 --> 00:13:30.292
cifra de fluxo que é projetado para implementações de software e hardware

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

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

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

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

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

00:13:50.963 --> 00:13:55.008
projetado de modo que seja fácil de implementar em hardware e seu software

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

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

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

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

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

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

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

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

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

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

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

00:14:49.956 --> 00: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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

00:18:30.431 --> 00:18:34.797
deve dizer que o projeto eSTREAM realmente tem cinco cifras de fluxo como

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

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

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

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

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

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

00:19:01.182 --> 00:19:05.202
candidato chamado Sosemanuk. Devo dizer que estes são finalistas eSTREAM. Estes são

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

00:19:09.588 --> 00:19:13.712
de terem atingido uma taxa significativa. Esta é a 643 megabytes por segundo nesta

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

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

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

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

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

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