Especificamente, estou perguntando se o texto cifrado pode incluir uma sequência de bytes como 170303, que é um possível cabeçalho de registro TLS.
Normalmente, o aplicativo que analisa o fluxo de bytes TCP delimita o registro TLS analisando o cabeçalho e extraindo o comprimento em octetos do 4º e 5º byte após o início do cabeçalho. Então, presumo que ele avance e tente ler o próximo registro no deslocamento calculado pelo cabeçalho analisado anteriormente.
Minha pergunta é: a implementação do AES 256 GCM para TLS 1.3 impôs alguma restrição à saída de criptografia? A RFC não faz menção a isso. Pode haver um registro TLS que comece com um header 170303xxxx, mas também tenha 170303como parte de seu texto cifrado?
Exceto por alguns modos especiais (e muito raros) de 'preservação de formato', todos os algoritmos de criptografia modernos, incluindo AES-GCM, podem lidar com qualquer sequência de bytes em texto simples e produzir qualquer sequência de bytes como texto cifrado. (Na verdade, os algoritmos podem lidar principalmente com qualquer sequência de bits , mas as implementaçõesem computadores orientados a bytes, a maioria lida apenas com bytes, especialmente porque eles geralmente são escritos em C e o suporte C para dados de subbyte depende da implementação. AES-GCM é uma espécie de exceção; consiste em AES-CTR mais GMAC, ambos os quais podem lidar com qualquer bit, mas o NIST, no entanto, especifica o GCM para lidar com apenas bytes de 8 bits. Possivelmente porque eles tiveram problemas no passado com implementações de criptografia supostamente testadas para conformidade que ainda falham em casos extremos, e praticamente ninguém hoje em dia precisa ou mesmo deseja criptografia que não seja de bytes.)
Quando restrições de dados se aplicam - como enviar texto cifrado por e-mail não-MIME ou armazená-lo em determinados bancos de dados que não suportam dados binários, também conhecidos como 'blob' - é comum codificar o texto cifrado em um formato que satisfaça essas restrições, como hex, base64, base64 seguro para URL, base32, base58, base95, etc. No entanto, SSL/TLS (todas as versões) não exige isso; no nível do registro permite qualquer sequência de bytes no corpo e, sim, cada registro é portanto delimitado SOMENTE pelo comprimento especificado no cabeçalho do registro e nunca pelo seu conteúdo. ( Alguns registros, como aqueles no subprotocolo de handshake, têm restrições em seu conteúdo, mas se criptografados, eles se aplicam ao texto simples antes da criptografia ou após a descriptografia, não ao texto cifrado.)
Qualquer cifra de bloco que possa criptografar dados binários arbitrários deve ser capaz de produzir todas as sequências de bytes em sua saída, ou sua saída deve ser maior que sua entrada para pelo menos algumas entradas. Mas o AES-GCM produz saída do mesmo tamanho e aceita entrada binária.
Se houvesse alguma restrição, teria menos entropia por byte de saída do que entrada totalmente aleatória. ou seja, haveria menos de 2 ^ n valores de saída possíveis, onde n é o comprimento da saída em bits. Isso significaria que não seria possível codificar exclusivamente cada um dos 2 ^ n fluxos de entrada possíveis com esse comprimento.
(Este princípio é verdadeiro em geral, não apenas para cifras, e é por isso que você não pode compactar dados aleatórios arbitrários sem perdas. Freqüentemente chamado de princípio do pombo. https://en.wikipedia.org/wiki/Pigeonhole_principle )