Resumen

  • RFC 1969 usó el último bloque cifrado de cada paquete como entrada CBC del siguiente; ahorró un nuevo inicio por paquete a cambio de una dependencia externa al datagrama.
  • El nonce inicial de 64 bits viajaba en claro y se cifraba con la clave DES compartida. El número de secuencia de 16 bits hacía visible un salto, pero ninguno de los dos campos autenticaba contenido o extremo.
  • Si falta N-1, el texto de N no puede recuperarse. Si llegó el cifrado de N, su bloque final permite descifrar N+1: vuelve el estado, no los dos textos perdidos.

No descifrar no significaba no usar

El receptor ve un salto de secuencia. Falta N-1, mientras N ha llegado con todos sus octetos. En un diseño por paquetes sería razonable tratar N como una unidad fallida y descartarla. RFC 1969 obliga a mirar otra cosa: el último bloque de su ciphertext.

En CBC, el primer bloque claro de N necesita el último bloque cifrado de N-1. Sin él, N es ilegible. Pero el primer bloque de N+1 necesita el último bloque cifrado de N, que sí está disponible sin descifrar N. Así termina la sombra: un paquete perdido causa la pérdida de su propio texto y del texto del sucesor, no una desincronización perpetua.

La palabra recuperación debe conservar esa escala. Se recupera la capacidad de calcular paquetes posteriores. No se reconstruyen N-1 ni N, no se confirma que PPP entregó nada y no aparece un recibo de aplicación. El ciphertext de N es una pieza de estado, no una copia de los datos perdidos.

Una continuidad que ignoró la frontera visible

RFC 1969, publicado como Informational en junio de 1996, detalló un protocolo DES para el marco ECP de PPP. Después de que ECP quedara Opened, el emisor aplicaba DES-CBC con una clave de 56 bits al Protocol field y al Information field, con el padding necesario. El Address y Control field quedaban fuera.

La decisión distintiva era continuar CBC más allá de cada paquete. Para el segundo y posteriores, C[0] era el último bloque cifrado del paquete anterior. Se evitaba transportar una inicialización nueva con cada datagrama y se reducían patrones repetidos, pero el orden pasaba a formar parte del cálculo criptográfico.

PPP seguía viendo paquetes; el cifrador veía una cadena. Esa divergencia explica el coste de recuperación. También delimita este artículo frente a RFC 1968: la negociación general, los estados de ECP y la elección de algoritmo son antecedentes, no el objeto. Aquí importa qué ocurre una vez fijada una secuencia DESE.

Lo público inicia; lo secreto protege

La opción DESE ocupaba diez octetos. Ocho correspondían al Initial Nonce ofrecido por el receptor para el primer paquete que su par enviaría hacia él. El documento aconsejaba cambiarlo en cada negociación y proponía combinar tiempo en segundos y nanosegundos para evitar inicios repetidos.

El nonce se transmitía en claro. La entrada inicial real era E[k](nonce), no el nonce desnudo. La clave DES compartida aportaba el secreto; el nonce, una base variable; el bloque final de cada paquete, la continuidad posterior. Confundir esas tareas convierte una observación pública en una credencial que nunca fue.

Además, RFC 1969 no establecía cómo compartir la clave. Mencionaba la configuración manual y posibles factores como la autenticación PPP o el Multilink Endpoint Identifier. Ver el nonce prueba que se negoció una cifra. Descifrar prueba que alguna contraparte tenía clave y estado compatibles. Ninguna observación identifica por sí sola a una empresa, persona o equipo autorizado.

Un contador no es un autenticador

El Sequence Number explícito tenía 16 bits y comenzaba en cero al abrir ECP. Permitía detectar una discontinuidad entre paquetes consecutivos y evitar que el receptor aplicara una cola antigua al cifrado equivocado.

No estaba protegido por un MAC definido en la especificación, ni comprobaba el contenido. Un salto podía proceder de pérdida, reordenamiento, corrupción, descarte local o acción hostil. El valor tampoco mostraba quién transmitió el paquete. Era evidencia de orden esperado, no un sello.

El documento sucesor, RFC 2419, hizo explícita la frontera: confidencialidad solamente; sin integridad, autenticación o no repudio; sin garantía frente a replay, cut-and-paste o manipulación activa. Que un ciphertext produzca un plaintext no demuestra que ese plaintext no fue influido por una modificación.

El padding también era una decisión de interoperabilidad

DES trabaja con bloques de ocho octetos. RFC 1969 permitía basura aleatoria al final de protocolos con longitud interna —IP, IPX, XNS y CLNP— y reservaba padding autodescriptivo para protocolos en los que esos octetos cambiarían el significado. La clasificación dependía del protocolo encapsulado.

Esa flexibilidad introducía ambigüedad entre implementaciones. El método autodescriptivo procedía de RFC 1570. Incluso un texto ya alineado podía necesitar ocho octetos completos si sus últimos valores parecían un sufijo de padding. El receptor debía saber cuándo retirar esos bytes sin dañar datos reales.

La cuenta del MRU muestra el coste. Con PFC y un MRU original múltiplo de ocho, un paquete lleno más un Protocol field de un octeto necesita siete octetos de padding. Tras añadir la secuencia de dos octetos y el efecto del protocolo exterior, el Information field DESE puede crecer diez octetos. Negociar DESE no eleva automáticamente el MRU porque las opciones PPP son independientes.

La versión 2 corrigió el límite, no cambió a 3DES

RFC 2419 obsoletó RFC 1969 con una regla uniforme: padding autodescriptivo para todos los textos, independiente de la opción SDP de PPP, con máximo fijo de ocho octetos. Si la secuencia de relleno no coincide, el receptor debe descartar la trama.

Como la nueva interpretación podía resultar incompatible con la anterior, DESE-bis recibió ECP Type 3. El Type 1 quedó deprecado; una implementación nueva no debía ofrecerlo y debía rechazarlo. El registro PPP de IANA conserva ambos estados.

No fue una sustitución de DES por Triple-DES. RFC 2420 definió 3DESE de forma separada con Type 2. RFC 2419 unificó el padding, evitó la mezcla silenciosa mediante otro número, pasó a Standards Track y describió con mayor rigor sus límites de seguridad.

La huella legal en una especificación técnica

RFC 1969 señalaba que había código DES-ECB en una referencia, pero que las leyes de exportación de Estados Unidos impedían incluir código listo para compilar. RFC 2419 conservó la frase. Esa línea prueba que el régimen de exportación criptográfica de los años noventa afectó lo que podía imprimirse en un RFC.

No prueba la situación legal de un producto, el origen de una implementación ni su despliegue. Ausencia de código y ausencia de software no son equivalentes. Tampoco dice nada sobre la fortaleza operativa de una instalación concreta.

El Datatracker y RFC Editor sostienen identidad, fecha, estado y sucesión. La captura de la página de erratas de RFC 1969 no ofreció un cuerpo utilizable; por eso no se afirma que la lista esté vacía.

Seis hechos que no deben fundirse

Una bitácora útil separa opción ECP y dirección; nonce y referencia de clave; secuencia observada; cola cifrada usada como estado; descifrado y padding; aceptación PPP bajo RFC 1661. La entrega a la aplicación es un recibo posterior.

La lectura sigue la disciplina de Running-Code Primacy de Heng Lu: el texto y la operación observable deben encontrarse antes de ampliar una conclusión. Minimum Initial Specification mantiene cada campo en su función mínima. Reality Layers y Reality, Not Advocacy ayudan a no transformar símbolos en resultados ni estructuras en relatos de intención. Son un método editorial, no evidencia histórica del protocolo.