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

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

Противник запишет сеанс и когда Алиса будет связываться с Бобом, пошлёт Бобу старое сообщение якобы от Алисы, со старым X:
A->B: PKE _B (X, Pub _A)
Алисе пошлёт старый ответ якобы от Боба со старым Y:
B->A: PKE _A (Y, Pub _B)

Алиса отправит сообщение, думая, что отправляет Бобу.

Боб мог бы получить старый r1, хотя и не сможет расшифровать его из-за подмены (он то отправлял точно новый Y).
A->B: r1, HMACs(r1)

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

но как бы из этого не вывели различитель

Вот это то, что я предполагал услышать, рассуждая где-то аналогично. Напрягусь, подумаю.
Цель определена: сократить подготовку к беседе до двух сообщений: запроса (от инициатора к акцептору) и согласия (обратно). Желательно использовать PGP только в этих сообщениях. А дальше – так или иначе быть готовым писать информационные сообщения и принимать их.
Возможно, Ваша идея объединить шаги завершения аутентификации с nonce и отправки первых сообщений и есть искомое решение.

A → B: MDC_PKE_B (id_A, X, r₁)
B → A: MDC_PKE_A (id_B, X, Y, r₁, r₂, HMAC_s (id_B, r₁, r₂) )

После получения ответа на втором шаге, Алиса уже аутентифицировала Боба по отношению к своему запросу.

Следующие две отправки Алиса посылает параллельно:

A → B: MDC_PKE_B (id_A, r₁, r₂, HMAC_s (id_B, r₁, r₂), HMAC_s (id_A, r₁, r₂) )
A → B: MDC_SE_s (id_A, Message)

Если Боб не может аутентифицировать Алису по первой отправке, то он и не станет (и не сможет) расшифровывать вторую отправку.

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

P.S. На третьем шаге решил не менять местами r₁ и r₂ внутри HMAC, надо только следить, что никакие из пар id и r не совпадают.

как бы из этого не вывели различитель

Похоже, упрется в проблему дискретных логарифмов.

А как Вы смотрите на то, чтобы в вашем примере в качестве r1,r2 в MAC-функции использовать те же X,Y? Ведь они тоже доверяемо рандомны:
HMAC _s ( id_A, X, Y)? Или при этом возможна непредсказуемая интерференция межу DH и HMAC, от греха по дальше?

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

Вроде так будет экономнее по числу и размеру полей:

A → B: MDC_PKE_B (id_A, X)
B → A: MDC_PKE_A (id_B, X, Y, HMAC_s (id_B, X, Y))
A → B: MDC_PKE_B (id_A, X, Y, HMAC_s (id_A, X, Y)); MDC_SE_s (id_A, Message)

По сравнению с вашим вариантом:

1. Число шагов такое же: запрос – ответ – ответ исходной стороны с отправкой сообщения.
2. Вся проверка аутентификации идёт только внутри GnuPG MDC_PKE.
3. Вся аутентификация только на nonce или параметрах DH, не связанных с самими сообщениями в окончательном виде.
4. Отправка сообщения от A идёт только после прохождения стадии аутентификации B. A не высылает сообщение кому-попало, даже в шифрованном виде.
5. После аутентификации можно перейти на MDC_SE как на самом GnuPG, так и на другую схему симметричного рэндомизированного шифрования с аутентификацией.

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

Смотрел на то, к чему мы пришли в итоге, и вдруг дошло: а ведь получилась в точности SIGMA! (Page 7).

Потом посмотрел еще дольше, и с удивлением понял: если отбросить все, начиная с HMAC во второй строчке, то получится протокол Abadi (Page 4), с той разницей, что общий секрет выводится не хешированием половинок, а DH. Причем стойкость этого протокола формально доказана, и вроде как критики не было.

Просматривая условия выполнения протокола Abadi (пункт Cryptographic на стр.3), я так и не понял, подразумевается ли обеспечение целостности сообщений (mdc), но в любом случае в нашей модели PGP это обеспечивает.
Как Вы считаете, может, этого будет достаточно? (тем более, что в одном из постов давали ссылку на протокол Abadi, как перспективный).

А в итоге непохоже ни на то, ни на другое. В SIGMA используется MAC совместно с подписями. У Abadi всё как-то мутно — и выведение секрета (там вроде как нет отвязки от ключей через DH, а сразу выводится общий симметричный ключ) и работа, и презентащка, и система доказательств.

Получилось нечто среднее между SIGMA и Abadi. К тому же ни там, ни там не используется специфическая фича — mdc или она заменяется чем-то другим (подразумевается аутентифицированное шифрование в некоем другом абстрактном исполнении).

К тому же вариантов SIGMA и Abadi — много. Также как мы тут насочиняли сходу массу похожего.

К тому же, в SIGMA понятна идея помещать айдишники внутри MAC, несмотря на аутентификацию подписью всего сообщения целиком.

У Abadi всё как-то мутно — и выведение секрета (там вроде как нет отвязки от ключей через DH, а сразу выводится общий симметричный ключ)

