Implementando Algoritmo AES Padronizado
- Espero que esta questão se encaixe aqui -
Repetidamente, há sempre uma pessoa que pergunta sobre a criação de seu próprio padrão / cifra de criptografia, e todos concordamos em interrompê-los logo no início, porque todos concordamos que é muito imprudente fazer isso (como prevenir fraquezas desconhecidas ou invisíveis em seu padrão, etc.).
Minha pergunta curiosa é: que tal programar sua própria biblioteca de, digamos, cifra AES, na linguagem de sua escolha? Não é criar uma nova cifra (ainda segue estritamente a cifra / algoritmo AES), mas apenas escrever esse algo na linguagem de programação de sua escolha (talvez faça a cifra AES novamente em C / C ++ para que possamos usar um novo recurso (s) integrado (s) no novo gen CPU e torná-lo mais rápido -> APENAS EXEMPLO) ou alguém construiu uma nova linguagem de programação que ainda não tem biblioteca AES (e você deseja contribuir com uma). Ainda é sensato fazer isso?
Respostas
Que tal programar sua própria biblioteca de, digamos, cifra AES, na linguagem de sua escolha?
Implementar o AES por conta própria de maneira correta não é muito difícil. A especificação é bem escrita, contém ilustrações e vetores de teste intermediários para que praticamente qualquer pessoa possa fazer isso.
O que é complicado para o AES e a razão pela qual geralmente não é aconselhável escrever uma implementação pronta para produção é escrever uma implementação que seja razoavelmente rápida e (/ ou) resistente aos canais laterais da CPU de software comum.
Se você ainda deseja que sua linguagem tenha uma implementação AES, a maneira usual de fazer isso seria usar a interface de função estrangeira para chamar uma biblioteca AES baseada em C.
Quanto à implementação do AES você mesmo, se sua linguagem compilar para código de máquina, geralmente há uma maneira de acessar os intrínsecos do AES e, com eles, geralmente há pouco que se possa fazer de errado - além de não permitir que a CPU canalize as instruções de maneira adequada.
Se você não tiver uma linguagem compilada por código de máquina e / ou sua CPU de destino não tiver instruções de hardware AES, as coisas ficam mais complicadas. Você precisa garantir que o que quer que você escreva em seu idioma não faça coisas estranhas durante a interpretação / compilação just-in-time para introduzir acidentalmente instruções extras. Você precisa garantir que a implementação sempre leve a mesma quantidade de tempo, independentemente da chave e dos dados usados. Você precisa garantir que a etapa anterior não seja realmente potencialmente confundida pelo interpretador / compilador JIT / CPU. Você também precisa garantir que seus padrões de acesso à memória não dependam de dados secretos. A maioria desses pontos pode ser corrigida, por exemplo, usando implementações AES em bits, mas isso está longe de ser uma tarefa trivial - especialmente se você quiser que a implementação seja razoavelmente rápida.