Como escolher um modo de criptografia AES (CBC ECB CTR OCB CFB)?


480

Quais deles são preferidos em quais circunstâncias?

Gostaria de ver a lista de critérios de avaliação para os vários modos e talvez uma discussão sobre a aplicabilidade de cada critério.

Por exemplo, acho que um dos critérios é "tamanho do código" para criptografia e descriptografia, o que é importante para sistemas incorporados por microcódigo, como adaptadores de rede 802.11. Se o código necessário para implementar a CBC for muito menor do que o necessário para a CTR (não sei se isso é verdade, é apenas um exemplo), então eu poderia entender por que o modo com o código menor seria preferido. Mas se estou escrevendo um aplicativo que é executado em um servidor, e a biblioteca AES que estou usando implementa CBC e CTR de qualquer maneira, esse critério é irrelevante.

Veja o que quero dizer com "lista de critérios de avaliação e aplicabilidade de cada critério"?

Isso não é realmente relacionado à programação, mas é relacionado ao algoritmo.


22
"Isso não é realmente relacionado à programação, mas é relacionado ao algoritmo." ∵ algoritmos podem ser representados pela matemática. Programming a programação de computadores pode ser apresentada por matemática. ∴ sua pergunta é sobre programação de computadores.
Tyler Gillies

41
"Isso não é realmente relacionado à programação, mas é relacionado ao algoritmo." ∵ algoritmos podem ser representados pela matemática, e os mercados de ações podem ser representados pela matemática, sua pergunta é sobre mercados de ações. / pena do sarcasmo, mas enquanto a conclusão foi muito obviamente direita, o argumento era muito obviamente errado
Shien

Depende da compreensão dos relacionamentos nos quais você se inscreve. Algo não precisa necessariamente estar relacionado apenas a um conceito ou a outro.
Bryan Graça

Respostas:


325
  • O BCE não deve ser usado se criptografar mais de um bloco de dados com a mesma chave.

  • CBC, OFB e CFB são semelhantes; no entanto, OFB / CFB é melhor porque você só precisa de criptografia e não descriptografia, o que pode economizar espaço no código.

  • A CTR é usada se você deseja uma boa paralelização (ou seja, velocidade), em vez de CBC / OFB / CFB.

  • O modo XTS é o mais comum se você estiver codificando dados acessíveis aleatoriamente (como um disco rígido ou RAM).

  • O OCB é de longe o melhor modo, pois permite criptografia e autenticação em uma única passagem. No entanto, existem patentes nos EUA.

A única coisa que você realmente precisa saber é que o BCE não deve ser usado, a menos que você esteja criptografando apenas 1 bloco. O XTS deve ser usado se você estiver criptografando dados acessados ​​aleatoriamente e não um fluxo.

  • Você SEMPRE deve usar IV 's exclusivos toda vez que criptografar, e eles devem ser aleatórios . Se você não pode garantir que eles sejam aleatórios , use o OCB, pois requer apenas um nonce , não um IV , e há uma diferença distinta. Um nonce não descarta a segurança se as pessoas puderem adivinhar o próximo, um IV pode causar esse problema.

65
CBC, OFB e CFB estão longe de serem idênticos.
Jonathan Leffler

22
A CTR é passível de paralelização porque você pode dividir a mensagem em partes, cada parte tendo um intervalo de valores de contador associados a ela e criptografar (ou descriptografar) cada parte independentemente. Por outro lado, o CFB conta com a saída do bloco anterior como uma das entradas para a próxima, portanto, é rigorosamente seqüencial e inerentemente não paralelizável. Semelhante para os outros modos mencionados.
Jonathan Leffler

9
Mesmo se você estiver criptografando apenas um bloco, o BCE não deve ser usado se você estiver criptografando esse bloco mais de uma vez (e possivelmente mais de uma vez) com a mesma chave.
yfeldblum

23
... como uma resposta que diz "CBC, OFB e CFB são idênticas" não tem um único voto negativo?
Michael Mrozek

30
O GCM é muito semelhante ao OCB (desempenho e outras propriedades), mas não é onerado por nenhuma patente, por isso é a melhor escolha. A única desvantagem é o fato de a implementação ser altamente complexa - mas você não precisa se preocupar com isso se usar uma biblioteca.
Ntskrnl

409

