Desvantagens do AES-CTR?
No papel, parece * muito * bom para mim:
- seguro
- rápido (em meus testes é um pouco mais lento do que o ECB (mas sem a maioria das fraquezas, mais sobre isso abaixo), mas mais rápido do que todas as alternativas que testei, que foram
ECB, CTR, CBC, OFB, CFBescritas em ordem de desempenho ( link para o código de benchmark )) - simples de entender
- não requer preenchimento (o que eu acho que reduz significativamente a chance de implementar preenchimento de uma maneira insegura)
- suporta paralelização (para criptografia e descriptografia)
- suporte acesso aleatório
.. a única desvantagem em que posso pensar é que, como não requer preenchimento, as implementações na prática provavelmente revelarão o comprimento exato da mensagem , em comparação com a revelação de tamanhos de mensagem próximos (por exemplo, esquemas preenchidos podem revelar algo como the message is within 15 bytes of this length, enquanto não (esquemas preenchidos podem revelar the message is *exactly* this long), e se isso for uma preocupação, não é como se não pudesse ser mitigado apenas adicionando preenchimento de qualquer maneira.
Acho que estou faltando alguma coisa, então ...
Quais são as desvantagens?
Respostas
Desvantagens:
Comprimento da mensagem: Na criptografia, normalmente, o comprimento da mensagem não é considerado secreto. Existem abordagens em que você pode adicionar valores aleatórios ao final ou ao início ou a ambos, se isso for realmente um vazamento de informações para você. A abordagem aleatória depende do seu caso de dados real. Também é possível que um tamanho fixo pré-determinado possa ser usado, pois o e-mail pode ser limitado a 512 caracteres. No final, pelo menos o limite superior é revelado em todos os casos.
A reutilização do par (IV, chave) é um problema real que pode eliminar a confidencialidade com a técnica de arrastar no berço. Isso não revela a chave de criptografia.
Falta de autenticação Como todos os modos de criptografia não autenticados, o modo simples CTR carece de integridade e autenticação. Um único lance de inversão pode ter resultados catastróficos devido à maleabilidade do modo CTR.
O modo AES-GCM que usa o modo de operação CTR fornece tudo em uma vez, entretanto, tem o mesmo problema de reutilização de pares (IV, chave). Há um modo de vetor de inicialização sintética (SIV) como resistência ao uso incorreto ( papel , rfc8452 ) que elimina isso. O modo SIV ainda pode vazar que a mesma mensagem é enviada com a mesma chave, para que um observador possa distinguir isso.
Distinguidor de mensagem longa: o modo CTR é projetado com uma função pseudo-aleatória (PRF). Ao usar AES no modo CTR, nós o usamos com Pseudo Random Permutation (PRP);$$E_k\colon \{0,1\}^n \to \{0,1\}^n.$$ Whit PRP, desde que os blocos de mensagem não sejam repetidos na sequência $E_k(0), E_k(1), \dots, E_k(\ell - 1)$ com $\ell < 2^n$não é repetido. Se a mensagem com comprimento$\ell$-block não tem bloco repetido, isso não é problema. Se abordarmos a mensagem como um bloco aleatório uniforme, então esperamos uma colisão$\ell \approx \sqrt{2^n} = 2^{n/2}$ pelo paradoxo / ataque do aniversário.
Quando usado com AES-128 para mensagens longas, verifique a repetição. A repetição permite ao invasor distinguir isso do aleatório uniforme com probabilidade não desprezível .
Em suma, um texto cifrado duplicado em qualquer posição vaza que as mensagens são diferentes.
Tamanho da mensagem por chave: embora o NIST diga 64 nonce e contador de 64 bits, deve-se parar de usar uma chave bem antes$2^{64}$quadra. Isso ocorre devido ao uso de um PRP (AES) em vez de PRF no modo CTR .
Outras vantagens:
Não há necessidade de descriptografar: o modo CTR não requer a descriptografia da cifra de bloco, ele sempre as usa para criptografia. Isso é muito útil em ambientes restritos. Simplifica o código do software e do hardware também.
Não há necessidade de PRP: não precisa de uma cifra de bloco (PRP). Uma função hash pode ser usada como na série ChaCha.
Pré-processamento: o fluxo de chaves gerado pelo modo CTR pode ser preparado antes. Isso pode ajudar a usar buffers.
O modo CTR possui segurança CPA .
Um pouco de história da CTR
O modo CTR foi introduzido por Whitfield Diffie e Martin Hellman em 1979
Privacidade e autenticação: Uma introdução à criptografia como um artigo convidado em Proceedings of the IEEE, 67 (1979), pp. 397-427.
Uma segurança concreta de tratamento de criptografia simétrica, Bellare et. al, 97 fornece os limites de segurança.
Veja também; Comentários ao NIST sobre os modos de operação do AES: criptografia em modo CTR , por Lipmaa et al. para outros detalhes de vantagens e desvantagens.
Schneier e Ferguson recomendaram inicialmente o modo CTR, mas mudaram para o modo CBC recomendado devido a potenciais dificuldades em garantir que o contador nunca fosse reutilizado com uma chave.
Embora sua pergunta pareça estar se concentrando no lado CTR das coisas, vale a pena responder para discutir o lado AES das coisas também. Existem pelo menos duas situações em que outras cifras de bloco podem ser mais apropriadas.
Computação segura :
Existem duas "dificuldades" principais do AES no que diz respeito à computação segura (o que significa computação multi-partidária e NIZKs principalmente, mas também provavelmente criptografia totalmente homomórfica).
O AES é calculado sobre um campo de característica 2. Se um sistema MPC / FHE usa a característica $p$ aritmética, ter uma cifra na característica 2 requer conversões entre diferentes representações (digamos, de um elemento em $\mathbb{Z}/p\mathbb{Z}$, ou a decomposição de base 2 de tal elemento), que são mais caros do que no cálculo padrão.
Genericamente, as multiplicações são muito mais caras (relativamente) do que as adições no contexto de computação segura. Isso significa que se pode ter um "modelo de custo" diferente para construir cifras, onde se está mais interessado em reduzir o número de multiplicações na cifra genericamente.
Uma cifra para olhar para este tópico é MiMC (embora tenha havido recentemente um ataque parcial contra esta cifra em um "$\mathbb{F}_{2^k}$ versão "dele. Também tem"$\mathbb{F}_p$"versões, que não são atingidas pelo ataque).
Sistemas Embarcados :
Em máquinas padrão, a implementação de hardware do AES (por meio da instrução AES-NI) oferece algo como um aumento de velocidade de aproximadamente 40x em relação às implementações de software otimizadas do AES. Isso torna difícil ser competitivo com o AES ao comparar o AES-NI a implementações de software de outras cifras. Mas quando você não tem AES-NI, outras cifras podem ser mais competitivas. Este post de Matthew Green discute o uso de alternativa ao AES (sua recomendação ao escrever isto ~ 8 anos atrás era não fazer isso, para registro) discute certas cifras como Salsa20 oferecendo um aumento de velocidade 2x - 3x sobre AES no software. Observe que Salsa20 é tecnicamente uma cifra de fluxo em comparação com AES sendo uma cifra de bloco, mas isso é apenas para motivar ser capaz de "vencer" AES em velocidade quando você não tem acesso ao AES-NI.
Uma fonte melhor para cifras mais rápidas em ambientes de computação restritos é o NIST Lightweight Cryptography Standardization em andamento . Não tenho acompanhado isso de perto, mas atualmente há muito interesse de pesquisa em encontrar uma nova cifra para padronizar para (essencialmente) uso em sistemas embarcados. Eles estão atualmente planejando postar seus finalistas da terceira rodada em dezembro próximo, então não me surpreenderia se nos próximos anos houvesse uma "nova cifra" que substitua o uso de AES em sistemas embarcados.
CTR é realmente um modo de operação de cifra de bloco muito bom. Suas principais desvantagens são:
- ele não protege a integridade da mensagem (e de fato permite que um invasor facilmente inverta bits arbitrários em uma mensagem criptografada sem ter que descriptografá-la), e
- pode vazar texto sem formatação se um bloco contador for reutilizado; em particular, a criptografia no modo CTR requer uma entrada única que absolutamente não deve ser reutilizada para duas mensagens diferentes criptografadas com a mesma chave.
Felizmente, esses dois problemas podem ser resolvidos usando o modo CTR como um componente em uma construção de nível superior:
- O primeiro problema pode ser resolvido usando um modo de criptografia autenticado , muitos dos quais (como EAX e GCM ) são baseados em uma combinação do modo CTR com um código de autenticação de mensagem .
- O segundo problema pode ser resolvido usando um modo de criptografia "resistente ao uso indevido de nonce" que deriva o valor do contador inicial com base (entre outras coisas) na mensagem de texto simples que está sendo criptografada. Tais modos incluem SIV e GCM-SIV , ambos os quais também são baseados no modo CTR e também fornecem autenticação de mensagem conforme descrito acima.
Obviamente, a adição de autenticação de mensagem requer algum processamento extra que torna esses modos mais lentos do que o CTR bruto (embora uma boa implementação do GCM ainda possa ser muito rápida). Em particular, para obter a segurança total que esses modos garantem, o receptor deve autenticar toda a mensagem antes de transmitir qualquer texto simples descriptografado. Para os modos resistentes ao uso indevido, o mesmo também se aplica ao criptografar, uma vez que a mensagem inteira deve ser processada para derivar o valor do contador inicial antes que possa ser criptografada.
Ainda assim, geralmente é um preço pequeno a pagar por maior segurança. Se você pode usar um modo resistente ao uso incorreto de nonce, como SIV ou GCM-SIV, eu recomendo fortemente que você faça isso. Se não, pelo menos use um modo AE baseado em nonce como GCM.