id: Гость   вход   регистрация
текущее время 11:43 15/11/2019
Автор темы: gegel, тема открыта 20/11/2013 11:41 Печать
Категории: инфобезопасность, защита email
http://www.pgpru.com/Форум/Криптография/АналогPGPСОбеспечениемОтрицаемостиИНаперёдЗаданнойСекретностиОффлайн
создать
просмотр
ссылки

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


Обсуждение в соседней теме натолкнуло на мысль: существует ли решение, аналогичное PGP и обеспечивающее для оффлайн-сообщений конфиденциальность и аутентификацию, но плюс отрицаемость и наперед заданную секретность (PFS), ну, и, желательно, тихое уведомление о прессинге. Нашел похожий вопрос на crypto.stackexchange: похоже, что готовых решений пока нет. Возможно, где-то на pgpru это уже обсуждалось, или что-то уже появилось?



 
На страницу: 1, ... , 3, 4, 5, 6, 7, ... , 20 След.
Комментарии
— unknown (26/12/2013 11:32, исправлен 26/12/2013 11:33)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


Противник запишет сеанс и когда Алиса будет связываться с Бобом, пошлёт Бобу старое сообщение якобы от Алисы, со старым 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.

— gegel (26/12/2013 11:56)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
но как бы из этого не вывели различитель

Вот это то, что я предполагал услышать, рассуждая где-то аналогично. Напрягусь, подумаю.
Цель определена: сократить подготовку к беседе до двух сообщений: запроса (от инициатора к акцептору) и согласия (обратно). Желательно использовать PGP только в этих сообщениях. А дальше – так или иначе быть готовым писать информационные сообщения и принимать их.
Возможно, Ваша идея объединить шаги завершения аутентификации с nonce и отправки первых сообщений и есть искомое решение.
— unknown (26/12/2013 11:56, исправлен 26/12/2013 12:05)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

A → B: MDC_PKEB (idA, X, r1)
B → A: MDC_PKEA (idB, X, Y, r1, r2, HMACs (idB, r1, r2) )


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


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


A → B: MDC_PKEB (idA, r1, r2, HMACs (idB, r1, r2), HMACs (idA, r1, r2) )
A → B: MDC_SEs (idA, Message)


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


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


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

— gegel (26/12/2013 12:04)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
как бы из этого не вывели различитель

Похоже, упрется в проблему дискретных логарифмов.
— gegel (26/12/2013 12:20, исправлен 26/12/2013 12:21)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

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

— unknown (26/12/2013 12:30, исправлен 26/12/2013 15:27)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


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


A → B: MDC_PKEB (idA, X)
B → A: MDC_PKEA (idB, X, Y, HMACs (idB, X, Y))
A → B: MDC_PKEB (idA, X, Y, HMACs (idA, X, Y)); MDC_SEs (idA, Message)


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


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

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


— gegel (26/12/2013 19:49)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Смотрел на то, к чему мы пришли в итоге, и вдруг дошло: а ведь получилась в точности SIGMA! (filePage 7).

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

Просматривая условия выполнения протокола Abadi (пункт Cryptographic на стр.3), я так и не понял, подразумевается ли обеспечение целостности сообщений (mdc), но в любом случае в нашей модели PGP это обеспечивает.
Как Вы считаете, может, этого будет достаточно? (тем более, что в одном из постов давали ссылку на протокол Abadi, как перспективный).
— unknown (26/12/2013 21:19)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
А в итоге непохоже ни на то, ни на другое. В SIGMA используется MAC совместно с подписями. У Abadi всё как-то мутно — и выведение секрета (там вроде как нет отвязки от ключей через DH, а сразу выводится общий симметричный ключ) и работа, и презентащка, и система доказательств.

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

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

К тому же, в SIGMA понятна идея помещать айдишники внутри MAC, несмотря на аутентификацию подписью всего сообщения целиком.
— gegel (26/12/2013 22:12, исправлен 26/12/2013 22:32)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
У Abadi всё как-то мутно — и выведение секрета (там вроде как нет отвязки от ключей через DH, а сразу выводится общий симметричный ключ)

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


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

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


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


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


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

— unknown (26/12/2013 22:41)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Как Вы тонко когда-то заметили, если бы не было оптимистов-практиков, то все бы до сих пор пользовались одноразовыми блокнотами.

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


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


Его нет в стандартных криптолибах. Ни в OpenSSL, ни в libgcrypt. А другие в кроссплатформенный проект пока тянуть не рекомендуется.
— gegel (26/12/2013 23:35, исправлен 26/12/2013 23:47)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Всё-таки это будет чат, а не почта?

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


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

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

— ntldr (27/12/2013 03:06)   профиль/связь   <#>
комментариев: 371   документов: 19   редакций: 20
– PRNG: внутренний HMAC_DRBG, сидируется при каждом старте
Скоро представлю свою реализацию этого, включая множественные источники энтропии.
fileПредварительная версия реализации SHA512-HMAC-DRBG, комментарии насчет качества кода приветствуются.
— unknown (27/12/2013 09:55, исправлен 27/12/2013 09:56)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Может, это и непрофессиональный подход, но я всегда пытался по максимуму запихнуть в исходный код, чтобы уменьшить зависимость от внешних либ.

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


/comment75083


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

— gegel (27/12/2013 11:05)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Скорее SKEME

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

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

Спасибо, очень интересно, буду разбираться.
— unknown (27/12/2013 11:19, исправлен 27/12/2013 11:48)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


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


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


A → B: MDC_PKEB (idA, X)
B → A: MDC_PKEA (idB, Y, HMACs (idB, X, Y))
A → B: MDC_PKEB (idA, HMACs (idA, Y, X)); MDC_SEs (idA, Message)


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


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

На страницу: 1, ... , 3, 4, 5, 6, 7, ... , 20 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3