Мутно – да. Сейчас внимательно перечитываю полную версию. В принципе, выводы созвучны с моими, а вот что такое applied pi calculus, и на сколько эти доказательства надежны, я, конечно, не могу судить. Работа свежая (там SKEME цитируется), вполне возможно, пока не дошло дело до критики. Но идея мне нравится, можно рискнуть и попробовать реализовать. Заменить хеширование половинок на DH не проблема, не вижу причин, почему нет: кашу маслом не испортишь...

Пока это всё равно бездоказательный черновик.

Боюсь, что так все и останется, если не рисковать. Как Вы тонко когда-то заметили, если бы не было оптимистов-практиков, то все бы до сих пор пользовались одноразовыми блокнотами.

Поэтому есть идея сделать тестовый консольный софт под Linux, а там, возможно, кто-то заинтересуется и наши идеи оценит раскритикует.

Как на счет следующих криптопримитивов:
– ассиметрика: ECDH Curve25519 (все же размеры DH-паблика критичны);
– симметрика: Serpent-128 (на 256 ECDH не тянет), к AES как то душа не лежит;
– хеши: PKDF2, HMAC-SHA256
– PRNG: внутренний HMAC_DRBG, сидируется при каждом старте (т.е. при каждой операции с сообщением), с ориентировочной оценкой ентропии до заданного уровня (типа как у Yarrow), получаемой из девиации интервала между нажатиями клавиш. Если будет не юзерофильно, то, возможно, добавлять меньше энтропии, но сохранять seed-файл.

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

Как Вы тонко когда-то заметили, если бы не было оптимистов-практиков, то все бы до сих пор пользовались одноразовыми блокнотами.

Маловероятно, что буквально так и это не была ирония, вынутая здесь из контекста ;-)


Всё-таки это будет чат, а не почта?


Его нет в стандартных криптолибах. Ни в OpenSSL, ни в libgcrypt. А другие в кроссплатформенный проект пока тянуть не рекомендуется.

Всё-таки это будет чат, а не почта?

Почта (типа GPG), но с реализацией OTR. Т.е. внутри каждого письма будет и DH-паблик, и старый MAC-ключ (публикация неиспользуемых MAC-ов для repudiability), и еще пару фишек (большинство решений из OTR, я их реализацию разобрал "по косточкам"), адаптированных к Email. Я постараюсь схематично набросать весь предполагаемый протокол, а потом – и полную подробную его реализацию. В отличие от OTR, хочу сделать FS в пределах ключевого окна (чтобы выдержать правило: для каждого сообщения – всегда новый ключ, по меньшей мере выведенный из предыдущего).
Больше всего места займет DH-паблик (как минимум 2048 бит для обеспечения 128-битной секретности). А для ECDH – всего 256.

Его нет в стандартных криптолибах.

Скачал референс-код с домашней странички, скомпилировал под Ubunta (gcc) и Win32 (MSVC6 и BCB), сверил тест-вектора – все ОК.
Может, это и непрофессиональный подход, но я всегда пытался по максимуму запихнуть в исходный код, чтобы уменьшить зависимость от внешних либ. Имея исходный код, даже начинающий программист может всегда проверить тест-вектора любых используемых примитивов и убедиться в их валидности, тем более что этих примитивов – кот наплакал.

– PRNG: внутренний HMAC_DRBG, сидируется при каждом старте

Скоро представлю свою реализацию этого, включая множественные источники энтропии.
Предварительная версия реализации SHA512-HMAC-DRBG, комментарии насчет качества кода приветствуются.

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

В Torproject так делают, но только если алгоритм ожидается во внешних либах, но пока ещё не появился в стабильных версиях.

/comment75083

Скорее SKEME или гибрид SKEME, SIGMA и GnuPG-mdc.

Скорее SKEME

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

Предварительная версия реализации SHA512-HMAC-DRBG

Спасибо, очень интересно, буду разбираться.

Или попытка больше продвинуть именно такой базис, а не сам протокол. Его метод доказательств мне неизвестен, в мейнстримной криптографии он (пока?) не используется.

Собственно, как хотите. Мне как-то Кравчик понятнее. Чтобы не гонять одни и те же параметры кроме id, как у Кравчика и показано, и вернуть перестановку параметров внутри MAC, я пока бы остановился на таком:

X = g, p, g^a mod p
Y = g, p, g^b mod p
s = KDF ( g^a )^b mod p = KDF ( g^b )^a mod p

A → B: MDC_PKE_B (id_A, X)
B → A: MDC_PKE_A (id_B, Y, HMAC_s (id_B, X, Y))
A → B: MDC_PKE_B (id_A, HMAC_s (id_A, Y, X)); MDC_SE_s (id_A, Message)

С проверкой на неравенство всех пар id, X и Y между собой, ну и параметры DH тоже проверять, как положено.

Для этого можно даже скрипт на питоне или баше написать (вокруг OpenSSL) и воткнуть прослойкой в переписку обычной GnuPG почтой, которая бы привлекала меньше внимания, чем какой-то рэндомный набор битов, полученный специальным протоколом.