Удалите ненужную криптографию с открытым ключом GPG под капотом

Предпосылки :

  1. Некоторые существующие программы, такие как git-приложение ( шифрование git-приложения ) и пропуск , делегирование криптографии GPG , «полная и бесплатная реализация стандарта OpenPGP ». В частности, эти программы полагаются на ключевые идентификаторы GPG как способ взаимодействия с GPG:

    Хотя полагаться на GPG хорошо и похвально, конкретный способ, которым это делается (с помощью идентификаторов ключа GPG), приводит к, возможно, ненужному использованию криптографии с открытым ключом под капотом.

  2. Открытый ключ / асимметричная криптография адресует некоторые конкретные варианты использования, которые, в широком смысле, включают безопасную передачу информации между надежными и несколькими ненадежными сторонами. Если кто-то решает использовать pass для хранения своих собственных паролей в публичном репозитории git, в этой схеме нет ненадежной стороны, чтобы оправдать использование асимметричной криптографии.

  3. Традиционная / симметричная криптография потенциально более безопасна, чем асимметричная криптография. Например, существуют квантовые алгоритмы, которые нарушают асимметричную криптографию, но квантовых компьютеров пока не существует. Хотя такие разработки не гарантированы, для симметричной криптографии не известны аналогичные (потенциальные) недостатки.

  4. Асимметричная криптография дает преимущества от двух различных уровней безопасности:

    (A) закрытый ключ симметрично шифруется парольной фразой

    (Б) секретный ключ (зашифрованный) хранится в безопасном месте

    Таким образом, например, (а) ничего не добавляет к безопасности асимметричной криптографии, пока выполняется (б). Совершенно верно (хотя и нецелесообразно) делать асимметричную криптографию с пустой кодовой фразой.

    Нормальная симметричная криптография с одним закрытым ключом обеспечивает только защиту типа (a). Если бы кто-то заменил асимметричную симметричную криптографию, было бы неплохо сохранить оба уровня безопасности (а) и (б). Один из способов сделать это – 2 симметричных уровня:

    • Генерировать приватную случайную строку

    • Симметрично шифровать частную случайную строку с использованием кодовой фразы, хранить конфиденциально

    • Симметрично шифровать сообщение с помощью частной случайной строки, публично публиковать

  5. Ниже описывается, что происходит под капотом, когда программа, такая как pass использует GPG с помощью идентификатора ключа GPG. (Предположим, что криптография с открытым ключом является RSA, а симметричная криптография – AES.) Во-первых, GPG используется для:

    (I) создание пары открытых и закрытых ключей RSA

    (Ii) Открытый ключ RSA незашифрован, хранится конфиденциально (жесткий диск) или публично (ключевой сервер)

    (Iii) AES-шифровать закрытый ключ RSA с парольной фразой, хранить конфиденциально

    Далее, после шифрования OpenPGP , это работает как шифрование:

    (Iv) генерировать случайный ключ сеанса

    (V) AES-шифрование сообщения с ключом сеанса, публичное публичное хранение

    (Vi) RSA-шифровать сеансовый ключ с открытым ключом RSA, публично публиковать

    Соблюдайте, что сообщение скомпрометировано, нарушая либо (v), либо (vi).

Ненужная потенциальная уязвимость :

Предположим, что в будущем будут разработаны квантовые компьютеры, и RSA будет нарушена. (Для параноиков предположим, что RSA уже нарушена.) Хотя это приведет к изменениям в том, как мы делаем такие вещи, как онлайн-банкинг, это также будет иметь совершенно ненужное негативное влияние на безопасность данных, созданных в pass / git-annex .

Насколько это плохо, зависит от того, хранится ли открытый ключ RSA из (ii) выше, публично или конфиденциально. Если он хранится публично, данные уже скомпрометированы: злоумышленник может расшифровать (vi) получение ключа сеанса, а затем дешифровать (v) с помощью ключа сеанса, чтобы получить сообщение. Если открытый ключ RSA из (ii) фактически остается конфиденциальным, безопасность данных сводится к (b), безопасности среды, содержащей открытый ключ RSA, что эквивалентно выполнению асимметричного шифрования без кодовой фразы.

Эта уязвимость, надуманная или нет, совершенно не нужна, так как это связано с ненужным использованием криптографии с открытым ключом, присущей существующему интерфейсу между программами, такими как pass / git-annex и GPG (с помощью идентификаторов ключа GPG).

Вопрос :

Существует ли «относительно простой способ»:

  • Удалите использование асимметричного шифрования, когда GPG используется под капотом через идентификаторы ключа GPG

  • Продолжать использовать GPG для управления ключами по-прежнему

  • Поддерживать двухуровневую безопасность, упомянутую в пунктах 4 (а) и (b)

Полная схема, которой я пользуюсь после:

(I ') генерирует частную случайную строку

(Ii ') AES-шифрование частной случайной строки с парольной фразой, сохранение в частном порядке

(Iii ') AES-шифрованное сообщение с частной случайной строкой, публично хранящее

Я понимаю, как выполнять каждый из этих шагов отдельно, но то, о чем я прошу, является лучшим способом подключить такое «исправление», как программы могут использовать GPG с помощью идентификаторов ключа GPG. В частности, я ожидаю, что такие программы будут выдавать внешние вызовы формы gpg --encrypt --recipient <keyid> и gpg --decrypt .

Заключение : Кажется, что нет волшебной пули, и перехват этих вызовов с помощью сценария оболочки gpg – единственный способ пойти. Возможно, GPG должен рассмотреть этот вопрос в будущем.

    Симметричная криптография в OpenPGP

    Читая свой вопрос, я думаю, вы смешиваете некоторые криптографические термины и принципы. Подобного симметричного шифрования нет, например, с помощью секретных ключей. Симметричное шифрование зависит от ключа сеанса (также называемого блоком шифрования), в то время как криптография с открытым / закрытым ключом (асимметричная) основана на парах ключей для операций шифрования (открытый ключ) и дешифрования (закрытый ключ).

    OpenPGP обычно использует гибридный криптографический подход: сообщение (данные, файлы, …) шифруется с использованием симметричного шифрования и случайного уникального ключа сеанса. Ключ сеанса шифруется с помощью криптографии с открытым / закрытым ключом. Это сочетает в себе преимущества как симметричной, так и криптографии с открытым / закрытым ключом: симметричное шифрование выполняется очень быстро, но для этого необходим общий секрет; В то время как криптография с открытым / закрытым ключом обеспечивает мощное управление ключами и отдельные общедоступные и закрытые ключи, хотя для больших объемов данных они ужасно медленны.

    Симметричное шифрование OpenPGP делает то же самое, но вместо этого выводит ключ сеанса из кодовой фразы. В зависимости от конфигурации в этом процессе добавляется некоторая соль (и GnuPG имеет разумные значения по умолчанию здесь). Нет никаких открытых или закрытых ключей (например, с RSA). В GnuPG это возможно, применяя параметр --symmetric .

    Есть ли способ заставить gpg выполнять чисто симметричное шифрование таким образом, что кодовая фраза используется только для защиты закрытого ключа, как и в асимметричном шифровании? Разумеется, для дешифрования потребуется как кодовая фраза, так и закрытый ключ.

    Если вы за чем-то вроде «можете ли я хранить ключ сеанса отдельно, зашифрованный парольной фразой вместо того, чтобы полагаться на функцию« ключ-ключ »OpenPGP и шифровать этот ключ сеанса с помощью фразы« no », это невозможно в рамках Протокол OpenPGP. Но вы можете в значительной степени имитировать такую ​​операцию, имея пару открытых / закрытых ключей, хранящихся вместе в одном месте, все еще зашифрованную парольной фразой. Кодовая фраза будет использоваться для дешифрования закрытого ключа всякий раз, когда он будет использоваться.

    (В стороне, я считаю, что нечто подобное достигается солью MK, хранящейся в заголовке LUKS: потеряйте это, и только парольная фраза не может расшифровать контейнер.)

    Нет, соль хранится вместе в заголовках шифрования сообщения (или в контейнере шифрования в случае LUKS). Вы не можете сравнить это с ключом, и это не секретно. Соль используется для предотвращения нападений с радужными таблицами, присоединяя их к кодовой фразе до вычисления ключа сеанса.

    Переопределение ключей сеанса

    В ваших обновлениях вы уточнили свои цели.

    Полная схема, которой я пользуюсь после:

    (I ') генерирует частную случайную строку

    (Ii ') AES-шифрование частной случайной строки с парольной фразой, сохранение в частном порядке

    (Iii ') AES-шифрованное сообщение с частной случайной строкой, публично хранящее

    Вы не можете точно достичь этого, но GnuPG знает (нестандартизированный) способ извлечь и определить ключи сеанса для использования. От man gpg :

     --show-session-key 

    Отобразите ключ сеанса, используемый для одного сообщения. См. --override-session-key для аналога этой опции.

    Мы считаем, что Key Escrow – это плохая вещь; Однако у пользователя должна быть свобода решать, идти ли в тюрьму или раскрывать содержимое одного конкретного сообщения без компрометации всех сообщений, когда-либо зашифрованных для одного секретного ключа. НЕ ИСПОЛЬЗУЙТЕ ЭТО, ЕСЛИ ВАМ ДЕЙСТВИТЕЛЬНО НЕПРАВИЛИСЬ СДЕЛАТЬ.

     --override-session-key string 

    Не используйте открытый ключ, а строку ключа сеанса. Формат этой строки такой же, как и --show-session-key . Эта опция обычно не используется, но удобна, если кто-то заставляет вас раскрывать содержимое зашифрованного сообщения; Используя эту опцию, вы можете сделать это, не выдавая секретный ключ.

    Вы можете использовать эти параметры, чтобы извлечь ключ сеанса, зашифровать его отдельно, используя кодовую фразу, где-то хранить. Чтобы использовать его, вам придется зашифровать его снова, используя кодовую фразу, и передать его в GnuPG. Конечно, это может быть достигнуто с помощью некоторого сценария оболочки или аналогичных средств. Это самое близкое, что вы можете получить через GnuPG (это выходит за рамки того, что указано в OpenPGP, параметры GnuPG-specific). Эти варианты не считаются используемыми для ежедневной работы разработчиков.

    Я бы не злоупотреблял GnuPG и OpenPGP для такого рода операций. Вы можете легко использовать OpenSSL и, вероятно, также GnuTLS для этого и без использования эзотерических нестандартизированных режимов работы и сценариев оболочки.

    Давайте будем гением компьютера.