LINUX.ORG.RU

Прямая секретность с GnuPG(PGP)

 , , , ,


0

2

Приветствую.

Интересует возможность использования (совершенной)прямой секретности с GnuPG(и другими реализациями PGP). GPG удобен своей гибкостью(пусть и требует от пользователя определённого опыта) и тем, что позволяет легко превращать любые данные в base64-шифротекст, предоставляя возможность обмениваться не только текстом, но и медиафайлами и целыми архивами.

Однако асимметричные криптосистемы, поддерживаемые GnuPG, статичны(ECC тоже) и работают только по «классической» схеме с использованием долговременных ключей. Использование постоянных ключей для шифрования подразумевает возможность восстановить переписку при компрометации единственного секретного ключа(дешифруются все сообщения одной стороны, легко предполагается содержание шифротекстов другой), что не позволяет обеспечить ни прямую, ни обратную секретности. Более того, единственный доступный способ аутентификации(ЭЦП) не предполагает отрицаемости сообщений, что ставит под угрозу обе стороны.

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

Какой вариант я рассматриваю сейчас?

Рассмотрим ситуацию с двумя участниками обмена: Алисой(адресант, инициатор) и Бобом(адресат). Пошагово это выглядит так(предполагается использование RSA, но это работает с любым асимметричным алгоритмом, в т.ч. «постквантовым»):

  • Алиса и Боб генерируют две пары долговременных ключей(одну каждый) и обмениваются открытыми ключами друг с другом.
  • Алиса дополнительно создаёт одноразовую пару ключей.
  • Алиса отправляет свой одноразовый открытый ключ Бобу, предварительно зашифровав его долговременным открытым ключом Боба и подписав своим постоянным секретным ключом.
  • Боб, удостоверившись в аутентичности подписи, отправляет временный секрет(длинную псевдослучайную последовательность символов), его «срок жизни»(количество сообщений и срок годности) и предпочтительную схему симметричного шифрования(AES, Twofish, Serpent и т.п. с длиной ключа, прим AES-128.) Алисе, предварительно зашифровав сообщение одноразовым открытым ключом Алисы и подписав своим постоянным секретным ключом. На данном этапе аутентификация завершена.
  • Алиса, уничтожив временную пару ключей, отправляет тестовое сообщение, зашифрованное уже общим секретом, благодаря чему обеспечивается аутентичность всех сообщений с тем же секретом, повышается(на порядки) скорость работы и стойкость шифрования(в разы).
  • Полученный секрет используется до окончания его «срока жизни», после чего операция повторяется, начиная со второго шага.

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

#!/usr/bin/env bash
randexp=$(cat /dev/urandom | tr -dc '1-3' | head -c1)
randbyte=$(cat /dev/urandom | tr -dc '0-9' | head -c$randexp)
cat /dev/urandom | head -c$randbyte | base64
В данном примере добавляется от 0 до 999 байт.

Что насчёт анонимных сообщений? Всё просто - используется открытый ключ одной из сторон, но адресант не подписывает сообщение. Известен получатель, но не отправитель. А первоначальный обмен открытыми ключами можно произвести, например, с помощью OnionShare(«Trust» в Web of Trust, КМК, доверия не заслуживает).

Коллега предложил использовать долговременные ключи только для подписи, а ключи для шифрования запрашивать по необходимости, подписывая запрос. На мой взгляд такой подход слабее, а площадь атаки много больше.

На первый взгляд всё красиво, не так ли? Да и всю эту «рутину»(кроме первого шага) можно автоматизировать одним коротким исполняемым файлом.

Тем не менее, какие уязвимости есть у такого подхода? Интересует ваше мнение.

И ещё, GPG при работе с блочными шифрами использует режим CFB. Выглядит неплохо, но распространено утверждение, что CTR для подобных целей подходит намного больше. Так ли это?

Как бы то ни было, заранее спасибо за помощь.

ЕМНИП, похожая схема уже где то была реализована, не вспомню как мессенджер называется, но точно уже где то такое описание попадалось. Можно попробовать на ангельском запросы в поисковике.