Por favor, considere demorado e difícil se você não consegue implementar sua própria criptografia

A verdade feia da questão é que, se você estiver fazendo essa pergunta, provavelmente não poderá projetar e implementar um sistema seguro.

Deixe-me ilustrar meu argumento: imagine que você está construindo um aplicativo da Web e precisa armazenar alguns dados da sessão. Você pode atribuir a cada usuário um ID de sessão e armazenar os dados da sessão no servidor em um ID de sessão de mapeamento de mapa de hash para os dados da sessão. Mas então você tem que lidar com esse estado desagradável no servidor e, em algum momento, precisar de mais de um servidor, tudo ficará confuso. Então, em vez disso, você tem a ideia de armazenar os dados da sessão em um cookie no lado do cliente. Você o criptografará, é claro, para que o usuário não possa ler e manipular os dados. Então, qual modo você deve usar? Chegando aqui, você lê a resposta do topo (desculpe-me por destacar o myforwik). O primeiro coberto - ECB - não é para você, você deseja criptografar mais de um bloco, o próximo - CBC - soa bem e você não precisa do paralelismo da CTR, não precisa de acesso aleatório, portanto, nenhum XTS e patentes são PITA, portanto não OCB. Usando sua biblioteca de criptografia, você percebe que precisa de algum preenchimento porque só pode criptografar múltiplos do tamanho do bloco. Você escolhePKCS7 porque foi definido em alguns padrões sérios de criptografia. Depois de ler em algum lugar que o CBC é comprovadamente seguro se usado com um IV aleatório e uma cifra de bloco segura, você fica tranquilo, mesmo armazenando seus dados confidenciais no lado do cliente.

Anos mais tarde, após o fato de seu serviço ter aumentado significativamente, um especialista em segurança de TI entrará em contato com você em uma divulgação responsável. Ela está lhe dizendo que pode descriptografar todos os seus cookies usando um ataque oracle padding , porque seu código produz uma página de erro se o preenchimento estiver de alguma forma quebrado.

Este não é um cenário hipotético: a Microsoft tinha essa falha exata no ASP.NET até alguns anos atrás.

O problema é que existem muitas armadilhas em relação à criptografia e é extremamente fácil criar um sistema que pareça seguro para o leigo, mas que seja trivial para um invasor experiente.

O que fazer se você precisar criptografar dados

Para conexões ativas, use TLS (verifique o nome do host do certificado e a cadeia do emissor). Se você não pode usar o TLS, procure a API de nível mais alto que seu sistema oferece para sua tarefa e certifique-se de entender as garantias que ele oferece e, mais importante, o que ele não garante. No exemplo acima, uma estrutura como o Play oferece recursos de armazenamento no lado do cliente , mas não invalida os dados armazenados depois de algum tempo; se você alterou o estado no lado do cliente, um invasor pode restaurar um estado anterior sem você perceber.

Se não houver abstração de alto nível disponível, use uma biblioteca de criptografia de alto nível. Um exemplo proeminente é o NaCl e uma implementação portátil com muitas ligações de idioma é o sódio . Ao usar essa biblioteca, você não precisa se preocupar com os modos de criptografia, etc., mas precisa ter ainda mais cuidado com os detalhes de uso do que com uma abstração de nível superior, como nunca usar um nonce duas vezes.

Se, por algum motivo, você não puder usar uma biblioteca de criptografia de alto nível, por exemplo, porque você precisa interagir com o sistema existente de uma maneira específica, não há como se educar completamente. Eu recomendo a leitura de Engenharia de Criptografia por Ferguson, Kohno e Schneier . Por favor, não se engane, acreditando que pode criar um sistema seguro sem o conhecimento necessário. A criptografia é extremamente sutil e quase impossível testar a segurança de um sistema.

Comparação dos modos

