Вернер Кох (Werner Koch), основной разработчик и создатель проекта GnuPG (GNU Privacy Guard), основал проект LibrePGP, сосредоточенный на развитии обновлённой спецификации, альтернативной стандарту OpenPGP. Форк был создан в ответ на изменения, намеченные рабочей группой IETF для внесения в следующее обновление спецификации OpenPGP (RFC-4880) и воспринятые Кохом как сомнительные с точки зрения сохранения совместимости и обеспечения безопасности. Поддержавшие форк разработчики проектов GnuPG, RNP (реализация OpenPGP от Thunderbird) и Gpg4win опасаются, что намеченные изменения окажутся губительны для существующих внедрений приложений на базе OpenPGP, пользователи которых рассчитывают на стабильность спецификации в длительной перспективе и не готовы мириться с изменениями, нарушающими совместимость.
LibrePGP включает полезные улучшения, последние годы развивавшиеся для будущего варианта спецификации OpenPGP, но при этом исключает изменения, негативно влияющие на обеспечение совместимости. Например, по сравнению с действующим стандартом RFC-4880 в LibrePGP приняты такие возможности, как:
• Поддержка алгоритма шифрования Camellia (RFC-5581),
• Расширения ECC (Elliptic Curve Cryptography) для OpenPGP (RFC-6637).
• Обязательная поддержка хэшей SHA2-256 (SHA-1 и MD5 отнесены к категории не рекомендованных, а возможность расшифровки данных без версификации целостности отнесена к категории полностью устаревших).
• Увеличение до 256 бит размера проверочного слепка (fingerprint).
• Поддержка схемы цифровых подписей EdDSA и эллиптических кривых BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 и X448.
• Поддержка алгоритма CRYSTALS-Kyber, устойчивого к подбору на квантовых компьютерах.
• Поддержка режимов аутентифицированного шифрования OCB (Offset codebook mode).
• Реализация пятой версии формата цифровых подписей с защитой метаданных.
• Поддержка расширенных субпакетов с цифровыми подписями.
________________
Основные элементы критики новой спецификации OpenPGP:
• Рабочая группа IETF вместо постепенного инкрементального обновления спецификации попыталась заново переизобрести стандарт и внести в него значительные изменения, нарушающие совместимость.
• Навязывание поддержки симметричного режима шифрования GCM (Galois/Counter Mode), который трудно реализовать правильно, игнорируя при этом режим OCB (Offset codebook mode), патенты на который истекли несколько лет назад.
• Добавление опциональных пакетов со случайным добавочным заполнением для защиты от анализа трафика. По мнению создателей LibrePGP, подобные пакеты с непроверяемым начальным случайным заполнением создают угрозу использования для создания скрытых каналов передачи данных и обхода систем предотвращения утечек данных. Ранее идея включения добавочного заполнения отвергалась, как являющаяся объектом не уровня шифрования, а уровня приложения.
• Применение модифицированной схемы шифрования ECDH (изменение формата OID), вместо использования уже описанного в RFC-6637 и реализованного в PGP и GnuPG варианта.
• Удаление некоторых используемых на практике возможностей, таких как классический метод отзыва ключей, флаг "m" для пометки MIME-данных и флаг "t" для отделения текстовых данных от бинарных (на смену флагу "t" пришёл флаг "u" для текста в кодировке UTF-8).
• Отказ включать в новый формат подписей защиту метаданных подписанного файла (например, можно не нарушая подписи изменить имя файла).
• Сомнительная возможность добавления "соли" к подписям (Salted signature) для усиления защиты от коллизионных атак с заданным префиксом. Значение с солью может использоваться как неотключаемый скрытый канал для передачи 32 байт данных в подписи.
• Смещение стандарта в сторону основного использования для online-коммуникации, игнорируя потребности для длительного хранения данных.
Сторонники OpenPGP уже опубликовали критику на критику. В итоге, если не удастся найти компромисс раскол может привести к нарастанию несовместимостей в реализациях OpenPGP/LibrePGP. Частично для решения этой проблемы разработчики OpenPGP зафиксировали пятую версию формата подписей в виде совместимом с LibrePGP и перешли к работе над шестой версией.
LibrePGP включает полезные улучшения, последние годы развивавшиеся для будущего варианта спецификации OpenPGP, но при этом исключает изменения, негативно влияющие на обеспечение совместимости. Например, по сравнению с действующим стандартом RFC-4880 в LibrePGP приняты такие возможности, как:
• Поддержка алгоритма шифрования Camellia (RFC-5581),
• Расширения ECC (Elliptic Curve Cryptography) для OpenPGP (RFC-6637).
• Обязательная поддержка хэшей SHA2-256 (SHA-1 и MD5 отнесены к категории не рекомендованных, а возможность расшифровки данных без версификации целостности отнесена к категории полностью устаревших).
• Увеличение до 256 бит размера проверочного слепка (fingerprint).
• Поддержка схемы цифровых подписей EdDSA и эллиптических кривых BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 и X448.
• Поддержка алгоритма CRYSTALS-Kyber, устойчивого к подбору на квантовых компьютерах.
• Поддержка режимов аутентифицированного шифрования OCB (Offset codebook mode).
• Реализация пятой версии формата цифровых подписей с защитой метаданных.
• Поддержка расширенных субпакетов с цифровыми подписями.
________________
Основные элементы критики новой спецификации OpenPGP:
• Рабочая группа IETF вместо постепенного инкрементального обновления спецификации попыталась заново переизобрести стандарт и внести в него значительные изменения, нарушающие совместимость.
• Навязывание поддержки симметричного режима шифрования GCM (Galois/Counter Mode), который трудно реализовать правильно, игнорируя при этом режим OCB (Offset codebook mode), патенты на который истекли несколько лет назад.
• Добавление опциональных пакетов со случайным добавочным заполнением для защиты от анализа трафика. По мнению создателей LibrePGP, подобные пакеты с непроверяемым начальным случайным заполнением создают угрозу использования для создания скрытых каналов передачи данных и обхода систем предотвращения утечек данных. Ранее идея включения добавочного заполнения отвергалась, как являющаяся объектом не уровня шифрования, а уровня приложения.
• Применение модифицированной схемы шифрования ECDH (изменение формата OID), вместо использования уже описанного в RFC-6637 и реализованного в PGP и GnuPG варианта.
• Удаление некоторых используемых на практике возможностей, таких как классический метод отзыва ключей, флаг "m" для пометки MIME-данных и флаг "t" для отделения текстовых данных от бинарных (на смену флагу "t" пришёл флаг "u" для текста в кодировке UTF-8).
• Отказ включать в новый формат подписей защиту метаданных подписанного файла (например, можно не нарушая подписи изменить имя файла).
• Сомнительная возможность добавления "соли" к подписям (Salted signature) для усиления защиты от коллизионных атак с заданным префиксом. Значение с солью может использоваться как неотключаемый скрытый канал для передачи 32 байт данных в подписи.
• Смещение стандарта в сторону основного использования для online-коммуникации, игнорируя потребности для длительного хранения данных.
Сторонники OpenPGP уже опубликовали критику на критику. В итоге, если не удастся найти компромисс раскол может привести к нарастанию несовместимостей в реализациях OpenPGP/LibrePGP. Частично для решения этой проблемы разработчики OpenPGP зафиксировали пятую версию формата подписей в виде совместимом с LibrePGP и перешли к работе над шестой версией.