BLOBster ★★ ()
Ответ на: комментарий от anonymous

Да, это грубо говоря, на деле секрет не общий, но всё же распределённый.

Впрочем, можно возложить обмен частями секрета на обе стороны(даже реализовать протокол Диффи-Хеллмана), но поскольку постоянный ключ никогда не используется для формирования симметричного секрета, обоснованность такого подхода под вопросом — компрометация долговременного ключа даже обоих пользователей не позволит расшифровать сообщения — не даст одноразовый асимметричный ключ. Количество сообщений для «рукопожатия» при этом вырастет(сейчас их ровно два).

Тут уже вопрос в том, какой алгоритм более стойкий(скорость нас не интересует при «холодном» хранении сообщений) — ECDHA или RSA.

SM5T001 ()
Ответ на: комментарий от SM5T001

можно возложить обмен частями секрета на обе стороны(даже реализовать протокол Диффи-Хеллмана)

И переизобрести что-то наподобие tls.

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

какой алгоритм более стойкий(скорость нас не интересует при «холодном» хранении сообщений) — ECDHA или RSA.

Это контрольный вопрос?

anonymous ()
Ответ на: комментарий от anonymous

И переизобрести что-то наподобие tls

Ну да, но вариацию, пригодную для шифрования вообще чего угодно без особых проблем.

Только напрягает меня необходимость «растянуть» рукопожатие.

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

Справедливо. Можно, не растягивая рукопожатие, передавать Бобу свою часть секрета вместе с одноразовым открытым ключом. Тогда эта проблема устраняется(? скорее ослабляется, устранить полностью такую проблему невозможно), но появляется новая — ослабление(существенное) шифрования в случае компрометации долговременного ключа. Но смягчить проблему можно использованием очень длинного ключа(сотня-другая символов).

Тогда Боб во втором сообщении передаёт не весь ключ, а свою часть.

Это контрольный вопрос?

?

SM5T001 ()
Ответ на: комментарий от anonymous

Ну, судя по ситуации с toxcore это едва ли возможно(без нового форка), да и далеко мне до него. Кроме того, цель тут другая — создать схему, которая позволила бы эффективно обмениваться сообщениями в любой незащищённой среде, хоть в комментариях YouTube, например.

Делается это для формы связи, исходники которой я опубликую и любой администратор себе к сайту сможет прикрутить.

SM5T001 ()

Небольшой экскурс в историю, в «нулевые» асимметричное шифрование считалось чуть ли не панацеей для бизнеса и финансов, а потом «внезапно» выяснилось, что фрода меньше не стало.

Потому что, например, бухгалтеры тоже люди и уходя на обед и закрывая кабинет, не только не выключают компьютер, но и не убирают ключевой носитель в сейф. Вектор атаки просто сменился с перехвата и модификации на удалённое управление.

Не слишком ли много усилий на защиту канала/контента, когда переписка и медиа на клиентах в открытом виде и вообще, неизвестно, кто там за правым плечом Боба смотрит в монитор?

«Что знают двое, то знает и свинья».

vvn_black ★★★★★ ()
Ответ на: комментарий от vvn_black

Так PFS — не совсем асимметричное шифрование, рассчёт именно на возможность компрометации долговременных ключей.

Ну украдёд хакер Вася у Боба секрет, что с того? Он только сможет притвориться Бобом, но никак не прочитать всю его прошлую переписку. Защита же от поддельной подписи осуществляется простыми вопросами, мол, " — Боб, помнишь, я рассказывала тебе о любимой рок группе? — Конечно, конечно! С чего бы я забыл? — Боб, дело-то в том, что я не слушаю рок. Конец связи."

SM5T001 ()
Ответ на: комментарий от SM5T001

Так PFS — не совсем асимметричное шифрование

Так и я совсем не про шифрование.

Если образно, вы предлагаете приложить много усилий и укрепить дверь замком, но при этом есть окно, через которое можно подглядывать на расстоянии.

Отсюда вопрос, а зачем всё это? Может, пусть останется китайский замок в двери, к которому наверняка есть мастер-ключ или его возьмут легко отмычки, но при этом «повесить шторы»?