Somente criptografia:

  • Modos que exigem preenchimento : como no exemplo, o preenchimento geralmente pode ser perigoso, pois abre a possibilidade de ataques de preenchimento de oráculos. A defesa mais fácil é autenticar todas as mensagens antes da descriptografia. Ver abaixo.
    • O BCE criptografa cada bloco de dados independentemente e o mesmo bloco de texto sem formatação resultará no mesmo bloco de texto cifrado. Dê uma olhada na imagem do Tux criptografada pelo BCE na página da Wikipedia para ver por que esse é um problema sério. Não conheço nenhum caso de uso em que o BCE seja aceitável.
    • O CBC tem um IV e, portanto, precisa de aleatoriedade toda vez que uma mensagem é criptografada, alterar uma parte da mensagem exige re-criptografar tudo após a alteração, erros de transmissão em um bloco de texto cifrado destroem completamente o texto simples e alteram a descriptografia do próximo bloco, descriptografia pode ser paralelo / criptografia não, o texto sem formatação é maleável até certo ponto - isso pode ser um problema .
  • Modos de cifra de fluxo : esses modos geram um fluxo de dados pseudo-aleatório que pode ou não depender do texto sem formatação. Da mesma forma que as cifras de fluxo geralmente, o fluxo pseudo-aleatório gerado é XORed com o texto simples para gerar o texto cifrado. Como você pode usar quantos bits do fluxo aleatório quiser, não precisa de preenchimento. A desvantagem dessa simplicidade é que a criptografia é completamente maleável, significando que a descriptografia pode ser alterada por um invasor da maneira que ele quiser, como um texto sem formatação p1, um texto cifrado c1 e um fluxo pseudo-aleatório re atacante podem escolher uma diferença d de modo que a descriptografia de um texto cifrado c2 = c1⊕d é p2 = p1⊕d, como p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). Além disso, o mesmo fluxo pseudo-aleatório nunca deve ser usado duas vezes, pois para dois textos cifrados c1 = p1⊕r e c2 = p2⊕r, um invasor pode calcular o xor dos dois textos simples como c1⊕c2 = p1⊕r⊕p2⊕r = p1⊕p2. Isso também significa que a alteração da mensagem requer re-criptografia completa, se a mensagem original puder ter sido obtida por um invasor. Todos os modos de cifra a vapor a seguir precisam apenas da operação de criptografia da cifra de bloco; portanto, dependendo da cifra, isso pode economizar algum espaço (código de silício ou código de máquina) em ambientes extremamente restritos.
    • A CTR é simples, cria um fluxo pseudo-aleatório que é independente do texto sem formatação, diferentes fluxos pseudo-aleatórios são obtidos pela contagem de diferentes nonces / IVs que são multiplicados por um comprimento máximo de mensagem, para evitar a sobreposição, usando a criptografia de mensagem nonces. possível sem aleatoriedade por mensagem, descriptografia e criptografia são concluídas paralelamente, erros de transmissão afetam apenas os bits errados e nada mais
    • O OFB também cria um fluxo pseudo-aleatório independente do texto sem formatação, diferentes fluxos pseudo-aleatórios são obtidos iniciando com um IV diferente de nonce ou aleatório para cada mensagem, nem a criptografia nem a descriptografia são paralelizáveis, como na CTR usando a criptografia de mensagens nonces é possível sem a mensagem aleatoriedade, como nos erros de transmissão CTR, apenas afetam os bits errados e nada mais
    • O fluxo pseudo-aleatório do CFB depende do texto sem formatação, é necessário um IV diferente ou aleatório para cada mensagem, como com CTR e OFB usando a criptografia de mensagens nonces é possível sem aleatoriedade por mensagem, a descriptografia é paralelizável / a criptografia não é, erros de transmissão completamente destrua o bloco a seguir, mas efetue apenas os bits errados no bloco atual
  • Modos de criptografia de disco : esses modos são especializados para criptografar dados abaixo da abstração do sistema de arquivos. Por motivos de eficiência, a alteração de alguns dados no disco deve exigir apenas a reescrita de no máximo um bloco de disco (512 bytes ou 4kib). Eles estão fora do escopo desta resposta, pois possuem cenários de uso muito diferentes dos outros. Não os use para nada, exceto criptografia de disco no nível de bloco . Alguns membros: XEX, XTS, LRW.

Criptografia autenticada:

