Аналог PGP с обеспечением отрицаемости и наперёд заданной секретности оффлайн?
Обсуждение в соседней теме натолкнуло на мысль: существует ли решение, аналогичное PGP и обеспечивающее для оффлайн-сообщений конфиденциальность и аутентификацию, но плюс отрицаемость и наперед заданную секретность (PFS), ну, и, желательно, тихое уведомление о прессинге. Нашел похожий вопрос на crypto.stackexchange: похоже, что готовых решений пока нет. Возможно, где-то на pgpru это уже обсуждалось, или что-то уже появилось?
комментариев: 11558 документов: 1036 редакций: 4118
Это не так.
Нельзя. И такой финт работал бы только для ключей RSA. OpenPGP предписывает использование меток времени для всех подписей, так что либо надо подделывать время, либо как-то обходиться без подписей, либо использовать их так, чтобы это не вышло боком.
Самое смешное, что в gpg2 есть специальный отладочный параметр --faked-system-time, в который можно было бы передать 0, однако программа этот параметр почему-то не воспринимает (может, лично у меня, хотя в 2.0.22 должно работать).
комментариев: 9796 документов: 488 редакций: 5664
Если сторона высылает пароль, то она может подсунуть в него нечто, как в примере /comment73797, но это следует считать или неустранимой проблемой или вообще не считать проблемой согласно /comment73796. Если пароль выводят обе стороны, неважно — объединением, сложением, ксором, хэшированием, классическим бит коммитментом, то в подписанный параметр любая сторона всегда может воткнуть хэш от какого-то предварительного заявления. Но это её заявление, которое можно рассматривать как заведомо ложное или как намерение о провокации.
Ещё раз, если у сторон заранее отсутствует предрасшаренный секрет, то за счёт подписей при согласовании, если Алиса раскроет отрицаемую переписку с Бобом:
комментариев: 393 документов: 4 редакций: 0
Тогда я, наверное, неверно понимаю термин "отрицаемость" – какая модель угроз подразумевается?
Возможна ли отрицаемость для Алисы:
– если Ева просто контролирует трафик ее и Боба?
– если Боба позже принуждают к сотрудничеству?
– если он изначально злонамеренній и скооперирован с Евой?
Возможно, так получится этому противостоять (считаем k хешем от компроментирующего заявления):
Алиса и Боб имеют публичные ключи друг друга и доверяют им. Боб инициирует общение с Алисой.
Задача: сгенерировать общий секрет, чтобы включать его в неподписанные PGP-сообщения для своей аутентификации друг перед другом. Так, чтобы Ни Алиса, ни Боб не смогли доказать кому-либо еще, что вторая сторона владеет этим секретом или принимала участие в его выработке, но сами в этом были уверены.
0. Боб генерирует случайное число k, подписывает и отсылает его Алисе. Это единственное сообщение, связывающее его с Алисой. Только она может получить k, и она будет уверенна, что получила его именно от Боба. Третей стороне k неизвстно. Задача протокола – сделать так, чтобы Боб (случайно, позже под нажимом или изначально злонамеренно) не смог позже связать ни факт, ни контекст беседы с Алисой с этим k, но сам мог идентифицировать Алису. То же касается Алисы.
Примечание: предполагаем, что метка времени обнулена, и Боб всегда может утверждать, что посылал Алисе это сообщение и k ранее совсем в другом контексте. Алиса может утверждать, что она это сообщение не получала и k никогда не видела.
1. Алиса генерирует случайное число ra, сохраняет и отсылает Бобу его хеш h. Она уверена, что только Боб может этот хеш получить. Ева может перехватить сообщение, подменить его, но не прочитать.
2. Боб получает h, но не уверен, что его послала Алиса, и не уверен, что факт владения h не скомпроментирует его позже. Он сохраняет его в секретном месте, генерирует свое случаное число rb, сохраняет сам и отсылает Алисе. Он уверен, что только Алиса может получить это число. Ева может перехватить сообщение, подменить его, но не прочитать.
3. Алиса получает число rb от Боба, но она не уверена, что его послал Боб, и не уверена, что факт владения этим числом не скомпроментирует ее позже. Алиса банально ксорит полученное число rb со своим ra, получает s. Т.к. она уверена, что свое число случайное, то и s будет случаен. Теперь Алиса отсылает свое случайное число ra Бобу и тот час удаляет и его, и число rb, полученное от Боба.
4. Боб получает число ra от Алисы, но не уверен, что его послала Алиса, и не уверен, что факт владения этим числом не скомпроментирует его позже. Он сверяет хеш с h, и теперь уверен, что отправитель этого сообщения то же, что и предыдущего, и не менял задуманное вначале число, исходя из полученного числа Боба. Боб ксорит полученное число ra со своим rb, получает s. Т.к. он уверен, что свое число случайное, то и s будет случайное. Боб тот час удаляет h, ra и rb.
5. В итоге у Алисы и Боба могут быть различные s (если внедрилась Ева), но если они одинаковые, то Ева о них гарантированно ничего знать не может. Также Ева ничего не знает о числе k, подписанном Бобоб. Алиса и Боб вычисляют MAC m от результата s, в качестве ключа используют k. Т.к. s случаен и для Алисы, и для Боба (как показано выше), то и m будет случаен. На шаге 1 Алиса не сможет подсунуть вместо случайного такое число, чтобы затем, реверсировав mac, доказать связь m и k. Ни Боб, ни Алиса не смогут показать связь k и m, т.к. число m было рандомизировано другим участником, и связать его с ним невозможно.
Теперь Алиса и Боб могут добавлять m внутрь отправляемых неподписанных PGP-сообщений для идентификации данного приватного сенса связи между ними с обоюдной отрицаемостью, как содержания беседы, так и факта контакта, гарантированной даже в случае изначально злонамеренного собеседника.
комментариев: 9796 документов: 488 редакций: 5664
Похоже на бит-коммитмент (multibit, string-commitment) на хэшах для совместного выведения секрета. С учётом того, что принято инициирующей стороной назначать Алису, можно нагляднее переписать так, вообще без использования подписи в вашем п.0:
Кое-что по теории есть здесь. На стр. 12-14 такие протоколы критикуются как проблемные. Но в чём м.б. проблема в данном случае — сказать затрудняюсь. М.б. частичный MITM?
Отдельную ссылку на то, что это всё напоминает, вынес в /comment73841.
комментариев: 11558 документов: 1036 редакций: 4118
Я рассматриваю по аналогии с OTR: отрицается не факт совершения беседы, а содержимое диалога, т.е. ни одна из сторон не может доказать третьей стороне, что собеседник действительно писал такое. Прослушивание OTR-трафика не позволяет внешнему наблюдателю утверждать что-либо о его содержании. Если Ваша модель допускает контроль Евы над каналами обоих собеседников, то более сильной отрицаемости (отрицание факта беседы) Вы всё равно не добьётесь даже с помощью Tor, ибо атака на подтверждение трафика.
По содержанию беседы — да, по факту беседы — нет.
По содержанию беседы — да, по факту беседы — возможно, если в протоколе вообще не применяются ЭЦП.
Ни по содержанию, ни по факту беседы.
комментариев: 393 документов: 4 редакций: 0
/comment73839
Мне тоже так показалось. Терию почитаю, спасибо.
/comment73790:
Не все так хорошо на самом деле, принимая во внимание тезизы ниже:
/comment73850:
/comment73766:
Но пессимистическая нота: данная схема, к сожалению, обеспечивает только отвязку беседы от ее инициализации и от публичных ключей участников. Но, в отличие от OTR, вся беседа в смысле отрицаемости является единым целым: если один из участников докажет авторство хотя бы одного любого сообщения (по содержанию, уникальной информации, известной только другой стороне и т.п.), то автоматически докажет авторство всех его сообщений. Или я ошибаюсь, и предложенная Вами схема ( /comment73788 ) поможет этого избежать?
Возможно, поможет параллельная PFS с помощью пошаговой DF, но не уверен, что все так просто будет. Как бы в итоге не получился тот же OTR. Что еще раз подтверждает его уникальность.
комментариев: 9796 документов: 488 редакций: 5664
Поможет скорее схема /comment73839 (чуть доработанный вариант вашей же идеи), там вообще нет использования каких-либо подписей изначально. Только шифрование на публичный ключ другой стороны, но обязательно с использованием опции MDC. Вроде, включением повторных H в ответы на запрос, можно даже избежать MITM, но это всё наброски на коленке и бездоказательно. В вышеприведённой работе вроде как указанно, что при соблюдении всех условий с биткоммитментом такие схемы аутентификации работают, но есть отсылки к другим работам, надо разбирать, где там м.б. узкие места.
Если канал совсем анонимный, а всю почту они сливают куда-то на файлообменники и их обратно не отследить, то Еве вроде как ловить нечего.
Даже если A заготовит своё RA за год до этого сеанса переписки, запихнёт в него хэш от содержимого предыдущих подписанных писем Боба, проштампует у третьей стороны — вроде это ничего доказывать не должно. Она дальше может полностью сочинить не только содержимое переписки, но и факт согласования параметров с Бобом.
Видится, например, небольшая утечка такого рода. Алиса пытается снова согласовать параметры с Бобом, утверждая, что предыдущее совместное R было потеряно, но использует для этого новое RA, связанное с предыдущим по какой-то формуле, после чего разглашает эту формулу и свой закрытый ключ на каком-нибудь закрытом форуме. Тогда все его участники могут увидеть, что Боб снова вышел с ней на связь и ведёт компрометирующие его разговоры.
Хотя, вроде факт связи всё равно недоказуем (если канал анонимный) — может это Алиса сама всё шлёт от его имени. Но в общем, если Алиса сдаёт свой ключ под давлением и её изолируют, а от её имени кто-то ведёт диалог с Бобом, то он (кто действует от её имени, а это м.б. целый коллектив свидетелей) может сам убедиться, что Алиса была права. Теперь Боб может только утверждать, что его кто-то подставляет, придумывая сеансы связи помимо Алисы, например, что у неё есть сообщники.
Хуже вариант, когда злонамеренная Алиса-провокатор изначально использовала в качестве своего RA хэш от своего же закрытого ключа (можно похэшировать со вставкой какого-нибудь слова, чтобы было доказательно, но Боб не догадался). Этот закрытый ключ она и предполагала впоследствии разгласить вместе со всеми сеансами и перепиской, проштампованными метками времени и связанными цепочкой хэшей. После раскрытия своего ключа она может дать всем желающим продолжить переписку с Бобом (она может даже подсказывать диалог), так что он ни о чём не догадается и будет думать, что переписывается с ней. Все желающие смогут сами посылать на открытый ключ Боба сообщения под видом Алисы, а он будет отвечать на её ключ, включая в ответы R, выведенное из этого RA.
P.S.: Кажется, составляя этот комент, я поломал все ваши и свои предыдущие наивные протоколы. Не изобретайте протоколы на коленке шифрпанковским способом. Пусть этим занимаются теоретики.
комментариев: 9796 документов: 488 редакций: 5664
Посмотрел протоколы OTR и SKEME. Там всё тоже самое. Если провокатор Алиса инициализирует какой-нибудь генератор случайных чисел хэшем своего закрытого ключа и будет брать во всех сеансах связи параметры с этого генератора, а затем в ходе сеанса связи раскроет всю эту схему третьему лицу или группе лиц вместе со своим закрытым ключом и они вступят в переписку с Бобом от её имени, то они могут убедиться, что переписка с Бобом была подлинной, на другом конце линии им отвечает Боб.
Помимо того, группа лиц может заранее совместно сгенерировать общий секрет и ключ Алисы, чтобы от её имени участвовать в переписке с Бобом. Затем они опубликуют метод создания этого секрета из множества своих ключей (например известной группы хакеров или экспертов правоохранительных органов, или ещё каких разоблачителей) вместе со всей перепиской, разоблачающей Боба.
Или я чего-то не понимаю.
комментариев: 11558 документов: 1036 редакций: 4118
ШОК!!!Участники проекта pgpru.com взломали протокол OTR".комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Я сейчас пытаюсь что-то ответить, попутно мучаясь с местной вики-разметкой. Следите за дальнейшими событиями. Хотя, может мне стоит просто получше выспаться и не торопиться с выводами…
Cейчас думаю над началом сеанса в OTR:
комментариев: 9796 документов: 488 редакций: 5664
Большая группа народу может совместно создать некий секрет R, подписать его всеми своими подписями. На основе этого секрета создать совместно управляемый ключ некой Алисы (журналистки, подставной пособницы преступника и др.), а хэшем закрытой части этого ключа (со вставленной строкой, например "Gotcha, Bob! We are anonymous avengers with real keys 0xXXXXXXX!") инициализировать генератор псевдослучайных чисел, с которого отправлять все параметры Бобу. Так, параметр, XA для gXA будет связан с этим генератором, Боб ответит gXB. У обеих сторон будет вычислен сеансовый ключ gXA XB. Но псевдо-Алиса сможет доказать, что он состоит из помеченного XA.
Дальше надо подумать…
комментариев: 9796 документов: 488 редакций: 5664
Так OTR шифрует сессии, отлично, все помеченные параметры от ГПСЧ Алисы идут в сообщения, да ещё и связываются между собой:
Глава "4.3 Authentication" в прямом и переносном смысле слова — ключевая.
Обе стороны могут подсунуть на подпись друг другу помеченный секрет. Q.E.D.: В лучшем (для стойкости OTR) случае Алиса может доказать, что переписывалась с Бобом или Боб — что с Алисой, если кто-то из них подсуетился заранее. В худшем — подлинность содержимого сообщений, но это пока не вполне ясно.
Дальше, они из него же выводят MAC:
2 SATtva:
Похоже, что нет. И похоже, что это серьёзно.
2 gegel /comment73795:
Если окажется, что и обе половинки никак не помогают, то вам, gegel и вам, Гость из другой темы теперь тоже
никак не отмазатьсябольшое спасибо.P.S.: Надо ещё последнюю версию протокола поковырять.
P.S.S.: Последняя версия в данном вопросе от первой, описанной в исходной работе, ничем существенно не отличается. Стороны всё равно обмениваются подписанными параметрами для вывода совместного секрета DH и получают связанную цепочку сообщений, ключей и MAC, только более сложным способом. Если злонамеренная сторона шлёт все параметры из детерминированного ГПСЧ, а затем раскрывает его алгоритм и ключ (выведенный из своего секретного ключа OTR), то фактически она доказывает и авторство второй стороны,
и подлинность содержимого записанной переписки. Протокол соцмиллионера там сбоку-припёку и обычно используется только как доп. проверка. Плохо, что по последней версии нормальной работы нет.P.S.S.: Насчёт доказательства подлинности содержимого пока сомнения остаются. Первый обмен по DH выдаст общий gxy, на составных частях которого будут красоваться подписи обеих сторон и подставной x из детерминированного ГПСЧ. На всех последующих — выведение MAC'ов, ключей и пр. будут влиять предопределённые x, но y Алиса может выбирать свободно вместо Боба. Может ли Алиса к предопределённым gx подбирать такие y, чтобы получить осмысленный результат во всей последующей переписке? Если может, не нарушая связности протокола со своим ГПСЧ — то тогда она может подделывать переписку, значит содержимое переписки останется отрицаемым. Если не может (и ей нужен реальный Боб) — то тогда отрицаемость действительно теряется и становится доказываемой третьей стороне. Методы с групповой генерацией секрета Алисы, также как и методы с последующей попыткой связаться участникам группы с Бобом через раскрытый ключ Алисы — это вообще отдельные сценарии, ограниченной, скажем так, неотрицаемости содержимого.