Аналог PGP с обеспечением отрицаемости и наперёд заданной секретности оффлайн?

Если очень большой, то может собирать донейты

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

Для начала, проект по безопасности не обязан быть чисто софтварным. Это может быть, например, какое-то специальное железо.

Вот на счет железа у меня лично очень сильный интерес, ну т.е. я вижу в этом большой потенциал и перспективу, вот только снова увы и ах – я человек, дале3ий от IT. И как там будет на счет давления со стороны и внедрения всякого зловреда – понятия ее имею. Скажу так, что по моему личному опыту, даже имея финансы, свой внутренний кодекс Чести и характер – перекрыть кислород вам смогут очень быстро и усложнить жизнь тем более, никому ничего не желаю, люди здесь поумнее меня сидят, просто делюсь опытом, который далек от сказок и теорий.

To unknown:

За основу взял проект tabby (похоже, ефемеральные ключи и хеши там используются в точности так же, как и китайцев).

Вник в работу и понял, что ошибся во втором утверждении: это функционально разные протоколы.

Tabby (аналог HOMQV Кравчика, p.18, slide 40) – однопроходный ассиметричный протокол получения общего секрета с односторонней аутентификацией клиентом сервера. Математика: B^ae+x = X^b + A^eb
(A,B-долговременные DH-пары сторон, X-ефемерал, e-хеш публичных параметров, одинаковый для обеих сторон).
Утечка a безпасна, утечка b компроментирует все временные секреты.

VOAKE – двухпроходный симметричный протокол получения общего секрета со взаимной аутентификацией. Т.е. тот же Дифффи-Хеллманн, но строго аутентифицированный долговременными DH-ключами сторон. Утечки a или b безопасны.
Математика: B^x * Y^xe+a = A^y * X^ye+b
(A,B-долговременные DH-пары сторон, X,Y-ефемералы, e-хеш публичных параметров)

Если вернуться к нашим баранам идеям (адаптация OTR к email), то важны два момента:

• максимально короткий IKE с использованием долговременных PGP-ключей
• работа с ключевым окном, пригодная для высоколатентной среды

По первому пункту мне, несмотря ни на что, нравится протокол Abadi (на него, кстати, ссылались разработчики OTR в первой публикации, но предпочли SIGMA). По второму пункту есть идея использовать HOMQV для реализации пожелания:

Правильный OTR мог бы создавать некое "окно" сессии, идущее как вперед так и назад, с сохранением временных ключей на диске.

Базовая логика OTR (раздел 4.1): обе стороны имеют предварительно взаимно аутентифицированные базовые DH-пары и общий секрет.

– A вводит новую пару Xx и отсылает паблик под маком. Таким образом, B может доверять полученному X.

– B выводит ключ шифрования со своего имеющегося базового привата и полученного паблика. Также B вводит новую пару Yy и отсылает Y под маком. Также B сохраняет полученный паблик как новый базовый.

– A, получив ответ, выводит ключ расшифровки со своего x и базового паблика B, расшифровывает сообщение и получает Y. Далее аналогично.

Все идеально в случае строгого чередования сообщений и отсутствия потерь. Но для реальных условий (потери, опоздания) есть идея при каждой отправке сообщения дополнительно генерировать уникальную эфемеральную пару Сс, выводить ключ шифрования по протоколу HOMQV (используя текущие базовые паблик и приват, как описано выше в случае с обычной DH) и вкладывать С в сообщение, немедленно удаляя с. Т.о. отправленное сообщение может быть прочитано только получателем до нового DH-обмена, но не отправителем. Отправитель может отсылать подряд любое количество сообщений (все содержат одинаковый вновь вводимый X и разные С). Получатель может расшифровывать их в любом порядке, и ему достаточно получить хотя-бы одно для приема нового X. Таким образом, обеспечивается устойчивость к потерям и опозданиям почты. Цена – включение двух DH-ключей в сообщение. Наверное, поэтому описанная идея не была реализована в OTR: 1536 бит – весомая добавка для IM-сообщения. Но использование 256-битных ключей ECDH Curve25519 меняет дело, разработчикам OTR есть смысл добавить их поддержку в свой протокол.

Что касается нового VOAKE, то даже не представляю, как его можно применить в данном случае. В принципе, можно выполнять везде вместо обычной DH в OTR, в качестве A и B используя не долговременные ключи сторон, а текущие базовые параметры. Это позволит аутентифицировать вновь вводимые DH-параметры не под маком, а используя пруф (как рекомендуют в конце работы) для лучшей PFS. Но тогда получается, что в OTR есть изъян PFS, во что с трудом верится. В этом плане стоит еще подумать, особенно в случае вброса детерминированных параметров изначально злонамеренной стороной.

Вот на счет железа