Para evitar ataques de preenchimento oracle e alterações no texto cifrado, é possível calcular um código de autenticação de mensagem (MAC) no texto cifrado e descriptografá-lo apenas se não tiver sido adulterado. Isso é chamado de criptografar-então-mac e deve ser preferido a qualquer outro pedido . Exceto em poucos casos de uso, a autenticidade é tão importante quanto a confidencialidade (o último dos quais é o objetivo da criptografia). Os esquemas de criptografia autenticados (com dados associados (AEAD)) combinam o processo de criptografia e autenticação em duas partes no modo de criptografia em bloco que também produz uma marca de autenticação no processo. Na maioria dos casos, isso resulta em melhoria de velocidade.

  • O CCM é uma combinação simples do modo CTR e um CBC-MAC. Usando duas criptografias de cifra de bloco por bloco, é muito lento.
  • O OCB é mais rápido, mas onerado por patentes. Para software gratuito (como em liberdade) ou não militar, o detentor da patente concedeu uma licença gratuita .
  • O GCM é uma combinação muito rápida, mas sem dúvida complexa, do modo CTR e GHASH, um MAC sobre o campo de Galois com 2 ^ 128 elementos. Seu amplo uso em importantes padrões de rede como o TLS 1.2 é refletido por uma instrução especial que a Intel introduziu para acelerar o cálculo do GHASH.

Recomendação:

Considerando a importância da autenticação, eu recomendaria os dois modos de codificação de bloco a seguir para a maioria dos casos de uso (exceto para fins de criptografia de disco): Se os dados forem autenticados por uma assinatura assimétrica, use CBC, caso contrário, use o GCM.


214
"Se você precisar fazer essa pergunta, provavelmente não conhece o suficiente sobre criptografia para implementar um sistema seguro". - Você está certo, mas você percebe que fazer perguntas é como as pessoas aprendem? Então, talvez relaxe um pouco.
Robert MacLean

70
@RobertMacLean True, mas, ao contrário de muitos outros campos da TI, você não obterá a segurança certa por tentativa e erro. Considerando que, com o design da web, a escalabilidade de aplicativos, etc., você pode verificar ativamente seus requisitos, o teste dos aspectos de segurança varia de difícil a impossível. Infelizmente, essa é uma lição que raramente é ensinada. A maioria dos recursos diz como a criptografia funciona e não as inúmeras maneiras em que falha na prática sem que você esteja ciente disso. A única saída é saber muito sobre o assunto. E esse é o moral do post: #
Perseids

8
Invista tempo suficiente para conhecer a criptografia completamente ou evite-a o máximo possível e use abstrações fortes. E no tema de aprender como a criptografia quebra o primeiro parágrafo é muito mais específico do que a descrição dos modos.
Perseids

33
Menos um: o título inicial está errado; deve dizer "Se você está fazendo esta pergunta, está indo na direção certa, continue assim e você se destacará!"
Henrik

11
@FerminSilva: Verdade, mas outro aspecto do argumento é que geralmente é mais fácil usar soluções verdadeiras e testadas do que copiar e colar código criptográfico. Por exemplo, quando tudo o que você deseja fazer é conversar com seu servidor a partir de um aplicativo para smartphone, é muito mais simples configurar um proxy reverso Apache com um certificado TLS Criptografar TLS e escrever https://your.serverem qualquer lugar do aplicativo, do que inventar algum protocolo de troca de chaves e faça com que as bibliotecas de criptografia de ambos os lados funcionem juntas sem problemas.
Perseidas

36

Uma análise formal foi feita por Phil Rogaway em 2011, aqui . A Seção 1.6 apresenta um resumo que transcrevo aqui, adicionando minha ênfase em negrito (se você estiver impaciente, a recomendação dele é usar o modo CTR, mas sugiro que você leia meus parágrafos sobre integridade de mensagens versus criptografia abaixo).

Observe que a maioria deles exige que o IV seja aleatório, o que significa imprevisível e, portanto, deve ser gerado com segurança criptográfica. No entanto, alguns exigem apenas um "nonce", que não exige essa propriedade, mas exige apenas que ela não seja reutilizada. Portanto, os projetos que dependem de um noncece são menos propensos a erros do que os que não o fazem (e acredite, já vi muitos casos em que o CBC não é implementado com a seleção IV apropriada). Então você verá que eu adicionei negrito quando Rogaway diz algo como "a confidencialidade não é alcançada quando o IV é inaceitável", significa que se você escolher o seu IV criptograficamente seguro (imprevisível), então não há problema. Mas se não o fizer, estará perdendo as boas propriedades de segurança. Nunca reutilize um IV para nenhum desses modos.