Т.е. я про «доверенную среду», которая не ограничивается тем, что вы предлагаете.

vvn_black ★★★★★ ()
Последнее исправление: vvn_black (всего исправлений: 2)
Ответ на: комментарий от vvn_black

а зачем всё это?

Всё это исключительно(по крайней мере пока) для общения с глазу на глаз, для тех, кто знает, что и зачем делает.

Если доводить до абсурда, то и Tor не нужен, и даже пароль sudo, так получается?

SM5T001 ()
Ответ на: комментарий от Morin

Почти. Впрочем, если вы считаете, что это не нужно, то я попрошу предоставить готовую альтернативу, которая:

1)Была бы широко распространена.

2)Шифровала бы данные только локально, всегда создавая шифротекст, никогда — открытый текст. Ни единого байта, кроме какого-нибудь BEGIN PGP MESSAGE.

3)Могла бы использоваться где угодно, защищая любой канал связи. Тот же пример с комментариями YouTube актуален.

Я подобного, увы, не знаю, а потому пытаюсь приручить GPG(PGP).

SM5T001 ()
Ответ на: комментарий от SM5T001

Второй пункт более вменяемо опишите

3 пункт это маразм, как можно и зачем нужно шифровать сообщения на открытой стене? которая предназначена для прочтения кем угодно, зачем? Вам там выше уже намекнули про необходимость выбора среды распространения, так вот среда, это множество абстракций, очевидно, что комнет на ютубе - плохой выбор

Morin ★★★ ()
Последнее исправление: Morin (всего исправлений: 1)
Ответ на: комментарий от Morin

2. Защита канала передачи данных(http, smtp и т.п.) осуществляется отдельно от защиты самих данных(pgp). Сами данные шифруются только локально, без необходимости соединяться с сетью.

3. Маразм — доверять исключительно какому-то конкретному решению всецело, рискуя потерять всё либо при компрометации самого решения, либо при его устаревании по окончании поддержки.

Зачем нужно шифровать сообщения на открытой стене? А зачем вообще шифровать сообщения? Мы сам факт шифрования не пытаемся и не будем пытаться скрыть.

Обмен публичными ключами стороны производят сами как им удобно. Строго говоря, это вообще не проблема асимметричной криптографии. Никто не может гарантировать, что ключ в моём комментарии на том же LOR не подменит злой модератор на свой, став посредником.

SM5T001 ()
Ответ на: комментарий от SM5T001

про подписи и доверие маны читали? проследуйте пожалуйста

брать со стены открытый ключ неподписанный никем верх маразма. Не ну если очень хочется, то кто же вам мешает общаться с тв майором

Morin ★★★ ()
Ответ на: комментарий от Morin

Угу. И кто же будет подписывать ваш долговременный ключ? Майор Центр сертификации? Вот он же и подпишет поддельный ключ.

И берём мы не со стены. В первом посте уже описал один из вариантов, но кто читает перед комментированием, правда?

Раз уж вы настолько узко смотрите на тему — пожалуйста, откланивайтесь, зря взялись комментировать то, с чем не сталкивались и не планируете столкнуться на практике. Это не для вас делается.

SM5T001 ()
Ответ на: комментарий от Morin

