CFB1 contra CFB8 contra CFB128: é o tamanho do feedback, não o da chave

Um nome como AES-256-CFB1 carrega dois números, e eles respondem a perguntas diferentes. O 256 é o comprimento da chave AES. O 1 é o feedback do CFB, ou seja, o tamanho do segmento, uma propriedade de como o modo avança o seu estado. Lido como comprimento de chave, o 1 faz o nome parecer uma configuração errada catastrófica, e é por isso que a pergunta volta sempre.

Decida qual das três grandezas está a ver antes de julgar o nome: tamanho da chave, tamanho do bloco ou tamanho do segmento. Só a primeira é um parâmetro de segurança no sentido habitual.

Três números, três grandezas

O AES aceita chaves de 128, 192 ou 256 bits e tem um bloco de 128 bits, escolha o que escolher. O tamanho do bloco pertence ao AES, não ao modo. O sufixo CFB é a terceira grandeza: quantos dados o modo consome e devolve por passo. A documentação AES do OpenSSL lista esses tamanhos de deslocamento explicitamente para as variantes CFB.

O CFB1 devolve um bit de cada vez, o CFB8 um byte, o CFB128 um bloco completo. Os três usam internamente a mesma cifra de bloco de 128 bits; o que muda é quantos bits de cada bloco calculado são usados por operação. Por isso o sufixo mexe no custo e no comportamento de buffering, não na força da chave.

Porque é que o tamanho do bloco nunca muda

O AES é uma cifra de bloco com um bloco fixo de 128 bits, e os modos são construções edificadas à volta dele. Nenhum deles encolhe o bloco para corresponder ao tamanho do segmento. Uma implementação CFB1 continua a calcular um bloco AES completo e retira um bit do resultado. Os outros bits são descartados nesse passo, e é exactamente aí que vive o custo de eficiência.

Assim, um feedback de um bit não implica uma chave de um bit, e um nome não pode ser ordenado pelo sufixo. O CFB128 não é quatro vezes mais forte do que o CFB32; processa segmentos maiores.

O que o tamanho do segmento realmente muda

O tamanho do segmento muda quanto texto cifrado é devolvido por passo e quanto texto simples cada passo pode transportar. Também muda a propagação de erros e o comportamento de buffering, o que importa para uso do tipo fluxo. Segmentos orientados a bytes alinham-se com buffers, os orientados a bits não.

Na prática, é o protocolo que escolhe o modo, não o operador. Um canal de dados VPN usa a construção que o seu protocolo especifica, com a sua própria protecção de integridade, e uma listagem de biblioteca só diz que nomes existem.

Ler uma etiqueta CFB sem qualificação

Uma etiqueta CFB sem qualificação precisa do contexto da implementação. Nos cabeçalhos do OpenSSL 1.0.2, EVP_aes_128_cfb é uma macro para EVP_aes_128_cfb128, com aliases correspondentes para chaves de 192 e 256 bits. Isso é uma convenção de nomes de API de um ramo, não a afirmação de que todas as bibliotecas, formatos de ficheiro ou GUI expandem a abreviatura da mesma forma. Verifique o cabeçalho ou a documentação da versão que tem à frente.

Se um perfil antigo diz CFB e o par aceita, os parâmetros negociados ficam registados em algum lugar: num log, num dump de configuração, numa resposta de API. Leia esses em vez de deduzir o tamanho do segmento a partir de uma string de visualização.

O que o nome de um modo não lhe diz

O nome descreve comportamento de cifra e nada mais. Uma VPN continua a precisar de protecção de integridade, derivação de chaves e autenticação do par, e o CFB não fornece nenhuma delas. Trocar CFB8 por CFB1 também não é uma mudança cosmética: o comportamento no fio difere e ambos os lados têm de suportar a mesma construção. Nem um nome numa biblioteca prova que o gateway implementado o aceita para o seu canal de dados.

Para tudo o que é mantido, use o arranjo completo de protecção do protocolo e a política do operador, e registe versões de biblioteca e gateway, a opção exacta e o resultado negociado. O nome antigo explica o que está a ler; não justifica reviver a configuração.