Além disso, é importante entender a diferença entre integridade da mensagem e criptografia. A criptografia oculta os dados, mas um invasor pode modificar os dados criptografados e os resultados podem ser potencialmente aceitos pelo seu software se você não verificar a integridade da mensagem. Enquanto o desenvolvedor disser "mas os dados modificados voltarão a ser lixo após descriptografia", um bom engenheiro de segurança encontrará a probabilidade de que o lixo cause comportamento adverso no software e depois transformará essa análise em um ataque real. Eu já vi muitos casos em que a criptografia foi usada, mas a integridade da mensagem era realmente mais necessária do que a criptografia. Entenda o que você precisa.

Devo dizer que, embora o GCM tenha criptografia e integridade de mensagem, é um design muito frágil: se você reutilizar um IV, está ferrado - o invasor pode recuperar sua chave. Outros projetos são menos frágeis, então, pessoalmente, tenho medo de recomendar o GCM com base na quantidade de código de criptografia ruim que eu vi na prática.

Se você precisar de ambos, integridade da mensagem e criptografia, poderá combinar dois algoritmos: geralmente vemos o CBC com o HMAC, mas não há razão para se vincular ao CBC. O importante é saber criptografar primeiro, depois o conteúdo criptografado por MAC , e não o contrário. Além disso, o IV precisa fazer parte do cálculo do MAC.

Não conheço problemas de IP.

Agora, para as coisas boas do professor Rogaway:

Modos de cifras de bloco, criptografia, mas não integridade da mensagem

BCE : Uma codificação em bloco, o modo codifica as mensagens que são um múltiplo de n bits, codificando separadamente cada parte de n bits. As propriedades de segurança são fracas , o método perde a igualdade de blocos nas posições e no tempo dos blocos. De considerável valor legado e de valor como elemento básico para outros esquemas, mas o modo não alcança qualquer objetivo de segurança geralmente desejável por si só e deve ser usado com considerável cuidado; O BCE não deve ser considerado como um modo de confidencialidade "de uso geral" .

CBC : um esquema de criptografia baseado em IV, o modo é seguro como um esquema de criptografia probabilístico, alcançando indistinguibilidade de bits aleatórios, assumindo um IV aleatório. A confidencialidade não é alcançada se o IV for meramente um nonce , nem se for um nonce codificado sob a mesma chave usada pelo esquema, como o padrão sugere incorretamente fazer. Os textos cifrados são altamente maleáveis. Nenhuma segurança de ataque de texto cifrado (CCA) escolhida. A confidencialidade é perdida na presença de um oráculo de preenchimento correto para muitos métodos de preenchimento. Criptografia ineficiente por ser inerentemente serial. Amplamente usadas, as propriedades de segurança somente para privacidade do modo resultam em uso indevido frequente. Pode ser usado como um componente básico para os algoritmos CBC-MAC. Não consigo identificar vantagens importantes sobre o modo CTR.

CFB : um esquema de criptografia baseado em IV, o modo é seguro como um esquema de criptografia probabilístico, alcançando indistinguibilidade de bits aleatórios, assumindo um IV aleatório. A confidencialidade não é alcançada se o IV for previsível , nem se for produzido por um nonce codificado sob a mesma chave usada pelo esquema, como o padrão sugere incorretamente fazer. Os textos cifrados são maleáveis. Sem segurança CCA. Criptografia ineficiente por ser inerentemente serial. O esquema depende de um parâmetro s, 1 ≤ s ≤ n, normalmente s = 1 ou s = 8. Ineficiente para precisar de uma chamada de código de bloco para processar apenas s bits. O modo obtém uma propriedade interessante de "auto-sincronização"; a inserção ou exclusão de qualquer número de caracteres de s bits no texto cifrado apenas interrompe temporariamente a descriptografia correta.

OFB : Um esquema de criptografia baseado em IV, o modo é seguro como um esquema de criptografia probabilístico, alcançando indistinguibilidade de bits aleatórios, assumindo um IV aleatório. A confidencialidade não é alcançada se o IV é um noncece, embora uma sequência fixa de IVs (por exemplo, um contador) funcione bem. Os textos cifrados são altamente maleáveis. Sem segurança CCA. Criptografia e descriptografia ineficientes por serem inerentemente seriais. Criptografa nativamente seqüências de caracteres de qualquer tamanho de bit (não é necessário preenchimento). Não consigo identificar vantagens importantes sobre o modo CTR.