ну когда возразить нечего (:

Да, на справедливое возражение так отвечать — мигом обнулять справедливость, конечно.

Ещё раз: ключами мы меняемся через OnionShare, в «комментарии на ЛОР» меняемся только отпечатком и .onion-адресом. Такой подход сильно усложняет подмену, доверять чёрт знает кому нет необходимости(это я предложил и «умные люди» вроде как «раскритиковали с фейспалмом»).

Всё на этом, далее требую вернуться к первоначальной теме, а именно:

счастливого велосипедостроения

За язык никто не тянул. Теперь прошу дать ссылку на «оригинальный велосипед» или не разбрасываться более самоуверенными заявлениями, которые есть суть вздор.

SM5T001 ()
  1. Делал похожее, но вместо:

Боб, удостоверившись в аутентичности подписи, отправляет временный секрет(длинную псевдослучайную последовательность символов), его «срок жизни»(количество сообщений и срок годности) и предпочтительную схему симметричного шифрования(AES, Twofish, Serpent и т.п. с длиной ключа, прим AES-128.)

Действовал как здесь:

Алиса дополнительно создаёт одноразовую пару ключей.

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

Тоесть использовал стандартное PGP, только с временными ключами.

Было реализовано также возможность заверение каждого сообщения более чем одной подписью. Зашифрованное сообщение сверху шифровалось еще подписями.

  1. Здесь для безопасности больше важна аппаратная часть дела, которая защищает временные о «постоянные» ключи.

Пример: https://www.nitrokey.com

Долговременные ключи в работающей системе держать нельзя. Это строгое правило.

  1. Зачем теперь все это когда есть TOX и он может работать поверх TOR? https://qtox.github.io/ru.html

Люди сегодня не хотят тыкать сообщения. Надо просто поговорить, лучше при этом видеть лицо собеседника, конечно соблюдая приватность и помня это: ми6 насобирала для АНБ гигабайты порно с инет видеочатов.

anonymous ()
Ответ на: комментарий от SM5T001

вопрос в том, какой алгоритм более стойкий(скорость нас не интересует при «холодном» хранении сообщений) — ECDHA или RSA.

восстановления закрытого ключа ECDSA, обрабатываемого в анклаве Intel SGX, после осуществления в системе всего одной операции с цифровой подписи: Security Boot и подпись загрузчика Windows (комментарий)

Сообщения хранить не надо! Использовать p2p, безсерверную пересылку с end2end шифрованием.

anonymous ()
Ответ на: комментарий от SM5T001

Ни единого байта, кроме какого-нибудь BEGIN PGP MESSAGE.

Ээээ это уже очень много сегодня. Еще ты еще опцию –hidden-recipient не указывай ;)

Заглавте BEGIN PGP MESSAGE и конец могут клиенты сами дописать, также и перебрать все свои ключи для расшифровки. А иначе ваш «супер секурный» менеджер забанят даже в коментах ютуба.

anonymous ()

Коллега предложил использовать долговременные ключи только для подписи, а ключи для шифрования запрашивать по необходимости, подписывая запрос. На мой взгляд такой подход слабее, а площадь атаки много больше.

Идеальное решение. Именно так реализуется PFP с помощью PGP.

anonymous ()

А первоначальный обмен открытыми ключами можно произвести, например, с помощью OnionShare

Тебе сделают MitM.

Даже если в ЛОР профиле публичные ключи оставлять, все равно сделают MitM по долговременным ключам.

Web of Trust

Это хорошая вещь была. Именно с неё надо начинать. Товарищ майор умышленно её частично похерил: SKS Keyserver Network Under Attack (комментарий)

Фундаментом использования PGP есть получения публичного ключа с рук владельца приватной части и сверкой его паспортных данных: фотографии с лицом и ФИО в паспорте с указанными данными в поле UID ключа, верификацией его E-mail! В этом случае ключ заслуживает доверия. Можно также обмениватся ключами с людьми которых ты точно знаешь ФИО и E-mail по учебе, работе. По ключам заслуживающим доверие, можно провести верификацию Web of Trust.

Все должны хранить свои ключи защищая аппаратно, например нитрокеем. С домашней папки их у вас украдут.

Если ты берёшь ключ с рук, но без сверки паспортный данных, то человек может выдать себя за другого и сделать MitM или нарушить верификации Web of Trust...

КМК, доверия не заслуживает).

Что это?

Обмен сессионными ключами делать надо по алгоритму Дифи и Хелмана.

На территоррии РФ, за разработку такого ПО, Путин и ЕР может посадить на 5 лет: Что должен знать специалист ИБ на старте (комментарий)

anonymous ()
Ответ на: комментарий от anonymous

Тоесть использовал стандартное PGP, только с временными ключами.

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

Было реализовано также возможность заверение каждого сообщения более чем одной подписью.

