Обзор
В этом документе описываются важные вопросы, которые необходимо учитывать при предложении замены или добавления к нашей асимметричной криптографии на основе ElGamal.
Это информационный документ.
Мотивация
ElGamal устарел и медленен, и существуют лучшие альтернативы.
Однако перед тем, как добавить или перейти на любой новый алгоритм, необходимо решить несколько вопросов.
В этом документе освещаются эти нерешённые проблемы.
Предварительное исследование
Любой, кто предлагает новую криптографию, должен быть знаком с нижеследующими документами:
- Предложение 111 NTCP2
- Предложение 123 LS2
- Предложение 136 экспериментальные типы подписей
- Предложение 137 опциональные типы подписей
- Темы обсуждений для каждого из вышеперечисленных предложений, ссылки на которые находятся внутри
- Приоритеты предложений 2018 года
- Предложение ECIES
- Обзор новой асимметричной криптографии
- Обзор низкоуровневой криптографии
Использование асимметричной криптографии
Напомним, что ElGamal используется нами для:
Сообщений построения туннеля (ключ находится в RouterIdentity)
Шифрования сообщений I2NP между маршрутизаторами и в netDb (ключ находится в RouterIdentity)
Сквозного шифрования на стороне клиента ElGamal+AES/SessionTag (ключ находится в LeaseSet, ключ Destination не используется)
Эфемерного DH для NTCP и SSU
Проектирование
Любое предложение по замене ElGamal на другой алгоритм должно содержать следующие детали.
Спецификация
Любое предложение по новой асимметричной криптографии должно полностью описывать следующие аспекты.
1. Общие положения
Ответьте на следующие вопросы в своём предложении. Обратите внимание, что это может потребовать отдельного предложения, отличного от деталей в пункте 2) ниже, поскольку оно может противоречить существующим предложениям 111, 123, 136, 137 или другим.
- Для каких из вышеуказанных случаев 1–4 вы предлагаете использовать новую криптографию?
- Если для 1) или 2) (маршрутизатор), где будет находиться открытый ключ — в RouterIdentity или в свойствах RouterInfo? Вы собираетесь использовать тип криптографии в сертификате ключа? Полностью укажите. Обоснуйте своё решение в любом случае.
- Если для 3) (клиент), планируете ли вы хранить открытый ключ в Destination и использовать тип криптографии в сертификате ключа (как в предложении ECIES), или хранить его в LS2 (как в предложении 123), или использовать иной способ? Полностью укажите и обоснуйте своё решение.
- Для всех применений — как будет объявляться поддержка? Если для 3), будет ли это в LS2 или где-то ещё? Если для 1) и 2), будет ли это аналогично предложениям 136 и/или 137? Полностью укажите и обоснуйте свои решения. Вероятно, потребуется отдельное предложение для этого.
- Полностью опишите, как и почему это будет обратно совместимо, и детально пропишите план миграции.
- Какие нереализованные предложения являются предпосылками для вашего предложения?
2. Конкретный тип криптографии
Ответьте на следующие вопросы в своём предложении:
- Общая информация о криптографии, конкретные кривые/параметры, полностью обоснуйте свой выбор. Приведите ссылки на спецификации и другую информацию.
- Результаты тестов производительности по сравнению с ElGamal и другими альтернативами, если применимо. Включите шифрование, расшифрование и генерацию ключей.
- Доступность библиотек на C++ и Java (OpenJDK, BouncyCastle и сторонние) Для сторонних или не-Java библиотек укажите ссылки и лицензии
- Предлагаемые номера типа криптографии (в экспериментальном диапазоне или нет)