CTR : um esquema de criptografia baseado em IV, o modo alcança indistinguibilidade de bits aleatórios, assumindo um nonce IV. Como um esquema não baseado em segurança, o modo também pode ser usado como um esquema de criptografia probabilístico, com um IV aleatório. Falha total na privacidade se um nonce for reutilizado na criptografia ou descriptografia. A paralelicidade do modo geralmente o torna mais rápido, em algumas configurações, muito mais rápido do que outros modos de confidencialidade. Um bloco de construção importante para esquemas de criptografia autenticada. No geral, geralmente a melhor e mais moderna maneira de obter criptografia apenas com privacidade.

XTS : um esquema de criptografia baseado em IV, o modo funciona aplicando um código de bloco tweakable (seguro como um PRP forte) a cada pedaço de n bits. Para mensagens com comprimentos não divisíveis por n, os dois últimos blocos são tratados especialmente. O único uso permitido do modo é para criptografar dados em um dispositivo de armazenamento estruturado em bloco. A largura estreita do PRP subjacente e o mau tratamento dos blocos finais fracionários são problemas. Mais eficiente, mas menos desejável do que um código de bloco seguro por PRP (de bloco amplo) seria.

MACs (integridade da mensagem, mas não criptografia)

ALG1–6 : Uma coleção de MACs, todos baseados no CBC-MAC. Muitos esquemas. Alguns são comprovadamente seguros como VIL PRFs, outros como FIL PRFs e outros não têm segurança comprovável. Alguns dos esquemas admitem ataques prejudiciais. Alguns dos modos são antigos. A separação de teclas é inadequada para os modos que a possuem. Não deve ser adotado em massa, mas a seleção seletiva dos “melhores” esquemas é possível. Também seria bom adotar nenhum desses modos, em favor da CMAC. Alguns dos MACs ISO 9797-1 são amplamente padronizados e usados, especialmente no setor bancário. Uma versão revisada da norma (ISO / IEC FDIS 9797-1: 2010) será lançada em breve [93].

CMAC : um MAC baseado no CBC-MAC, o modo é comprovadamente seguro (até o limite do aniversário) como um PRF (VIL) (assumindo que o código de bloco subjacente é um bom PRP). Sobrecarga essencial mínima para um esquema baseado em CBCMAC. Natureza inerentemente serial, um problema em alguns domínios de aplicativos, e o uso com uma codificação de bloco de 64 bits exigiria uma reinserção ocasional. Mais limpo que a coleção ISO 9797-1 de MACs.

HMAC : um MAC baseado em uma função de hash criptográfico em vez de em um código de bloco (embora a maioria das funções de hash criptográfico sejam baseadas em códigos de bloco). O mecanismo possui fortes limites de segurança comprovável, embora não de suposições preferidas. Várias variantes intimamente relacionadas na literatura complicam a compreensão do que é conhecido. Nunca foram sugeridos ataques prejudiciais. Amplamente padronizado e usado.

GMAC : um MAC não baseado em GCE que é um caso especial do GCM. Herda muitas das boas e más características do GCM. Mas o non-requisito é desnecessário para um MAC, e aqui ele compra pouco benefício. Ataques práticos se as tags forem truncadas para ≤ 64 bits e a extensão da descriptografia não for monitorada e reduzida. Falha completa na não reutilização. De qualquer forma, o uso está implícito se o GCM for adotado. Não recomendado para padronização separada.

criptografia autenticada (criptografia e integridade da mensagem)

CCM : um esquema AEAD não baseado em código que combina a criptografia no modo CTR e o CBC-MAC bruto. Inerentemente serial, limitando a velocidade em alguns contextos. Provavelmente seguro, com bons limites, assumindo que o código de bloco subjacente seja um bom PRP. Construção deselegante que demonstra o trabalho. Mais simples de implementar que o GCM. Pode ser usado como um MAC não baseado em EC. Amplamente padronizado e usado.

GCM : um esquema AEAD não baseado em código que combina criptografia no modo CTR e uma função hash universal baseada em GF (2128). Boas características de eficiência para alguns ambientes de implementação. Bons resultados comprovadamente seguros, assumindo o truncamento mínimo de tags. Ataques e baixos limites de segurança comprovável na presença de truncamento substancial de tags. Pode ser usado como um MAC não baseado em GCE, que é chamado GMAC. Escolha questionável para permitir nonces que não sejam 96 bits. Recomenda restringir nonces a 96 bits e tags a pelo menos 96 bits. Amplamente padronizado e usado.


