Resumo

  • A RFC 1969 transformou o último bloco cifrado de um pacote no estado inicial CBC do próximo, economizando uma nova inicialização por pacote e criando dependência de ordem.
  • O nonce de 64 bits trafegava em claro e era cifrado com a chave DES compartilhada para iniciar a corrente; o número explícito de 16 bits detectava descontinuidade, mas não autenticava mensagem ou ponta.
  • Se N-1 se perde, N não pode ser decifrado. Se o ciphertext de N chegou, seu bloco final permite abrir N+1; sincronização retorna, os dois textos claros não.

O pacote que falhou e mesmo assim precisava ser guardado

Na seção de recuperação da RFC 1969, N-1 desaparece e N chega corretamente. O receptor não consegue obter o texto de N, pois lhe falta o último bloco cifrado de N-1. Descartar N, porém, prolongaria a falha: seu próprio bloco final é a entrada necessária para N+1.

O mecanismo funciona porque CBC não precisa conhecer o texto de um bloco anterior para usar seu ciphertext. Para o primeiro bloco de N+1, basta conservar a cauda cifrada de N. Assim, uma perda apaga dois textos claros — o pacote perdido e o sucessor indecifrável — mas não condena toda a sessão.

“Recuperação” descreve a corrente computacional. Não há reconstrução dos dados, retransmissão ou confirmação de que o PPP e a aplicação receberam algo. Essa diferença deve sobreviver a qualquer painel operacional.

Eficiência com memória fora do datagrama

Publicada como Informational em junho de 1996, a página da RFC 1969 registra o protocolo DES-CBC de dados do ECP. Depois de ECP chegar a Opened, o emissor cifrava o Protocol field e o Information field, exceto LCP e ECP. A história geral da negociação fica na RFC 1968; aqui interessa o estado já ativo.

No primeiro pacote, há um começo negociado. Nos seguintes, C[0] é o último bloco cifrado do pacote anterior. A corrente evita carregar um vetor novo em cada datagrama e reduz a repetição de padrões, mas faz a decifragem depender de material externo ao pacote presente.

É uma troca direta: menos estado explícito por pacote, mais necessidade de preservar ordem e contexto. A fronteira PPP organiza a transmissão; não encerra a memória criptográfica.

Nonce público, chave externa

A opção DESE tinha dez octetos, oito deles para o Initial Nonce. O receptor oferecia o valor que o par usaria no primeiro pacote enviado naquela direção. A especificação recomendava um nonce diferente a cada negociação, inclusive sugerindo uma combinação de segundos desde 1970 e nanossegundos.

Ele era enviado em claro. A entrada inicial verdadeira era E[k](nonce), produzida pela chave DES compartilhada de 56 bits. Nos pacotes seguintes, a cauda cifrada assumia essa função. Nonce traz variação; chave traz segredo; ciphertext anterior traz continuidade.

A RFC deixou a distribuição do segredo fora do escopo, citando configuração manual e possíveis fatores como autenticação PPP ou Endpoint Identifier. Portanto, observar o nonce não prova posse da chave. Decifrar prova compatibilidade de chave e estado, não a identidade institucional do emissor.

A sequência só acusa o salto

O Sequence Number de 16 bits começava em zero após a abertura de ECP. Uma descontinuidade alertava o receptor de que sua cauda anterior não correspondia necessariamente ao predecessor do pacote recebido.

O campo não verificava o conteúdo e não tinha autenticação definida pela RFC. Não distinguia perda, reordenação, descarte local ou interferência ativa. Não dizia quem enviou o pacote. Era um recibo de posição esperada, não de integridade.

A sucessora RFC 2419 formulou a fronteira: apenas confidencialidade, sem integridade, autenticação ou não repúdio, e sem garantia contra replay, cut-and-paste ou adulteração ativa. Ciphertext decifrável não é sinônimo de mensagem intacta.

Oito octetos viram uma conta de MRU

DES exige blocos de oito. A RFC 1969 permitia lixo final aleatório quando o protocolo interno possuía comprimento explícito, como IP, IPX, XNS e CLNP. Nos casos em que bytes extras alteravam o significado, usava padding autodescritivo. A regra dependia de classificar corretamente o protocolo encapsulado.

O método autodescritivo vinha da RFC 1570. Um texto já alinhado podia precisar de mais oito octetos se terminasse com uma sequência parecida com padding. E o exemplo de MRU acumulava dez octetos: com PFC e MRU múltiplo de oito, um Protocol field de um octeto exigia sete de padding; somavam-se dois de sequência e o efeito do protocolo externo. Negociar DESE não aumentava automaticamente o MRU, pois as opções PPP eram independentes.

A versão 2 fechou uma ambiguidade

A página da RFC 2419 registra que ela tornou a RFC 1969 obsoleta. DESE-bis passou a exigir padding autodescritivo em todos os textos, independentemente da opção SDP do PPP, fixou o máximo em oito e recomendou descartar a trama cujo padrão fosse inválido.

Como a interpretação podia divergir da versão anterior, DESE-bis recebeu ECP Type 3. O Type 1 foi depreciado e deveria ser rejeitado. O registro PPP da IANA conserva Type 1 como Deprecated (DESE), Type 2 para 3DESE e Type 3 para DESE-bis.

Isso importa porque a RFC 2419 não trocou DES por Triple-DES. O 3DESE pertence à RFC 2420. A substituição tratou de padding, interpretação interoperável, numeração incompatível, passagem à Standards Track e limites de segurança mais claros.

A lei entrou no registro técnico

A RFC 1969 dizia que havia código DES em modo ECB na bibliografia, mas que leis de exportação dos Estados Unidos impediam incluir código pronto para compilação. A RFC 2419 manteve a frase. É evidência direta de que o regime criptográfico dos anos 1990 moldou o conteúdo editorial do RFC.

Não é evidência sobre a legalidade, origem ou adoção de uma implementação particular. Falta de código no documento não prova falta de software, e muito menos segurança.

O Datatracker e o RFC Editor sustentam identidade e sucessão. A página de errata não forneceu corpo utilizável na captura; por isso não se declara uma lista vazia.

Um recibo para cada fronteira

O registro deve separar opção ECP e direção, impressão do nonce e referência de chave, sequência observada, cauda usada como C[0], resultado da decifragem, validação do padding e decisão do PPP sob a RFC 1661. A entrega à aplicação vem depois.

O método segue Running-Code Primacy de Heng Lu: especificação e operação observável não são a mesma prova. Minimum Initial Specification limita a autoridade do campo à sua função. Reality Layers e Reality, Not Advocacy impedem elevar símbolos a resultados ou inventar motivações. São lentes editoriais, não fontes da história do protocolo.