Не совсем понимаю, в каких условиях понадобится подписывать сообщение разными ключами.

Здесь для безопасности больше важна аппаратная часть дела, которая защищает временные о «постоянные» ключи.

Можно использовать самодельные «PGP-карты».

Зачем теперь все это когда есть TOX и он может работать поверх TOR?

Увы, не может. Он может использовать Tor как прокси, но не умеет работать с onion-сервисами. А onion-сервисы Tor намного безопаснее схем с выходными узлами.

SM5T001 ()
Ответ на: комментарий от anonymous

Ээээ это уже очень много сегодня. Еще ты еще опцию –hidden-recipient не указывай ;)

Заглавте BEGIN PGP MESSAGE и конец могут клиенты сами дописать

--hidden-recipient это конечно хорошо, но удаление BEGIN PGP MESSAGE не сильно поможет спрятать факт шифрования PGP в силу особенностей кодирования Radix-64, так как в конец сообщения добавляется контрольная сумма.

Так-то можно удалить и BEGIN, и END, после написать безобидный комментарий, в конец которого вставить нашу криптограмму.

А иначе ваш «супер секурный» менеджер забанят даже в коментах ютуба.

Комменты ютуба — просто наглядный пример. Кто-то правда думает, что я всего-то хочу сделать безопасной переписку в YouTube?? Я же сказал, цитирую:

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

Это отдельная реализация, но принципиальная особенность в том, что пользователь должен сам шифровать всё. Так не нужно будет кому-то доверять.

SM5T001 ()
Ответ на: комментарий от anonymous

Тебе сделают MitM.

Его мне сделают в любом случае, если очень сильно захотят. Но можно довольно легко сделать атаку слишком дорогой и заметной — достаточно использовать несколько каналов связи, желательно не принадлежащих одним лицам(аля youtube, lor, соцсеть какая-нибудь в .onion и т.п.), а после обмена проводить сверку.

Это хорошая вещь была. Именно с неё надо начинать. Товарищ майор умышленно её частично похерил

Меня местные могли не так понять: я не против использования WoT в принципе, для дел вроде разработки ПО это самое то, но он совершенно не подходит для «подпольной» анонимной работы. Уже хотя бы потому, что ключ удалить невозможно никак. Минусов там полно.

Если ты берёшь ключ с рук, но без сверки паспортный данных, то человек может выдать себя за другого и сделать MitM

Но он не сможет расшифровать тестовое сообщение без секретного ключа, так что не сможет. Или сможет если украл ключ, но тогда тут проблема серьёзнее.

Обмен сессионными ключами делать надо по алгоритму Дифи и Хелмана.

Не обязательно. Раньше делали по RSA.

На территоррии РФ, за разработку такого ПО, Путин и ЕР может посадить на 5 лет:

К счастью, на территории Лунного Содружества этот закон не применяется.

SM5T001 ()

Должен уточнить, это вовсе не праздный теоретический интерес, на данный момент завершаются работы над системой обмена сообщениями через Tor, шифрование сообщений в которой возложено целиком на пользователя

Как бы то ни было, заранее спасибо за помощь.

Как бы то ни было, сворачивай всю эту самодеятельность на корню и бери че там внутри OMEMO юзают примерно этак вообще все. В лучшем случае (<1%) будешь как Телеграм со своим сомнительным великом, в худшем (>99%) накосячишь.

t184256 ★★★★★ ()
Ответ на: комментарий от SM5T001

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

Скорость не важна. Размер уменьшается сжатием. Безопасность увеличивается наложением нескольких слоев шифрования, разными ключами, как матрешка. Да, надо минимум по одной паре сеансовых, кратковременных PGP с каждой стороны, здесь главная цель не держать долговременные PGP в рабочей системе с подключением в Inet! Да, авторизация временных ключей длительная, трудоемкая, ручная процедура.

в каких условиях понадобится подписывать сообщение разными ключами.

Безопасность. По техзаданию может требовался наложения минимум двух подписей от разных людей на одно сообщение. Сообщение подписаное только одним человеком в некоторых системах достоверным не считается.