1
Modo GCM: Dado que a maioria dos SOs tem pouco ou nenhum conhecimento de criptografia, não usará nenhum modo corretamente, geralmente não usa autenticação e geralmente usa o modo ECB. O modo GCM é provavelmente a melhor opção aqui . Infelizmente, a falta de implementações de plataforma, em alguns casos (iOS), não há suporte de fornecedor, verificação ruim em muitos casos, falta de suporte de hardware, atualmente é problemática. Caso contrário, é bom para os não iniciados em criptografia, pois ele possui autenticação integrada e parece ser o futuro.
Zaph 7/03

3
Modo CTR: Não concordo com o modo CTR como a melhor opção devido a tantas falhas na prática, principalmente a reutilização IV. Até a Microsoft estragou tudo isso pelo menos algumas vezes.
Zaph 7/03

1
Modo CBC: Provavelmente o modo mais comum e o mais usado no SO, BCE (que não deve ser usado), exceto. As principais falhas de uso são um IV não aleatório, mas estamos vendo usos mais corretos com um CSPRNG. O Padding Oracles, embora seja um problema, é facilmente remediado simplesmente ignorando e não retornando erros de preenchimento. Algumas implementações (por exemplo, Common Crypto) não relatam erros de preenchimento de uma maneira essencialmente bem-sucedida de evitá-los no nível da API.
Zaph 7/03

1
A CTR da IMO é pior porque é um xor simples, onde a CBC tem propagação de bloco para bloco, assim como vários outros modos. Pode parecer fácil, mas houve grandes falhas no código do mercado de massa.
Zaph 7/03

1
Ao ler o artigo vinculado, parece que apenas a chave de autenticação é obtida, e não a chave de criptografia da reutilização nonce. Essa não parece ser a afirmação nos comentários aqui de que a chave de criptografia é obtida. A obtenção da chave de autenticação permite a violação da mensagem, mas não a recuperação da mensagem. Por favor, indique onde posso estar errado.
Zaph

30
  1. Qualquer coisa menos o BCE.
  2. Se você estiver usando CTR, é essencial que você use um IV diferente para cada mensagem; caso contrário, o invasor poderá pegar dois textos cifrados e derivar um texto sem criptografia combinado. O motivo é que o modo CTR transforma essencialmente uma cifra de bloco em uma cifra de fluxo, e a primeira regra das cifras de fluxo é nunca usar a mesma chave + IV duas vezes.
  3. Realmente não há muita diferença em como os modos são difíceis de implementar. Alguns modos exigem apenas que a cifra de bloco opere na direção da criptografia. No entanto, a maioria das cifras de bloco, incluindo AES, não precisa de muito mais código para implementar a descriptografia.
  4. Para todos os modos de cifra, é importante usar IVs diferentes para cada mensagem se suas mensagens puderem ser idênticas nos primeiros bytes e você não desejar que um invasor saiba disso.

Para dar suporte ao seu ponto 1 (+1 para esse btw): codinghorror.com/blog/archives/001267.html
Michael Stum

1
Você não deve iniciar a CTR com um número aleatório, pois isso tem uma chance pequena, mas crescente, de colidir com parte de uma mensagem anterior. Em vez disso, aumente-o monotonicamente (isso pode significar lembrar onde você está no armazenamento persistente) e digite novamente se (quando) você ficar sem contador.
CAF

@Theran - ponto 2 - um número aleatório diferente para cada mensagem? Não, acho que isso não está correto. Estou com a impressão de que iniciar o contador sempre em zero é bom. @caf, acho que quando Theran diz "mensagem", ele não significa "bloco". Obviamente, o contador é incrementado para cada bloco de uma mensagem específica que é executada na cifra. O que Theran parece estar dizendo é que cada mensagem deve começar com um valor inicial diferente para o contador. E acho que isso não está correto.
Cheeso

1
re: ponto 3 - Eu li artigos que dizem, por exemplo, que o modo CTR é menor para implementar porque a descriptografia é a mesma transformação que a criptografia. Portanto, metade do código. Mas, como eu disse, não é relevante em uma máquina de classe de servidor.
Cheeso

