Кратко

  • RFC 1969 использовал последний блок шифротекста одного PPP-пакета как начальное состояние CBC для следующего: меньше служебных данных, но зависимость от порядка за пределами пакета.
  • Открыто согласованный 64-битный nonce проходил через общий ключ DES и задавал первую цепочку. Явный 16-битный номер замечал разрыв, но не удостоверял содержимое или сторону.
  • При потере N-1 пакет N не расшифровывается. Если его шифротекст получен, последний блок позволяет прочитать N+1; состояние восстановлено, два открытых текста — нет.

Нечитаемый пакет как часть состояния

RFC 1969 разбирает три пакета. N-1 потерян, N и N+1 приняты. Для расшифрования N нужен последний блок N-1, которого нет. Но для N+1 требуется последний блок шифротекста N, а он доступен без знания открытого текста N.

Поэтому при ошибке нельзя автоматически выбросить весь пакет N. Его данные недоступны, но хвост сохраняет криптографическую позицию. Потеря создаёт «тень» длиной в ещё один пакет, а не бесконечный отказ.

Такое recovery возвращает возможность вычислять последующие блоки. Оно не восстанавливает N-1 и N, не подтверждает приём PPP и не создаёт квитанцию приложения. Синхронизация и данные — разные результаты.

Почему состояние пересекло границу PPP

Опубликованный в июне 1996 года как Informational, RFC 1969 задавал протокол DES-CBC для PPP Encryption Control Protocol. После перехода ECP в Opened шифровались Protocol и Information fields, кроме пакетов LCP и ECP, с 56-битным ключом.

После первого пакета значение C[0] бралось из последнего блока предыдущего шифротекста. Не требовалось передавать новый вектор с каждым датаграммом, а повторяющийся открытый текст не начинался всякий раз с одинакового состояния. Цена — пакет перестал быть самодостаточной единицей расшифрования.

PPP видел рамку, CBC — непрерывный поток. Общая история согласования ECP описана в RFC 1968; здесь важна уже выбранная однонаправленная цепочка.

Открытый nonce и ключ вне спецификации

Опция DESE длиной десять октетов содержала восьмиоктетный Initial Nonce. Принимающая сторона предлагала его для первого пакета, который peer отправит в её сторону. Документ рекомендовал новый nonce при каждом согласовании и приводил пример на основе секунд и наносекунд.

Nonce передавался открыто. Настоящее первое значение цепочки было E[k](nonce), вычисленное с общим ключом DES. Nonce отвечал за изменяемость старта, ключ — за секретность, предыдущий шифротекст — за продолжение. Наблюдаемый nonce не являлся секретом.

Способ доставки общего ключа RFC оставил за рамками: обычно ручная настройка, возможно с учётом PPP authentication или Multilink Endpoint Identifier. Успешная расшифровка подтверждает совместимый ключ и состояние, а не юридическую или пользовательскую личность отправителя.

Номер последовательности показывает только разрыв

16-битный Sequence Number начинался с нуля после Opened. Несовпадение соседних значений предупреждало, что сохранённый хвост не относится к непосредственному предшественнику.

Счётчик не проверял содержимое и не защищался отдельным MAC в RFC 1969. Потеря, перестановка, локальное отбрасывание и активное вмешательство могли выглядеть одинаково. Источник пакета тоже не удостоверялся.

В RFC 2419 граница названа прямо: только confidentiality, без integrity, authentication и nonrepudiation; без гарантии против replay, cut-and-paste и active tampering. Полученный открытый текст не обязательно остался неизменным.

Восемь октетов меняют MRU

DES работает блоками по восемь октетов. RFC 1969 разрешал случайный хвост для протоколов с собственной длиной — IP, IPX, XNS, CLNP — и self-describing padding там, где лишние байты меняли смысл. Обе стороны должны были одинаково классифицировать внутренний протокол.

Самоописывающийся метод был взят из RFC 1570. Даже уже выровненный текст мог потребовать ещё восемь октетов, если его конец походил на padding. Пример MRU показывает рост до десяти октетов: при PFC и исходном MRU, кратном восьми, однооктетный Protocol field требует семь байт padding; добавляются два байта последовательности и внешнее оформление. Согласование DESE само MRU не повышало.

RFC 2419 устранил различие толкований

Страница RFC 2419 фиксирует, что он obsoletes RFC 1969. DESE-bis потребовал одинаковый self-describing padding для всех открытых пакетов независимо от отдельной PPP SDP option, установил максимум восемь октетов и рекомендовал отбрасывать кадр с неверным шаблоном.

Поскольку старый и новый получатель могли по-разному истолковать один результат расшифрования, DESE-bis получил ECP Type 3. Старый Type 1 стал deprecated и должен был отвергаться. Реестр PPP IANA сохраняет это разделение.

Это не замена DES на Triple-DES. 3DESE описан отдельно в RFC 2420 и получил Type 2. RFC 2419 исправлял padding и совместимость, вводил несовместимый номер, переходил в Standards Track и яснее описывал безопасность.

Экспортное право осталось строкой в стандарте

RFC 1969 ссылался на исходный код DES-ECB, но сообщал, что законы США об экспорте запрещают включить готовый к компиляции код. RFC 2419 сохранил фразу. Она прямо показывает влияние режима криптографического экспорта 1990-х на содержание документа.

Она не доказывает законность продукта, происхождение реализации, её экспорт или распространение. Отсутствие кода в RFC не означает отсутствие программ и ничего не говорит о конкретной защите.

IETF Datatracker и RFC Editor подтверждают документ и преемника. Страница errata при сохранении не дала пригодного текста, поэтому нулевой набор исправлений не заявляется.

Не одна галочка, а цепочка квитанций

Нужно отдельно хранить направление и Type ECP, отпечаток nonce и ссылку на ключ, Sequence Number, использованный хвост, расшифрование, padding и решение PPP по RFC 1661. Доставка приложению — следующий независимый факт.

Подход Heng Lu в Running-Code Primacy требует соединять текст с наблюдаемой работой до расширения вывода. Minimum Initial Specification оставляет полю минимальные полномочия. Reality Layers и Reality, Not Advocacy не дают превратить символ в результат или придумать мотив. Это редакционная рамка, не источник истории DESE.