O mito sobre o "móvel" CHACHA20

Ao preparar a metodologia para calcular o índice de confiabilidade HTTPS, vasculhamos muita literatura temática e mais de uma vez encontramos uma recomendação para oferecer suporte a conjuntos de criptografia com base no algoritmo de criptografia CHACHA20 em um servidor da web, a fim de reduzir a carga em clientes móveis que não pode usar hardware AES. Nesse contexto, os processadores Mediatek e "processadores móveis de orçamento antigo" costumavam ser mencionados.



O CHACHA20 com seu fiel companheiro POLY1305 realmente mantém os clientes móveis bacanas e vale a pena suportá-lo em um servidor da web? Vamos discutir isso!



CHACHA20 foi criado pelo renomado criptógrafo Daniel Bernstein, a quem amamos por seu Curve25519 em particular, e por seus esforços de defesa de que apenas oldfags lembrem o que _EXPORT_ significava em uma suíte de criptografia. O algoritmo é bem pesquisado, opera no modo AEAD, não tem fraquezas ou vulnerabilidades conhecidas e é um dos dois algoritmos de criptografia aprovados pela IETF para uso em TLS 1.3 (o outro é AES imortal).



Sua força criptográfica teórica quando usada em TLS é estimada de forma diferente, no intervalo entre AES-128 e AES-256 no modo GCM, que é considerada suficiente pelos padrões de hoje e para o futuro previsível. Ao mesmo tempo, é notadoque CHACHA20 é "mais rápido" do que AES, ou seja, "Consome menos recursos do processador para fornecer o mesmo nível de força criptográfica." Este texto não só cheira a telemarketing (com todo o respeito ao seu autor), mas também perde um detalhe importante: em processadores sem suporte de hardware AES.



E aqui nós finalmente retornamos aos "processadores móveis de orçamento" que superaquecem sob AES, começam a acelerar e demandar nitrogênio líquido (sarcasmo). Os fabricantes de processadores estão cientes do problema e o resolveram adicionando um conjunto apropriado de instruções. Em processadores compatíveis com x86, isso é AES-NI, em outros - seus nomes (e seu próprio conjunto). E aqui chegamos à parte mais interessante: suporte AES por processadores.



A Intel introduziu o suporte para AES-NI em 2010 nos processadores Westmere, e não em todos: Atom, Celeron, Pentium e Core i3 nos quais não confiava há muito tempo. Você pode ter certeza do suporte AES-NI sem se aprofundar nas especificações apenas começando com a arquitetura Goldmont (Apollo Lake e Denverton), e isso já é 2016.



Para AMD, essas são as arquiteturas Bulldozer (2011) e Jaguar (2013), com ARM tudo é mais complicado: o suporte para instruções AES é fornecido na arquitetura ARMv8-A (2011, o primeiro dispositivo é 2013), mas a implementação real deles em silício depende do processador do fabricante e eu, pessoalmente, não denunciaria com tanta confiança "processadores móveis de orçamento antigo", em vez disso, vale a pena falar sobre "processadores móveis não emblemáticos" em geral, incl. produzido até hoje.



Simplificando, não é tão difícil encontrar um processador sem suporte de hardware AES. Então CHACHA20 é realmente uma ótima alternativa ao AES? Vamos dar uma olhada nos resultados deste estudo , por exemplo . Em processadores sem suporte a AES, o CHACHA20 está visivelmente à frente em desempenho, muitas vezes. Infelizmente, não foram mostradas as medições de temperatura, mas se estamos falando de um processador de servidor, é óbvio que a diferença nos recursos do processador consumidos é significativa.



A situação é inversa quando se trata de processadores compatíveis com AES. Não vale a pena culpar o CHACHA20 por isso, a quem ninguém ofereceu um conjunto pessoal de instruções no processador, e o que acontece quando os dois jogadores jogam pelas mesmas regras que víamos nos processadores antigos (lembre-se: AES mescla).



Então, vamos buscar o suporte CHACHA20 em servidores web? Por que não, se apenas porque todos os ovos não são colocados na mesma cesta, e se amanhã de repente um buraco for encontrado no próprio AES ou sua implementação em uma biblioteca de criptografia particular, podemos desligá-lo "até esclarecimento" com um leve movimento da nossa mão, permanecendo no CHACHA20, e não procurando freneticamente algo para substituir o AES, mas como ele liga.



A questão do lugar de CHACHA20 em nossa vida é muito menos direta. a lista de suítes de cifras oferecidas pelo servidor web para negociação, ou seja, sua prioridade.



Vamos lembrar como o pacote de criptografia é geralmente negociado ao estabelecer uma conexão HTTPS: o cliente envia ao servidor a lista de pacotes de criptografia que ele suporta, na ordem "do bulldozer" e esta ordem pode ser alterada apenas por meio de políticas de grupo do Windows e apenas para Navegadores Internet Explorer usando SChannel (correto, se estiver errado). O servidor compara a lista recebida do cliente com a lista de conjuntos de criptografia que ele suporta e informa ao cliente qual ele escolheu para proteger a conexão. Se a prioridade dos conjuntos de cifras for configurada no servidor, será acordado o primeiro que corresponder em ambas as listas, levando em consideração a prioridade configurada no servidor. Se não for definido, então o administrador do servidor precisa arrancar suas mãos, estamos mergulhando no campo da teoria da probabilidade desconhecida .



A prioridade dos conjuntos de criptografia no servidor é geralmente definida com base no princípio da segurança máxima disponível: os conjuntos de criptografia mais fortes são listados primeiro, menos - o último. Um cliente moderno se depara com um conjunto de criptografia forte e concorda com ele, um cliente "desatualizado" pula ainda mais para baixo na lista para um conjunto de criptografia menos forte e concorda com ele. Todos estão felizes, tudo funciona, desde cada um de acordo com sua capacidade, até cada um usando HTTPS.



E aqui um conjunto de cifras baseado em CHACHA20 se encaixa neste quadro harmonioso do mundo, que adicionamos por razões de reduzir a carga sobre os clientes "fracos" do ponto de vista do hardware, sem saber se eles estão simultaneamente "desatualizados" ou não (ou seja, o carro-chefe deste ano de uma empresa chinesa de terceiro nível ou uma criança de cinco anos de uma marca de primeira linha). O cliente informa que ele oferece suporte a TLS 1.3 e um conjunto completo de conjuntos de criptografia associados, AES e CHACHA20. Sua solução, administrador, com qual pacote de criptografia estamos concordando com o cliente? Aqui estou quase o mesmo ...



Resumo o acima sobre o algoritmo de criptografia CHACHA20.

1. O algoritmo é muito bom para si mesmo e é adequado para uso em TLS.
2. Os pacotes de criptografia baseados nele são suportados apenas por navegadores razoavelmente modernos , portanto, não há necessidade de AES.
3. O ganho de desempenho com seu uso pode ser obtido não apenas em "processadores móveis de orçamento antigo", mas também em desktops e servidores. Em processadores com suporte de hardware AES, a situação é inversa.
4. Ao estabelecer uma conexão HTTPS, não há como saber se o processador do cliente suporta AES no hardware. Conseqüentemente, não há como saber qual pacote de criptografia será "mais rápido" em cada caso.