Можно использовать самодельные «PGP-карты».

PGP и так сложен и очень трудоемок, еще и аппаратные ключи самим делать…

Увы, не может

TOX замечательно работает поверху TOR если кому когда надо. А может и прекрасно, БЕЗОПАСНО работать без него!

Преимущество TOX удобство видеозвонков для общения, можно и простых голосовых. Удобство работы сразу «изкаробки» без настроек. Верификация проходит не только крыптографическая, при видео звонках есть визуальная верификация лица, сисек-писек.

anonymous ()
Ответ на: комментарий от SM5T001

но удаление BEGIN PGP MESSAGE не сильно поможет спрятать факт шифрования PGP в силу особенностей кодирования Radix-64, так как в конец сообщения добавляется контрольная сумма.

Если чуть подумать, то все хорошо прячится. Клиенты с двух сторон одинаковы, значит мы можем делать ВСЕ!

но принципиальная особенность в том, что пользователь должен сам шифровать всё

Будут общаться в чате только два бородатых админа.

Незря привел пример TOX. Все готово из каробки, чтобы домохозяйки могли обмениваться кухонными рецептами по видео не платя денег за связь.

anonymous ()
Ответ на: комментарий от SM5T001

достаточно использовать несколько каналов связи, желательно не принадлежащих одним лицам(аля youtube, lor, соцсеть какая-нибудь в .onion и т.п.), а после обмена проводить сверку.

Твой враг сегодня ИИ с безграничным доступом к: youtube, lor, соцсеть какая-нибудь в .onion и т.п.

для «подпольной» анонимной работы

Иди наюх от PGP со своей анонимностью!

От TOX тоже наюх со своей анонимностью!

Лично я в чатах с анонимами не общаюсь! Для анонимов есть публичные форумы.

Чаты, TOX, PGP это для общения ЗНАКОМЫХ. И я, Антон, желаю на 100% быть уверенным что в чате общаюсь с знакомой Аней, а не с бородатым админом или товмайором, которым нехбольшеделать, через их MitM.

Если ты берёшь ключ с рук, но без сверки паспортный данных, то человек может выдать себя за другого и сделать MitM

Но он не сможет расшифровать тестовое сообщение без секретного ключа, так что не сможет. Или сможет если украл ключ, но тогда тут проблема серьёзнее.

Он сделает MitM и не только расшифровки вашу переписку, а легко исказит ее. Если ты этого не понял то разговор окончен.

Обмен сессионными ключами делать надо по алгоритму Дифи и Хелмана.

Не обязательно. Раньше делали по RSA.

Сегодня обязательно, иначе сделают MitM.

К счастью, на территории Лунного Содружества этот закон не применяется.

Я очень рад за умных людей «Лунного Содружества», которые избирают власть не принимающую дурацких законов.

А на территтрии РФ, в благодарность за слепую преданость на выборах, Путин и Единая Росия, удостоили: крепаков, батраков, бурлаков, цензура_ЛОРа_тиких_слов_не_пропустит – цензурным, почетным, политкорректным поганялом, так называемый, «трудовой народ».

anonymous ()
Ответ на: комментарий от anonymous

РФ страна где больше "трудового народа" чем людей.

Через недельку в РФ, официально, будут жить Люди и нелюди, или выражаясь политкорректнее «трудовой народ».

anonymous ()

Режимы CTR или GCM, конечно, поудобнее.

А про сессионные ключи я бы рекомендовал не (сразу) изобретать велосипед, а (сначала) ознакомиться с существующими: https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm

А то, что вы описали,свойством PFS не обладает.

ivlad ★★★★★ ()
Последнее исправление: ivlad (всего исправлений: 1)
Ответ на: комментарий от ivlad

Два вопроса?

1. А есть какие другие, хорошие, советы по верификации публичных ключей PGP, кроме указанных в документации:

man gpg --default-cert-level --trust-model и https://www.opennet.ru/docs/RUS/pgupg/management.html#AEN339

2. И советы по защите секретного ключа кроме классики: https://www.opennet.ru/docs/RUS/pgupg/wise.html#AEN515

