можно ли путем -show-session-key и -override-session key решить нетривиальнейшую задачу?
Итак, как известно, у каждого сообщения М есть случайный сессионный ключ К, шифрованый ассиметричным (публичным) ключом А.
Задача: Есть сообщение М. Есть статистически неотличимая от случайной строка из 256 бит С.
Как сделать так, чтобы при шифровании сообщения М в рамках PGP использовать эту строку С ВМЕСТО сессионного ключа К, дальше спокойно зашифровать С публичным ключом А, как если бы С было нормальным сессионным ключом, потом построить стандартное PGP сообщение, т е (С зашифрованное А)+(М зашифрованное С)?
А зачем оно надо?
ОТВЕТ:
Известно, что любое сообщение, зашифрованное нормальным алгоритмом не отличимо от выхода нормального ГСЧ. Если мы возьмем 256 значимых бит (это целых 32 ASCII символа!) и зашифруем их, то результатом будет 256 бит, аналитически неотличимые от 256 бит, выданных нам ГСЧ. Это и есть наша строка С...
Сессионный ключ это 256 бит выданных ГСЧ. Если мы сможем подменить их нашими С, то Алиса сможет передать Бобу с помощью PGP/GnuPG не только сообщение М, но и особо важное тайное сообщение С (32 буквы).
Даже если Мэлори, пользуясь связями с злым Оборотнем в Погонах надавит на Боба, чтобы тот раскрыл переписку, Бобу будет нечего опасаться и он сможет ничего не теряя выполнить требования, так как НАСТОЯЩИЙ секрет (32 ASCII символа зашифрованные в С и прикидывающиеся шлангом сессионным ключом) останется в сохранности, так как Мэлори не сможет узнать, что сессионный ключ одного из множества PGP сообщений не является продуктом ГСЧ, а является неким сообщением, поскольку статистической разницы нет.
комментариев: 11558 документов: 1036 редакций: 4118
Только есть у этого подхода большая проблема: использование печатного и, тем более, осмысленного ASCII-текста катастрофически снизит энтропию сеансового ключа. В этом случае ничто не мешает Мэллори подобрать непосредственно его по словарю. Вы в своей схеме исходите из того, что Мэллори обо всём об этом ничего знать не будет, но что если он всё-таки попробует? Ему это может оказаться вполне по силам.
Добавлено:
Поторопился с ответом. Вы пишите, что строка-кандидат С неотличима от случайной. Если так (например, Вы стеганографируете сообщение в каких-то отдельных битах этой строки), то явных очевидных проблем я здесь не вижу.
комментариев: 9796 документов: 488 редакций: 5664
В принципе это возможно. Тоже можно делать и для подписей DSA.
Но опция -show-session-key позволяет показать сеансовый ключ, а -override-session key не заменяет сеансовый ключ в сообщении, а позволяет лишь использовать извлечённый сеансовый ключ для расшифровки вместо реально существующего. Это как вариант редкой судебной процедуры: раскрытие сообщения по требованию следствия без раскрытия закрытого ключа.
Т.е. подозреваемый делает -show-session-key для затребованных сообщений и отсылает дознавателю. Тот в присутствии экспертов делает -override-session key, вводит присланный ключ, после чего все читают сообщения.
Подойдёт теоретически при расследовании для крупной организации, но не против частного пользователя. (не приходилось этим пользоваться, поправьте если не так).
Т.е. возможностей для манипуляции со скрытым ключём в сообщении скорее всего нет. (будет время, проверю, но думаю бесполезно).
Но если влезать в исходники gpg, то тогда безопаснее подменять векторы инициализации, а не ключи, хотя это сложнее.
комментариев: 6 документов: 3 редакций: 0
Увы, хак кода я "ниасилю", потому что не програмист.
строка просто шифруется симметричным алгоритмом, например горячо любимым AES'ом 256. И в результате отличить ее от случайной, не зная о факте подмены, а так же шифр, режим и ключ, нельзя.
unknown
Для подписей тоже? Хм... чем больше узнаю, тем более привлекательной мне кажется идея :-) Жаль правда, что только для DSA, но ведь "по стандарту" все равно полагаются они...
Нда, похоже на то... увы.
а как хороша идея!
А чем IV в этом плане более привлекательны/более безопасны, чем ключи?
С ключом вроде "чистенько и простенько" – 256 "случайных" на вид (и на статистический тест) бит.
Господа, может быть оформить это как предложение разработчикам GnuPG? Функционал весьма себе полезный (кто не любит настоящую, недетектируемую стеганографию, даже если спрятать дают всего 32 буквы на сообщение?), от стандарта OpenPGP отступления нет (с точки зрения других приложений работающих в этом стандарте, той же PGP, такое "стего-обремененное" сообщение будет восприниматься как обычное PGP сообщение с нормальным, случайным сессионным ключом).
На мой взгляд, от такой уникальной функции GnuPG были бы одни только плюсы. Первая OpenPGP система с стеганографическим потенциалом...
Напишем письмецо?
Тем боле что "принципиальная возможность", насколько я понял, уже есть! Надо только "докрутить" соответствующий оверрайд, чтобы втыкать это самое С вместо сессионки =)))
комментариев: 9796 документов: 488 редакций: 5664
Уже была идея использовать дописывание случайных данных перед подписью, чтобы противостоять слабостям хэш-алгоритмов. Это позволяло бы создать скрытый канал. Но скрытые каналы могут использоваться для незаметного похищения ключей. Это потенциальная дыра в систему, снижающая доверие и эта одна из причин по которой предложение было отвергнуто.
Поэтому кто-то использует RSA, где скрытого канала нет, а в DSA стараются его избегать.
Идею plausible deniability нужно решать возможно как-то иначе.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Это хорошо, только эфемерные ключи и скрытый канал – это разные вещи.
комментариев: 11558 документов: 1036 редакций: 4118
Эфемерные ключи тоже решают эту задачу, хоть и иным путём: оппонент может определить наличие шифртекста и требовать выдачи ключей, но контрагенты в принципе не смогут выполнить это требование, поскольку самих ключей больше нигде нет (в большинстве случаев это даже предпочтительней: тут Вы хотя бы можете объективно доказать, что Вы не верблюд).
В данном случае оба подхода эквивалентны.
комментариев: 53 документов: 3 редакций: 1
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 232 документов: 17 редакций: 99
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 232 документов: 17 редакций: 99
Ладно, буду читать на английском, хотя это будет значительно дольше =(
Если вам не сложно объясните в двух словах остальным, я думаю это будет интересно всем, а то я может быть не до конца правильно пойму.
комментариев: 11558 документов: 1036 редакций: 4118
http://www.links.org/dnssec/draft-brown-pgp-pfs-04.txt
(это старый текст, ничего более свежего в своём архиве не нашёл)