Combinando os modos CTR e ECB para prevenir ataques
Ao reutilizar chaves AES-CTR e IVs para criptografia de arquivos , o OP estava perguntando sobre um esquema de criptografia composto$$C_i = E_K\left(P_i \oplus E_K\left(IV + i\right)\right)$$ que é basicamente apenas um CTR seguido de um ECB.
Agora, embora sua intenção fosse usar isso para criptografia de disco (onde o IV é apenas a localização única (mas conhecida) de um bloco no disco), essa abordagem veio com certas fraquezas devido aos recursos de ataque de um invasor na teoria de criptografia de disco . No entanto, gostaria de saber se há vantagens significativas para este CTR-then-ECB fora de necessariamente um contexto de criptografia de disco - como criptografar dados em um banco de dados, por exemplo.
Especificamente, qualquer reutilização de (IV/nonce + counter)em CTR (para a mesma chave) pode levar trivialmente a um ataque de texto simples conhecido se o invasor souber o texto simples de quaisquer outros blocos também criptografados com ele (IV/nonce + counter). E não apenas um (IV/nonce + counter)bloco, mas também quaisquer blocos "próximos" pertencentes a essas mensagens (devido à sobreposição do contador!).
No entanto, se criptografarmos com CTR-then-ECB, o invasor só saberá o texto simples dos blocos se eles estiverem criptografados com o mesmo IV+counter e também contiverem o mesmo texto cifrado. Em contraste, um invasor de um esquema de criptografia apenas CTR requer apenas correspondência IV + counter(para um bloco conhecido), e um invasor de um esquema de criptografia apenas CBC exige apenas correspondência de textos cifrados (para um bloco conhecido).
Mas isso é uma vantagem significativa, ou as probabilidades envolvidas aqui são tão mínimas - especialmente se usar IVs aleatórios - que o CTR-então-ECB deixa de fornecer qualquer benefício real? (por exemplo, com AES)
Respostas
Existem alguns problemas que vêm à mente:
- este é um esquema de passagem dupla, que é computacionalmente caro;
- o vazamento de blocos idênticos é desnecessário; há esquemas que vazam apenas texto simples totalmente idêntico;
- O modo ECB requer preenchimento, então você criaria alguma sobrecarga.
Agora você pode argumentar que 1. não é um problema nos computadores atuais. No entanto, isso só seria um bom argumento se não houvesse nenhum esquema que apresentasse as mesmas propriedades sem exigir uma passagem dupla.
Quanto à 2, existem esquemas como a criptografia de preservação de formato que não vaza nenhuma informação além de texto simples totalmente idêntico. O FPE geralmente é bastante caro quando se trata de implementação (por outro lado, não ter que armazenar um IV geralmente não é um problema para binários grandes, pois eles geralmente teriam um tamanho VARiável). Outra opção é realizar uma criptografia de bloco no índice e usar isso como um IV imprevisível para o modo CBC (possivelmente com o roubo de texto cifrado, se você não gostar da sobrecarga de preenchimento). As rotinas de criptografia de disco existentes, como XTS e ESSIV, já foram mencionadas.
Quanto ao 3, o roubo de texto cifrado (CTS) para o modo ECB pode ser implementado, mas definitivamente não ajuda na facilidade de implementação, o que seria o principal benefício sobre outros esquemas (ECB geralmente está disponível em, por exemplo, SQL e CTR é relativamente simples de implementar usando o ECB, embora eu definitivamente não goste de fazer isso no SQL).
Por fim, se você tiver espaço para uma etiqueta de autenticação, um modo SIV (como AES-GCM-SIV) pode ser usado para remover a necessidade de um IV explícito. Se você tem espaço para ambos, então apenas um AES-GCM genérico faria sentido, é claro.
Em suma, acho que - embora o esquema tenha méritos - há opções melhores por aí - de preferência aquelas que são construídas no motor DB.