Железо (точнее, embedded софт) приносит прибыли на порядки больше, а open source разарботки в области безопасности не приносят ее совсем, проверено :(

внедрения всякого зловреда

В одном из ранних проектов на 8-битном микроконтроллере с 256 ОЗУ и 8K RAM (маленькая коробочка подключалась к старым мобилам Сименс) я заложил RAT, каждые 10 мин отсылающий на подконтрольный мне домен статистику, пароли, заданные пользователем при конфигурации и т.д.) и дающий возможность полного контроля над устройством. В другом проекте с целью анонимности пакеты отсылались на IP спутникового аплинкера, таким образом выяснить пункт назначения было невозможно. И я с ужасом представляю, что заложено во всех современных девайсах. Поэтому опять приходим к тому же противоречию: доверять можно только хардверным решениям с открытыми прошивками в исходниках, но вот как их в этом случае коммерциализировать? Частично открытые исходники (пример – Silent Circle, Cryptophone) – то же, что и закрытые: обман самого себя.
Ко мне обращались с предложениями сделать коммерческий форк торфона, но и кто им будет пользоваться? Публика с r2d2 и pedoimperia предпочтет open source, а домохозяйки – Skype. Нет целевой аудитории для таких проектов.

Строго говоря, коммерческий ≠ closed source. Яркий пример — коммерческое PGP. Существуют ведь они как-то (в основном, правда, на корпоративном рынке) несмотря не существование полностью открытых и бесплатных TC и DC.

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

Нашел еще одну интересную публикацию 2013 года по теме: вводятся понятия "deniability", "full deniability", KCI attack, SKCI attack; анализируются имеющиеся однопроходные схемы аутентификации и предлагается своя: в одной посылке аутентифицируется и отправитель, и сообщение на основе имеющихся долговременных DH-ключей сторон. Разрабатывалась для почты. Математика достаточно сложная (ElGamal с наворотами), но вполне реализуемая на Curve25519.
Единственное но – использование долговременных DH-ключей из Certificate Authority, все же для почты традиционно характерны RSA и т.д. (PGP, GPG). Поправьте, если я не прав.

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


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

А вот вопрос доверия к самому протоколу — достаточно спорный. Малоизвестные авторы что-то напечатали в вордошнике. Интересен как очередной обзор и показатель сложности проблемы.

2 /comment75999:

Так можно про любую задачу сказать: раз ещё не решили, значит, бьются и решают. А если приглядеться внимательней, то есть, в лучшем случае, 2-3 научных коллектива, а то и вообще всего несколько человек, которым эта задача интересна. Другие занимаются другими задачами.

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

откуда между сторонами возникает первоначальное доверие.

Собственно, это я тоже хотел уточнить. Допустим, стороны уже имеют доверяемые PGP-ключи и хотят использовать (например, в мессенжере) протокол на основе доверяемых долговременных DH-ключей (например, описанный по приведенной выше ссылке). Какие действия сторон? Я так понимаю, надо завести DH-ключевые пары и подписать DH-паблик своим PGP-ключом, затем обменяться подписанными DH-ключами. Этого достаточно? Надо ли включать под подпись дополнительную информацию (Ид, отпечаток времени и т.д.)?

Как-то непонятно, что при этом будет с отрицаемостью и однопроходовостью. Не говоря уже о том, что в работе вроде как не упомянуто PFS.

Я не совсем понятно выразил мысль, извините.
Безусловно, подразумевается использование протокола OTR, обеспечивающего PFS. Но вместо OTR IKE на основе SIGMA используется IKE на основе VOAKE (я имел в виду упомянутую Вами китайскую работу, когда писал о ссылке: там двухпроходный DH-обмен, строго аутентифицированный долговременными DH-ключами сторон A и B). Таким образом, на этапе IKE получаем начальные значения X и Y, полностью отвязанные от A и B. Затем постоянно их обновляем, выполняя OTR. Вопрос в том, как обеспечить доверие к A и B, используя доверяемые PGP ключи сторон.

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

А вот вопрос доверия к самому протоколу — достаточно спорный.

Авторы объединили три прохода эвристики Фиата-Шамира в один, и на вскидку предположить последствия этого объединения нереально – при детальном рассмотрении могут быть неожиданности, тем боле работа свежая, и похоже, мало кем анализировалась. Но выглядит красиво. И библиография познавательная, жаль не все смог найти в открытом доступе.

Нашел ответ на свой же вопрос:

В протоколе OTR ключ аутентификации выводится непосредственно из ключа шифрования

тут (раздел 6.2). Кстати, Кравчик в авторах. OTR разобран "по косточкам". Похоже, сложный механизм своевременной публикации использованных MAC-ключей, который я упорно лепил к своему email-варианту, оказался не особо нужен для отрицаемости. Напрмер, в схожем проекте СМС-шифровальщика MAC-ключи не публикуются, используется режим CBC вместо CTR, MAC выводится из DH-секрета: все точно по рекомендациям в указанной выше работе.

И еще: протокол, описанный в представленной выше unknown китайской работе, тщательно проанализирован (в сравнении с HMQV) в другой работе, показаны свойства PFS и отрицаемости. Похоже, он идеально подойдет как замена SIGMA в начале OTR-обмена, а, возможно, и на протяжении всего OTR-обмена вместо обычной DH для предотвращения атаки деперсонализации при утечке ефемерального ключа (раздел 6.3)

Вот ещё обзор: Anonymous Authentication with Shared Secrets. Работа вроде как не совсем по теме, но там много ссылок на более близкие иследования, например Anonymous Public-Key Encryption: Anonymity-preserving Public-Key Encryption: A Constructive Approach.