< Return to Video

cifras do mundo real de fluxo (20 min)

  • 0:00 - 0:04
    Neste segmento, eu quero dar alguns exemplos de fluxo cifras que são usados na prática.
  • 0:04 - 0:07
    Vou começar com dois exemplos antigos que na verdade não são
  • 0:07 - 0:11
    suposto ser usado em sistemas novos. Mas, no entanto, eles ainda são bastante
  • 0:11 - 0:14
    amplamente utilizada, e assim que eu apenas quero mencionar os nomes para que você esteja familiarizado com
  • 0:14 - 0:19
    esses conceitos. A cifra de fluxo primeiro eu quero falar é chamado RC4, projetado
  • 0:19 - 0:23
    em 1987. E eu só vou te dar a descrição de alto nível e, em seguida
  • 0:23 - 0:28
    nós vamos falar sobre alguns pontos fracos do RC4 e deixar por isso mesmo. Assim RC4 leva um
  • 0:28 - 0:33
    sementes de tamanho variável, aqui eu só dei como um exemplo onde levaria 128
  • 0:33 - 0:37
    bits como o tamanho das sementes, que passaria então a ser utilizados como chave para a cifra de fluxo.
  • 0:37 - 0:42
    A primeira coisa que faz, é que se expande a chave de 128-bit segredo em 2.048 bits, que
  • 0:42 - 0:46
    vão ser usados como o estado interno para o gerador. E então, quando ele é feito
  • 0:46 - 0:51
    esta expansão, que basicamente executa um laço muito simples, onde cada iteração do
  • 0:51 - 0:56
    laço Isso gera um byte de saída. Então, basicamente, você pode executar o gerador de
  • 0:56 - 1:01
    , enquanto você quer, e gerar um byte de cada vez. Agora RC4 é, na verdade, como eu disse,
  • 1:01 - 1:05
    bastante popular. É usado no protocolo HTTPS é bastante comum, na verdade.
  • 1:05 - 1:12
    Estes dias, por exemplo, o Google usa RC4 em suas HTTPS. Também é usado no WEP como nós
  • 1:12 - 1:16
    discutido no último segmento, mas é claro que no WEP, ele é usado incorretamente e
  • 1:16 - 1:19
    é completamente inseguro da forma como ele é usado dentro do WEP. Assim, ao longo dos anos,
  • 1:19 - 1:24
    algumas deficiências foram encontradas no RC4, e como resultado, é recomendado que os novos projetos
  • 1:24 - 1:29
    na verdade não usar RC4, mas sim usar um mais moderno gerador pseudo-aleatório como veremos
  • 1:29 - 1:34
    discutir para a extremidade do segmento. Então deixe-me mencionar apenas dois dos pontos fracos.
  • 1:34 - 1:40
    Então a primeira é que é tipo de bizarra, basicamente, se você olhar para o segundo byte
  • 1:40 - 1:45
    da produção de RC4. Acontece que o segundo byte é um pouco tendencioso. Se RC4 foi
  • 1:45 - 1:50
    completamente aleatória, a probabilidade de que o segundo byte acontece ser igual a zero
  • 1:50 - 1:55
    seria exatamente um sobre 256. Existem 256 bytes possíveis, a probabilidade que
  • 1:55 - 2:00
    zero, deveria ser um sobre 256. Acontece que para RC4 a probabilidade é
  • 2:00 - 2:04
    realmente dois por 256, o que significa que se você usar a saída RC4 para criptografar uma
  • 2:04 - 2:10
    mensagem do segundo byte é provável que não seja encriptada de todo. Em outras palavras, ele vai
  • 2:10 - 2:15
    ser XOR-ed com zero com o dobro da probabilidade de que é suposto.
  • 2:15 - 2:19
    Assim, dois sobre 256, em vez de um sobre 256. E pelo jeito que eu deveria dizer que há
  • 2:19 - 2:23
    nada de especial sobre o segundo byte. Acontece que a primeira e os bytes terceiros
  • 2:23 - 2:28
    também são tendenciosos. E de fato ele é agora recomendado que se você vai usar RC4,
  • 2:28 - 2:33
    que você deve fazer é ignorar, basicamente, os primeiros 256 bytes da saída e apenas
  • 2:33 - 2:37
    começar a utilizar a saída do gerador a partir de byte 257. O primeiro casal
  • 2:37 - 2:41
    de bytes acabou por ser tendencioso, então você simplesmente ignorá-los. O segundo ataque que
  • 2:41 - 2:48
    foi descoberto é que de fato se você olhar para uma saída muito longo de RC4 que acontece
  • 2:48 - 2:54
    que você é mais provável conseguir o 00 de seqüência. Em outras palavras, você é mais
  • 2:54 - 2:59
    probabilidade de obter dezesseis bits, dois bytes de zero, zero, do que deveria. Novamente, se RC4
  • 2:59 - 3:04
    foi completamente aleatória a probabilidade de ver zero, zero seria exatamente 1/256
  • 3:04 - 3:09
    quadrado. Acontece RC4 é um pouco tendencioso eo viés é 1/256 cubos. Ele
  • 3:09 - 3:14
    Acontece que este viés realmente começa depois de vários gigabytes de dados são produzidos por
  • 3:14 - 3:19
    RC4. Mas, no entanto, este é algo que pode ser utilizado para prever o gerador
  • 3:19 - 3:23
    e, definitivamente, ele pode ser usado para distinguir a saída do gerador
  • 3:23 - 3:28
    partir de uma seqüência verdadeiramente aleatória. Basicamente o fato de que zero, zero aparece com mais freqüência
  • 3:28 - 3:32
    do que deveria é o Distinguisher. E então, no último segmento que falamos
  • 3:32 - 3:36
    relacionado-chave ataques que foram usados para atacar WEP, que basicamente dizem que
  • 3:36 - 3:41
    se teclas de um utilizações que estão intimamente relacionadas entre si, então é realmente possível
  • 3:41 - 3:46
    para recuperar a chave raiz. Assim, estes são os pontos fracos que são conhecidos de RC4 e, como um
  • 3:46 - 3:50
    resultado, é recomendado que os novos sistemas não realmente usar RC4 e utilizar um
  • 3:50 - 3:54
    gerador pseudo-aleatório moderna. Ok, segundo exemplo que quero dar-lhe é um
  • 3:54 - 3:59
    cifra de fluxo gravemente quebrado que é usada para criptografar filmes em DVD. Quando você compra um DVD
  • 3:59 - 4:04
    na loja, o próprio filme é criptografada usando uma cifra de fluxo chamado de
  • 4:04 - 4:08
    Content Scrambling System, CSS. CSS acaba por ser uma cifra de fluxo gravemente quebrado
  • 4:08 - 4:13
    e podemos muito facilmente quebrá-lo, e eu quero mostrar-lhe como o algoritmo de ataque
  • 4:13 - 4:17
    obras. Estamos fazendo isso para que você possa ver um exemplo de um algoritmo de ataque, mas em
  • 4:17 - 4:21
    verdade, existem muitos sistemas por aí que, basicamente, usar este ataque para descriptografar
  • 4:21 - 4:26
    DVDs criptografados. Assim, a cifra de fluxo CSS é baseada em algo que o hardware
  • 4:26 - 4:30
    projetistas gosta. Ele foi projetado para ser uma cifra de fluxo de hardware que é suposto
  • 4:30 - 4:34
    ser fácil de implementar em hardware, e baseia-se um mecanismo chamado linear
  • 4:34 - 4:39
    mudança comentários registar. Assim, um registrador de deslocamento linear feedback é basicamente um registo
  • 4:39 - 4:44
    que consiste em células em que cada célula contém um bit. Então, basicamente,
  • 4:44 - 4:49
    que acontece é que existem estas torneiras em certas células, não todas as células, certos
  • 4:49 - 4:54
    posições são chamados torneiras. E então essas torneiras alimentar em um XOR e, em seguida, em
  • 4:54 - 4:59
    cada ciclo de clock, o registrador de deslocamento desloca para a esquerda. O último pedaço cair
  • 4:59 - 5:04
    e, em seguida, o primeiro bit torna-se o resultado deste XOR. Assim você pode ver que
  • 5:04 - 5:09
    este é um mecanismo muito simples de implementar, e em hardware tem muito poucos
  • 5:09 - 5:14
    transistores. Apenas o deslocamento para a direita, o último bit cai e apenas o primeiro bit
  • 5:14 - 5:19
    torna-se o XOR dos bits anteriores. Assim, a semente para este LFSR
  • 5:19 - 5:23
    , basicamente, é o estado inicial do LFSR.
  • 5:24 - 5:29
    E é a base de uma série de codificações de fluxo. Então, aqui estão alguns exemplos. Assim, como
  • 5:29 - 5:33
    eu disse, a criptografia utiliza duas LFSRs DVD. Eu vou te mostrar como isso funciona em apenas um
  • 5:33 - 5:38
    segundo. Criptografia GSM, estes são chamados algoritmos A51 e A52. E isso
  • 5:38 - 5:43
    utiliza três LFSRs. Criptografia Bluetooth é um algoritmo chamado, E zero. Estes são todos
  • 5:43 - 5:49
    cifras de fluxo, e que utiliza quatro LFSRs. Acontece que todos eles são gravemente quebrado
  • 5:49 - 5:53
    e na verdade realmente não deve ser confiável para criptografar o tráfego, mas todos eles são
  • 5:53 - 5:57
    implementado em hardware, por isso é um pouco difícil agora para mudar o que o hardware
  • 5:57 - 6:01
    faz. Mas o mais simples deles, CSS, na verdade, tem um ataque bonito nele, então vamos
  • 6:01 - 6:05
    me mostrar-lhe como o ataque funciona. Então, vamos descrever como o CSS realmente funciona. Assim,
  • 6:05 - 6:11
    chave para o CSS é de cinco bytes, ou seja, 40 bits, cinco vezes oito é de 40 bits. O
  • 6:11 - 6:16
    razão eles tinham que se limitar a apenas 40 bits é que a criptografia do DVD foi
  • 6:16 - 6:20
    concebidos numa altura em que os regulamentos de exportação dos Estados Unidos só é permitido para a exportação de
  • 6:20 - 6:25
    algoritmos crpyto onde estava a chave apenas 40 bits. Assim, os designers de CSS foram
  • 6:25 - 6:30
    já limitados a chaves muito, muito curtos. Apenas 40 teclas bit. Assim, seu projeto trabalha
  • 6:30 - 6:35
    como se segue. Basicamente, o CSS usa duas LFSR do. Um é um LFSR de 17-bit. Em outras palavras,
  • 6:35 - 6:41
    registo a contém 17 bits. Eo outro é um LFSR 25-bit,
  • 6:41 - 6:47
    é um pouco mais, 25 bits LFSR. E a forma como estas são semeadas LFSRs
  • 6:47 - 6:52
    é como se segue. Portanto, a chave para a criptografia, basicamente, tem a seguinte aparência.
  • 6:52 - 6:58
    Você começa com um, e você concatenar a ele os dois primeiros bytes de
  • 6:58 - 7:03
    chave. E esse é o estado inicial do LFSR.
  • 7:03 - 7:08
    E então o segundo LFSR basicamente é intitialized da mesma maneira.
  • 7:08 - 7:14
    Uma concatenado os últimos três bytes da chave. E isso é
  • 7:14 - 7:20
    carregado para o estado inicial do LFSR. Você pode ver que os dois primeiros bytes são
  • 7:20 - 7:25
    16 bits, mais um líder, que tem dezessete pedaços geral, enquanto o segundo
  • 7:25 - 7:31
    LFSR é de 24 bits, mais um que é de 25 bits. E você percebe usamos todos os cinco pedaços de
  • 7:31 - 7:37
    chave. Então essas são basicamente LFSRs correr para oito ciclos, de modo que elas geram
  • 7:37 - 7:42
    oito bits de saída. E então eles passam por este componente que faz basicamente
  • 7:42 - 7:48
    adição módulo 256. É assim que esta é uma caixa disso, módulo 256. Há mais uma
  • 7:48 - 7:54
    coisa técnica que acontece. Na verdade vamos realmente, também adicionada é o transporte do
  • 7:54 - 8:00
    bloco anterior. Mas isso não é tão importante. Isso é um detalhe que não é tão
  • 8:00 - 8:05
    relevante. OK, então todos os blocos, você percebe que estamos fazendo além modulo 256 e
  • 8:05 - 8:10
    estamos ignorando o transporte, mas o transporte é basicamente adicionado como um zero ou um um ao
  • 8:10 - 8:15
    além do bloco seguinte. Ok? E então, basicamente, esta saída um byte por round.
  • 8:15 - 8:20
    Ok, e então este byte é usado, então é claro, XOR-ed com o adequado
  • 8:20 - 8:25
    byte do filme que está sendo criptografado. Ok, então é um fluxo muito simples
  • 8:25 - 8:30
    cifra, é preciso hardware muito pouco para implementar. Ele irá correr rápido, mesmo em muito
  • 8:30 - 8:36
    hardware barato e vai criptografar filmes. Então, acontece que este é fácil de quebrar
  • 8:36 - 8:41
    no tempo cerca de dois a 17. Agora deixe-me mostrar-lhe como.
  • 8:41 - 8:46
    Então, suponha que você interceptar os filmes, então aqui nós temos um
  • 8:46 - 8:51
    filme criptografado que você deseja descriptografar. Então, digamos que tudo isso é criptografado para
  • 8:51 - 8:55
    você não tem idéia do que está dentro de aqui. No entanto, acontece que só porque
  • 8:55 - 9:00
    criptografia DVD está usando arquivos MPEG, acontece se você souber de um prefixo da
  • 9:00 - 9:04
    texto simples, vamos apenas dizer que talvez esta é de vinte bytes. Bem, sabemos que se você
  • 9:04 - 9:09
    XOR essas duas coisas juntas, então, em outras palavras, você faz o XOR aqui,
  • 9:09 - 9:14
    que você vai conseguir é o segmento inicial do PRG. Assim, você terá a
  • 9:14 - 9:18
    primeiros vinte bytes de a saída do CSS, a saída do presente PRG. Ok, então agora
  • 9:18 - 9:24
    aqui é o que nós vamos fazer. Assim, temos os primeiros vinte bytes de saída. Agora
  • 9:24 - 9:31
    nós fazemos o seguinte. Nós experimentar todos dois para os valores possíveis de 17 a primeira
  • 9:31 - 9:37
    LFSR. Ok? Assim, duas aos dezassete valores possíveis. Assim, para cada valor, portanto, para
  • 9:37 - 9:43
    cada um destes dois aos dezassete valores iniciais do LFSR, vamos executar o
  • 9:43 - 9:48
    LFSR por vinte bytes, ok? Então, vamos gerar de vinte bytes de saídas a partir deste
  • 9:48 - 9:53
    LFSR primeiro, assumindo-para cada um dos dois para os dezassete configurações possíveis.
  • 9:53 - 9:59
    Agora, lembre-se que temos o resultado completo do sistema de CSS. Então o que podemos fazer é nos
  • 9:59 - 10:04
    pode tomar esta saída que temos. E subtrair os vinte mordidas que nós
  • 10:04 - 10:09
    obtido a partir do LFSR primeiro, e se de fato o nosso palpite para o estado inicial do primeiro
  • 10:09 - 10:14
    LFSR está correta, o que devemos começar é a saída 20-primeiro byte do
  • 10:14 - 10:19
    LFSR segundo. Certo? Porque isso é, por definição, o que a saída do CSS
  • 10:19 - 10:25
    sistema é. Agora, descobre-se que olhar para uma seqüência de 20 bytes, é muito fácil
  • 10:25 - 10:30
    dizer se essa seqüência de 20-byte veio de um LFSR 25-bit ou não. Se
  • 10:30 - 10:34
    não, então sabemos que o nosso palpite para o LFSR 17-bit foi
  • 10:34 - 10:37
    incorreto e, em seguida, passamos para o próximo palpite para o LFSR 17-bit e
  • 10:37 - 10:42
    suposição o seguinte e assim por diante e assim por diante. Até que finalmente chegamos ao direito inicial
  • 10:42 - 10:47
    estado para o LFSR 17-bit, e depois vamos realmente começar, vamos ver que
  • 10:47 - 10:52
    os 20 bytes que obtemos como a saída candidato para o LFSR 25-bit é
  • 10:52 - 10:57
    , de facto, uma saída possível para um LFSR 25-bit. E então, não só teremos
  • 10:57 - 11:02
    aprendeu o estado inicial correto para o LFSR 17-bit, nós também teremos
  • 11:02 - 11:08
    aprendeu o estado inicial correto do LFSR 25-bit. E então podemos prever o
  • 11:08 - 11:13
    saídas restantes do CSS, e é claro, usar isso, podemos, então, decifrar o resto
  • 11:13 - 11:18
    o filme. Na verdade, podemos recuperar o texto restante. Okay. Isto é
  • 11:18 - 11:22
    coisas que falamos antes. Então, eu disse isso um pouco rápido, mas espero que,
  • 11:22 - 11:27
    ficou claro. Nós também vamos estar fazendo um exercício de dever de casa neste tipo de fluxo
  • 11:27 - 11:31
    cifras e você vai espécie de chegar ao ponto de como esses algoritmos de ataque
  • 11:31 - 11:36
    trabalho. E devo mencionar que existem muitos sistemas open-source, agora que realmente
  • 11:36 - 11:41
    usar esse método para descriptografar CSS dados criptografados. Ok, então agora que já vimos dois
  • 11:41 - 11:46
    fracos exemplos, vamos passar para exemplos melhores, e em particular o melhor
  • 11:46 - 11:49
    pseudo-aleatórios geradores vêm do que é chamado de Projeto eSTREAM. Esta é uma
  • 11:49 - 11:56
    projeto que concluiu em 2008, e que se qualifiquem, basicamente, cinco fluxo diferente
  • 11:56 - 12:00
    cifras, mas aqui quero apresentar apenas um. Então, primeiro de todos os parâmetros para
  • 12:00 - 12:04
    essas cifras de fluxo é um pouco diferente do que estamos acostumados. Então, essas
  • 12:04 - 12:08
    fluxo cifras normalmente eles têm uma semente. Mas, além disso eles também têm, o que é
  • 12:08 - 12:13
    chamado nonce e vamos ver o que é um nonce é usada em apenas um minuto. Assim
  • 12:13 - 12:17
    tomam duas entradas de uma semente e um nonce. Vamos ver o que o nonce é usada no
  • 12:17 - 12:21
    apenas um segundo. E claro que o de produzir uma saída muito grande, então n é aqui
  • 12:21 - 12:27
    muito, muito, muito maior do que s. Agora, quando eu digo nonce, o que quero dizer é um valor que é
  • 12:27 - 12:31
    nunca indo para repetir enquanto a chave é fixo. E eu vou explicar isso em mais
  • 12:31 - 12:35
    detalhe em apenas um segundo. Mas, por agora, basta pensar nisso como um valor único que nunca
  • 12:35 - 12:41
    repete, desde que a chave é a mesma. E então é claro que quando você tem este PRG,
  • 12:41 - 12:45
    você criptografar, você obtém uma cifra de fluxo tal como antes, só que agora como você vê, o
  • 12:45 - 12:50
    PRG toma como entrada tanto a chave eo nonce. E a propriedade do nonce é
  • 12:50 - 12:56
    que o par, k vírgula r, de modo a vírgula chave nonce, é nunca, nunca se repete. É
  • 12:56 - 13:03
    nunca usou mais de uma vez. Assim a linha inferior é que você pode reutilizar a chave, reutilizar
  • 13:03 - 13:10
    a chave, porque o uso único faz com que o par único, porque K e R são apenas
  • 13:10 - 13:16
    usado uma vez. Eu vou dizer que é único. Ok então este nonce é uma espécie de truque bonito que
  • 13:16 - 13:22
    nos salva a dificuldade de se mudar para uma nova chave de cada vez. Ok, então o particular
  • 13:22 - 13:26
    exemplo do eSTREAM que eu quero lhe mostrar é chamado Salsa 20. É uma
  • 13:26 - 13:30
    cifra de fluxo que é projetado para implementações de software e hardware
  • 13:30 - 13:33
    implementações. É uma espécie de interessante. Você percebe que algumas cifras de fluxo são
  • 13:33 - 13:39
    projetado para software, como RC4. Tudo que ele faz é projetado para fazer
  • 13:39 - 13:43
    implementação de software de correr rápido, enquanto o fluxo cifras outros são projetados para
  • 13:43 - 13:48
    hardware, como CSS, utilizando um LFSR que está particularmente desenhado para fazer hardware
  • 13:48 - 13:51
    implementações muito baratos. É também, a única coisa boa disso é que é
  • 13:51 - 13:55
    projetado de modo que seja fácil de implementar em hardware e seu software
  • 13:55 - 14:00
    implementação também é muito rápido. Então deixe-me explicar como Salsa obras. Bem, Salsa
  • 14:00 - 14:05
    leva ou 128 ou 256-bit chaves. Eu só vou explicar a versão de 128 bits do Salsa.
  • 14:05 - 14:11
    Então esta é a semente. E então ele também leva um nonce, tal como antes, que
  • 14:11 - 14:15
    passa a ser de 64 bits. E então ele vai gerar uma grande saída. Agora, como faz
  • 14:15 - 14:21
    realmente funciona? Bem, a própria função é definida como se segue. Basicamente, dado
  • 14:21 - 14:26
    chave eo nonce, ele irá gerar um tempo muito longo, bem, pseudorandom uma longa
  • 14:26 - 14:31
    sequência, enquanto for necessário. E vai fazê-lo usando essa função que eu vou denotar por
  • 14:31 - 14:36
    H. Este H função recebe três entradas. Basicamente a chave. Bem, a semente k,
  • 14:36 - 14:40
    o r nonce, e, em seguida, um contador que incrementa a partir do passo a passo. Assim vai
  • 14:40 - 14:45
    de zero a um, dois, três, quatro, contanto que inaudível] [ser. Ok? Então, basicamente,
  • 14:45 - 14:50
    avaliando este H nesta kr, mas usando este contador incrementar, podemos obter uma
  • 14:50 - 14:55
    seqüência que é tão longo como nós queremos. Então, tudo o que tenho a fazer é descrever como esta função
  • 14:55 - 14:59
    H funciona. Agora, deixe-me fazer isso aqui para você. O modo como funciona é o seguinte. Bem, nós
  • 14:59 - 15:05
    começar pela expansão dos estados em algo muito grande que é de 64 bytes
  • 15:05 - 15:10
    longo, e fazemos isso da seguinte forma. Basicamente, manter uma constante no início, de modo
  • 15:10 - 15:16
    há tao zero, estes são quatro bytes, é uma de quatro bytes constante, de modo a especificação para
  • 15:16 - 15:21
    Salsa, basicamente dá-lhe o valor tao zero. Então nós colocamos k em que é
  • 15:21 - 15:25
    bytes dezesseis. Então nós colocamos uma outra constante. Novamente, isto é quatro bytes. E
  • 15:25 - 15:31
    como eu disse, a especificação basicamente especifica o que esta constante é fixo. Então nós colocamos
  • 15:31 - 15:37
    nonce o que é de oito bytes. Então vamos colocar o índice. Este é o zero do contador,
  • 15:37 - 15:43
    um, dois, três, quatro, que é mais oito bytes. Então nós colocamos uma outra constante
  • 15:43 - 15:49
    tau dois, que é mais quatro bytes. Então nós colocamos novamente a tecla, este é outro
  • 15:49 - 15:55
    bytes dezesseis. E então, finalmente, colocar a terceira constante, tau três, que é
  • 15:55 - 16:00
    mais quatro bytes. Ok então, como eu disse, se você somar estes acima, você vê que você tem 64
  • 16:00 - 16:05
    bytes. Então, basicamente, nós expandimos a chave eo nonce eo contador em 64
  • 16:05 - 16:11
    bytes. Basicamente a chave é repetido duas vezes, eu acho. E então o que fazemos é aplicar uma
  • 16:11 - 16:16
    função, eu vou chamar isso de h pouco funcional. Ok, então nós aplicamos essa função, h pouco.
  • 16:16 - 16:22
    E esta é uma função que é 12:59 assim que mapeia 64 bytes para 64 bytes. É uma
  • 16:22 - 16:26
    função completamente invertida, ok? Portanto, esta função é h, o que eu digo, é uma
  • 16:26 - 16:30
    função invertable. Assim, dada a entrada que você pode obter o resultado e dada a
  • 16:30 - 16:35
    saída você pode voltar para a entrada. E ele é projetado especificamente por isso é um fácil
  • 16:35 - 16:40
    de implementar em hardware e b-on um x86, é extremamente fácil de implementar, porque
  • 16:40 - 16:44
    x86 tem este conjunto de instruções SSE2 que suporta todas as operações que você precisa fazer
  • 16:44 - 16:49
    para esta função. É muito, muito rápido. Como resultado, salsa tem um fluxo muito rápido
  • 16:49 - 16:53
    cifra. E então ele faz isso, basicamente, uma e outra vez. Por isso, aplica-se este
  • 16:53 - 16:58
    função h de novo e fica outros 64 bytes. E assim por diante e assim por diante, basicamente
  • 16:58 - 17:05
    ele faz isso dez vezes. Ok então a coisa toda aqui, dizer repete dez vezes, de forma
  • 17:05 - 17:18
    basicamente aplicar h dez vezes. E, em seguida, por si só, isto não é na verdade muito aleatória.
  • 17:18 - 17:22
    Não vai parecer aleatória, pois como dissemos, H é completamente invertable. Portanto, dado
  • 17:22 - 17:26
    este resultado final, é muito fácil basta inverter h e depois voltar para o original
  • 17:26 - 17:32
    insumos e faça o teste que a de entrada tem a estrutura correta. Então você faz mais um
  • 17:32 - 17:37
    coisa, que é basicamente XOR as entradas e as saídas finais. Na verdade,
  • 17:37 - 17:42
    pena. Não é um XOR. É realmente uma adição. Então você faz uma palavra além de
  • 17:42 - 17:48
    palavra. Então, se existem 64 bytes, você faz uma adição palavra por palavra e quatro bytes de cada
  • 17:48 - 17:53
    tempo e, finalmente, chegar a saída 64-byte, e é isso. Esse é o todo
  • 17:53 - 17:57
    gerador pseudo-aleatório. Então, isso, isso é toda a função, h pouco. E como eu
  • 17:57 - 18:02
    explicou, esta construção inteira aqui é a grande função H. E então você avaliar
  • 18:02 - 18:06
    H grande, incrementando o I contador de zero, um, dois, três em diante. E isso
  • 18:06 - 18:10
    lhe dará uma seqüência pseudo-aleatório que é o tempo que você precisa que ele seja. E
  • 18:10 - 18:15
    basicamente, não há ataques signifigant sobre isso. Isto tem a segurança que é
  • 18:15 - 18:20
    muito perto de duas para o 128. Vamos ver o que isso significa mais precisamente mais tarde.
  • 18:20 - 18:25
    É uma cifra de fluxo muito rápido, tanto em hardware e em software. E, na medida do
  • 18:25 - 18:30
    podemos dizer, parece ser imprevisível como necessário para uma cifra de fluxo. Então, eu
  • 18:30 - 18:35
    deve dizer que o projeto eSTREAM realmente tem cinco cifras de fluxo como
  • 18:35 - 18:39
    presente. Eu só escolhi Salsa porque eu acho que é o mais elegante. Mas posso dar-lhe
  • 18:39 - 18:44
    alguns números desempenho aqui. Assim você pode ver, estes são os números de desempenho em um
  • 18:44 - 18:49
    gigahertz 2.2, você sabe, tipo de máquina x86. E você pode ver que na verdade é o RC4
  • 18:49 - 18:53
    mais lento. Porque, essencialmente, bem, realmente não tirar proveito da
  • 18:53 - 18:57
    hardware. Ele só faz operações de byte. E por isso há uma grande quantidade de ciclos de desperdício que
  • 18:57 - 19:01
    não estão sendo utilizados. Mas os candidatos E-Stream, tanto Salsa e outros
  • 19:01 - 19:05
    candidato chamado Sosemanuk. Devo dizer que estes são finalistas eSTREAM. Estes são
  • 19:05 - 19:10
    realmente fluxo cifras que são aprovados pelo projeto eSTREAM. Você pode ver que
  • 19:10 - 19:14
    de terem atingido uma taxa significativa. Esta é a 643 megabytes por segundo nesta
  • 19:14 - 19:18
    arquitetura, mais do que suficiente para um filme e estas são realmente muito impressionante
  • 19:18 - 19:22
    taxas. E agora que você já viu exemplos de duas cifras de fluxo antigos que não devem ser
  • 19:22 - 19:27
    utilizado, incluindo ataques a essas cifras de fluxo. Você viu o que as cifras de fluxo modernos
  • 19:27 - 19:30
    parecido com este nonce. E você vê os números de desempenho para estes
  • 19:30 - 19:35
    fluxo cifras modernas por isso, se acontecer de você precisar de uma cifra de fluxo, você poderia usar um dos
  • 19:35 - 19:38
    os finalistas eSTREAM. Em particular, você poderia usar algo como Salsa.
Title:
cifras do mundo real de fluxo (20 min)
Video Language:
English
erickshowplay added a translation

Portuguese, Brazilian subtitles

Revisions