Dois perfis são medidos no mesmo gateway, um com cifra e outro sem, e o cifrado não é mais lento. Às vezes é mais rápido, o que costuma render uma longa discussão sobre se o teste foi executado corretamente. O resultado é plausível, porque o custo de um pacote não é o número de palavras criptográficas na configuração. É o conjunto de operações que a implementação executa, no hardware que tem, sobre o layout de buffer que escolheu.

O sintoma: o lento não é o perfil cifrado

Suponha que um teste histórico compare uma cifra AEAD com um modo «sem cifra» que ainda calcula um código de autenticação separado por pacote. O segundo perfil esconde o conteúdo da carga útil mas mantém um hash por pacote, e num processador sem aceleração para esse hash pode custar mais do que a construção integrada que deveria vencer.

O rótulo na configuração diz «cifra», e o rótulo é tudo o que a maioria das comparações observa. O caminho do pacote diz outra coisa: um perfil executa uma operação combinada para a qual a CPU tem instruções, e o outro executa uma separada para a qual não tem. Ler apenas o arquivo de configuração nunca revelará essa diferença, porque as duas entradas parecem uma só linha. Só o modo negociado e o caminho de código por trás dele explicam o resultado.

Essa é toda a explicação, e ela não exige nenhuma afirmação sobre qual primitiva é universalmente mais rápida. As duas podem ser rápidas, as duas podem ser lentas, e a ordem depende da máquina e do código.

Conte operações, não rótulos

Uma construção AEAD, como a descreve a RFC 5116, dá à implementação uma única interface que devolve o texto cifrado e a etiqueta juntos. AES-GCM é um exemplo: cifra em modo contador combinada com um autenticador de Galois. A interface não torna a integridade gratuita; torna a combinação bem definida, e é isso que permite a uma implementação otimizar o par como uma unidade.

Separate authentication path:
  payload -> independent HMAC -> framed packet

AEAD path:
  payload -> authenticated encryption with tag -> framed packet

São esboços de processamento, não conselhos de configuração. O primeiro não tem confidencialidade mas ainda gasta CPU em autenticação, e é exatamente por isso que «desligar a cifra» não é sinônimo de «desligar o trabalho criptográfico».

O segundo pode ser mais barato porque os processadores oferecem instruções para as duas metades: rodadas AES e a multiplicação sem transporte que o corpo de Galois usa. Bibliotecas também processam buffers independentes em paralelo, o que mantém essas instruções ocupadas em vez de esperar pela memória.

O que o modo negociado realmente permite

Com o Community OpenVPN, uma cifra de dados AEAD significa que a opção auth já não contribui com um HMAC próprio e separado do canal de dados. A referência da opção de cifra descreve esse escopo, e é a razão pela qual duas configurações que parecem iguais num arquivo de texto podem diferir no trabalho por pacote.

Leia o modo negociado em vez da lista de desejos. Uma lista de cifras permitidas e um nome de suíte TLS não dizem quais operações correm sobre a carga útil, e uma linha cipher antiga pode não descrever o que a conexão atual escolheu.

openvpn --show-ciphers | head -20
sudo grep -E 'cipher|auth' /etc/openvpn/server.conf

O primeiro comando lista as cifras que o binário suporta, o que é uma lista de capacidades e não o resultado negociado. O segundo mostra o que o servidor realmente pede. O log da conexão é o lugar para confirmar a escolha final, porque um cliente pode recuar para algo que o servidor permite mas que ninguém pretendia.

Meça a carga de trabalho que você realmente executa

Um microbenchmark criptográfico mede uma primitiva nas suas próprias condições. Uma transferência VPN também copia buffers, agenda threads ou interrupções, verifica políticas e atravessa a rede. Essas partes costumam dominar, e por isso uma primitiva mais rápida nem sempre produz um túnel mais rápido.

openssl speed -evp aes-256-gcm
openssl speed -evp sha1

Esses dois comandos dão uma comparação local aproximada das primitivas na máquina à sua frente, e são honestos ao dizer que são microbenchmarks. Não dizem nada sobre a vazão do seu túnel, e nunca deveriam ser citados como tal.

Depois meça a carga que importa, mantendo todo o resto constante: mesmo endpoint, mesmos tamanhos de pacote, mesmo transporte, mesma política de compressão. Se a mudança de perfil também alterou o transporte ou o local de processamento, o resultado descreve esse pacote e não a criptografia.

Tenha também o objetivo em vista. Um caminho de dados com capacidade criptográfica de sobra ainda pode estar limitado pela latência porque a aplicação espera idas e voltas, e ganhos de capacidade bruta não corrigem um protocolo falador. Meça a configuração suportada e aprovada pela política como um todo, e trate «menos caixas deve ser mais rápido» como a hipótese que é. A pergunta útil não é se a cifra custa algo, mas se o custo aparece na medição que realmente lhe importa.

Artigos relacionados