anonymous ()
Ответ на: комментарий от vvn_black

AMD Microcode Signing Key (for signing microcode container files only)

В свете недавних «радостных» новостей от AMD: Security Boot и подпись загрузчика Windows (комментарий)

Требуется помощь с PGP ключами AMD.

По этой ссылке есть 4 файла: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd-ucode подписанных РАЗНЫМИ ключами от AMD с идентичным UID !!!

У себя, на компе, вы эти файлы можете найти если установили пакет linux-firmware в директории: /lib/firmware/amd-ucode/*

microcode_amd.bin подписанный 8C0108B4 20130710 20:56:29

microcode_amd_fam1* подписаны F328AE73 20141027 06:13:32

microcode_amd_fam15h.bin изменялся, все версии подписаны F328AE73

Оба ключа действительны, ни один не отзывался.

Как удостоверится в подлинности ключей от AMD?

anonymous ()
Ответ на: AMD Microcode Signing Key (for signing microcode container files only) от anonymous

The PaX Team

У меня есть также 2 ключа от PAX с одинаковыми короткими идентификаторами: 39F081BF, ключ от 20140616 00:54:42 - отозван.

Сгенерированы GnuPG-ключи с одинаковым коротким идентификатором

ElcomSoft запретили рассказывать об уязвимости в PGP

https://www.opennet.ru/opennews/art.shtml?num=51609

https://www.opennet.ru/opennews/art.shtml?num=46812

Не давно было в новостях, что удалось создать ключ RSA с полностью идентичным полным отпечатком ключа. SHA1 для создания отпечатков ключей сегодня уже непригоден.

anonymous ()
Ответ на: комментарий от ivlad

Режимы CTR или GCM, конечно, поудобнее.

Вероятно, ChaCha20 будет ещё лучше. GCM ныне многие критикуют, во многом по делу.

А про сессионные ключи я бы рекомендовал не (сразу) изобретать велосипед, а (сначала) ознакомиться с существующими: https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm

Читал, знаком с этим. Есть фатальные недостатки в текущих реализациях, такие как необходимость использовать централизованный сервер для хранения публичных ключей(третья сторона), невозможность обеспечить «анонимность наперёд»(forward anonymity) и т.п., что уже сильно ограничивает область применения.

А то, что вы описали,свойством PFS не обладает.

Почему? Первое и главное требование PFS — невозможность восстановить сообщения при компрометации долговременных ключей — соблюдается полностью благодаря использованию эфемерного(шаг 2) и сессионного(шаг 3) ключей. Протокол Диффи-Хеллмана не абсолютно обязателен, тот же SSL раньше использовал RSA.

Буквально немного переработав подход, я добавил защиту от компрометации ГСЧ одной из сторон и «эфемерный контрольный вопрос»(задаётся пара вопрос-ответ в конце сессии, можно использовать случайную мешанину из символов), что добавило к «рукопожатию» всего одно дополнительное сообщение. «Эфемерный контрольный вопрос» надёжно защищает от подделки подписей, а угадать его(в отличие от «постоянного») сложно.

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

Подход не позволяет защитить канал передачи данных, но защищает сами данные(так никто почему-то не делает, возлагая на канал одновременно обязанности по защите самих данных). Серьёзный недостаток — низкая производительность, но КМК современные машины спокойно справятся.

SM5T001 ()

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

Но ключевыми параметрами является система MFA сервер. На стороне которой, он анализирует пароль один раз для вошедших в систему пользователей и разрешает или запрещает доступ к источнику.Стабильность пароля достигается в основном за счет использования сложных алгоритмов его вывода, которые представляют собой постоянное обновление по времени. Основными мерами можем назвать три из них.

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

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

OCRA требует отзывчивой системы. Этот алгоритм делает пароль, используя случайное значение, полученное сервером в качестве даты ввода времени.

https://www.protectimus.com/blog/ru-two-factor-authentication-how-it-works/

Поэтому советую рассмотреть данную аналогию безопасности.

Stephen ()