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.