Sim, eu errei. É o IV / nonce que deve mudar para o modo CTR, mas que é combinado com o contador antes da criptografia, então eu costumo pensar nele como um ponto de partida aleatório para o contador. Na medida em que apenas é necessário usar a cifra na direção da criptografia, economizando espaço, para muitas cifras, você só precisa reverter as subchaves para descriptografar. O AES é um pouco volumoso para descriptografar, mas não é como se você pudesse implementá-lo em um uC com 128 bytes de RAM. As subchaves ocupam mais RAM que isso!
Theran

13

Você começou lendo as informações sobre isso na Wikipedia - Bloquear modos de operação de cifra ? Em seguida, siga o link de referência na Wikipedia para NIST: Recomendação para Modos de Operação de Cifra em Bloco .


6
Esta resposta não atende aos padrões de qualidade do Stackoverflow: suponha, em sua resposta, que todos os links externos tenham se esgotado e resuma - se não a cópia definitiva - as informações relevantes, de maneira ideal para responder melhor à pergunta original.
mirabilos

5
@mirabilos Chegando quase 5 anos depois, referindo-se a normas e padrões que não existiam na época, sério? Eu gosto especialmente de falar sobre links mortos quando os dois aqui ainda estão muito ativos e, dado que o site em questão provavelmente permanecerá por mais 5 anos. Ah bem.
KTC 04/04

3
@mirabilos Você pode estar correto , sem dúvida , mas a sua reclamação contra uma resposta que parecia ter sido feita há 5 anos em que as normas eram diferentes não é aplicável. Você deveria ter acabado de admitir seu erro. Mesmo que não seja esse o caso e que você esteja sugerindo que deve ser atualizado ou alterado, ainda não é obrigatório. A resposta foi suficiente de como era.
precisa saber é o seguinte

@KTC Exceto quando o governo é encerrado e o site está offline. Sua resposta pode ter sido uma informação útil, mas no momento está completamente ausente. Portanto, o leitor desta pergunta e suas respostas ainda fica imaginando o que foi atualizado em 2014 (devido a uma resposta incompleta) e o status atual (devido a um desligamento do governo no site do NIST). Eu adoraria adicionar as informações em falta, no entanto ...
G DeMasters

11

Você pode escolher com base no que está amplamente disponível. Eu tive a mesma pergunta e aqui estão os resultados da minha pesquisa limitada.

Limitações de hardware

STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC

Limitações de código aberto

Original rijndael-api source  - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API    CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)  
OpenAES [2] - ECB, CBC 

[1] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library

[2] https://openaes.googlecode.com/files/OpenAES-0.8.0.zip


1
ST Micro: EBC deve ser BCE; FYI: por exemplo, o STM32L4A6 suporta AES de 128 e 256 bits, com ECB, CBC, CTR, GCM, bem como o código de autenticação de mensagem Galois (GMAC) ou algoritmos de encadeamento CMAC no modo de código de autenticação de mensagem também são suportados por hardware.
Tom Kuschel

-3

Conheço um aspecto: embora o CBC ofereça melhor segurança alterando o IV para cada bloco, ele não é aplicável ao conteúdo criptografado acessado aleatoriamente (como um disco rígido criptografado).

Portanto, use CBC (e os outros modos seqüenciais) para fluxos sequenciais e o BCE para acesso aleatório.


Ah, claro, é claro. O CBC XORs o bloco de texto cifrado anterior com o bloco de texto sem formatação antes da criptografia. O primeiro bloco usa o IV. Portanto, para descriptografar qualquer bloco, você deve descriptografar com êxito todos os blocos anteriores. ok, essa é uma boa ideia.
Cheeso

6
Não, você só precisa ter acesso ao texto cifrado anterior , o que não requer a descriptografia de nenhum bloco anterior.
CAF

Ah, bem, isso significa que a CBC está bem com acesso aleatório, não é?
Cheeso

4
@ Chees: CBC é bom para acesso aleatório de leitura, mas não para acesso aleatório de gravação. Use CTR lá.
Paŭlo Ebermann 25/10/11

3
@ PaŭloEbermann Para acesso aleatório, a CTR não é uma boa ideia, pois permite ataques graves se um invasor observar duas versões do texto cifrado. Use o XTS ou um código de bloco tweakable.
CodesInChaos
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.