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

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


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



 
На страницу: 1, ... , 12, 13, 14, 15, 16, ... , 20 След.
Комментарии
— gegel (26/08/2014 19:33, исправлен 26/08/2014 19:37)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Господи, в чём у вас PhD?

Я стараюсь об этом или совсем не говорить, или шепотом. Но, если уж пошла такая пьянка, у Вас есть есть чувство юмора и под вами крепкий стул, то 14.01.02, защищена в 1997. И, чтобы повеселить окончательно, добавлю сертификат на семейную практику. Ну а теперь, как в том анекдоте про Ржевского: молчать, господа гусары!


смотрите внимательнее.

Вот что настораживает: в раунде n обе стороны вводят новые ключи Xn+1 и Yn+1, шифруя их с помощью SEsn, но не аутентифицируя. В следующем раунде n+1 одна из сторон первой отсылает сообщение, зашифрованное SEn+1, выведенным с участием полученного, но пока не аутентифицированного ключа Xn+1 (или Yn+1). Возможно, спасает PGP-обертка или MDC, или же я не заметил еще какой-то элемент, но это кажется не хорошо. Может, лучше передавать Xn+1 и Yn+1 открыто (т.е. только под PKE: все же это публичные ключи), но аутентифицируя их с помощью MACsn?
И еще одна мысль: зачем в выведение SPRFDID включать Message? Если это не улучшает безопасность, то в теории потенциально ухудшает отрицаемость.
Ну и совсем креатив: может, SPRFDID выводить с помощью того же s, что и MAC, но играя с параметрами (скажем, переставляя местами X и Y и оставляя на месте IDA и IDB? Конечно, это не улучшит свойства (а, может, и наоборот), но смотрится изящнее.


PS: спасибо за LaTeX-src, буду на них ориентироваться.

— unknown (26/08/2014 22:07, исправлен 26/08/2014 22:44)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Медицинские работы бывают весьма сложными, особенно исследовательские с использованием физических приборов, но оформлены обычно отвратительно, да. Правда и не в ворде, а в каких-то пакетах вёрстки мед. пэдээфники выглядят несколько лучше. Я ориентируюсь в своих впечатлениях по зарубежным медпубликациям. Ну и кстати, вам есть куда стремиться, по примеру одного известного врача-анестезиолога, который самостоятельно изучал ВУЗ-овскую программу по компьютерным специальностям.



Xi+1 и Yi+1, которые фактически извлекаются в текущем раунде, в последующем раунде обозначаются как Xi и Yi и идут под MAC вместе с другими параметрами. Если их подменить, то результат MAC с вычисленным из них s не совпадёт.



Верно, у нас уже есть R, который всё равно удаляется после всех вычислений. После нулевого раунда стороны могут посылать друг другу разные R. Надо только приделать индексы RA и RB.



Раз будут RA и RB, то всё ещё проще и изящнее. Другое дело, что s и s' всё равно лучше иметь разные для MAC и SE, а поскольку в SPRFDID результат MAC обрабатывается KDF, то и было решено использовать s'. Кроме того, в изначальном варианте, туда включалось и Message, которое по вашему замечанию можно убрать. Если его не убрать, то использовать одинаковый s нельзя, так как результат вычисления такого же MAC уже передаётся в сеансе.


Ну и с перестановками хватит играть: id идут в порядке «от кого к кому», а X и Y также идут в том же порядке, что и в основном MAC. Некрасиво лишний раз переставлять, кроме как один раз попарно.


Надо также учесть, что в нулевом раунде R — одинаковые. И вообще надо подумать насчёт атак «отзеркаливания», чтобы стороны намеренно не посылали друг другу одинаковые X и Y, RA и RB и т.д. Неприятно, что R, который предполагалось удалять сразу после извлечения Message, теперь надо хранить до получения другого R ответной стороны. Т.е. в хранимых параметрах мы отрицаемой аутентификации не получаем в течении раунда.


Хуже того, так же как Perfect Forward Secrecy, так и Perfect Forward Deniability ломается для последующих сеансов после одного скомпрометированного. Если для PFS это не так критично: противник не может прочитать предыдущие сообщения, часть информации от него скрыта, то для PFD — это фатально. Информация то скрывается одна и та же. И если противник захватит все параметры текущего сеанса, то он может послать запрос другой стороне или пассивно дождаться ответа от неё и увидеть, что сторона корректно ответила на текущие секретные параметры, тем самым выдав свою аутентификацию. Нельзя только строго доказать, что предыдущие сеансы аутентификации имели место именно с ней, но это делает всю концепцию достаточно ограниченной.


Ещё можно вернуться к идее всё-таки использовать две пары X и Y параллельно, чтобы выводить разные s для передачи в одну и другую стороны, но пока я к этому не готов и если решить так делать, то это стоит оставить на самый заключительный этап. Также как и прикручивания цепочек KDF для удобства использования симметричного суррогата PFS в пределах некоего короткого окна времени.


Исправленная с учётом ваших замечаний и моих соображений версия будет v.0.02, но скорее она тоже будет только промежуточная, здесь ещё много над чем надо работать.



Они очень черновые: лишние скобки в первой же формуле, нужные пробелы где-то включены в знак модуля, а где-то окружают его спецсимволами снаружи. Ужас, не ориентируйтесь на это пока. Правится очень на скорую руку, урывками между дел, а копипастить текст исходников и заливать отдельно рендеринг формул на сайт — тоже достаточно неудобно. Но хоть удобнее хранить, воспринимать и использовать в дальнейшем, чем обычную форумную вики-разметку.

— gegel (26/08/2014 23:09, исправлен 26/08/2014 23:19)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Xi+1 и Yi+1, которые фактически извлекаются в текущем раунде, в последующем раунде обозначаются как Xi и Yi и идут под MAC вместе с другими параметрами. Если их подменить, то результат MAC с вычисленным из них s не совпадёт.

Возможно, я что-то недопонял, или же Вы меня неверно поняли. Допустим, в текущем раунде стороны получили друг от друга новые X и Y. В этом раунде они их никак не аутентифицируют (не считая MDC). В следующем раунде кто-то первый должен написать сообщение, выводя из них секрет и аутентифицируя им параметры. Но он не может быть уверен на этом этапе, что получил X от участника, а не кого-то другого (опять же, MDC не берем пока во внимание). Может, есть смысл вновь вводимые ID включать под MAC вместе с текущими уже на этапе (раунде) их введения?


копипастить текст исходников и заливать отдельно рендеринг формул на сайт — тоже достаточно неудобно

Идея с LaTeX-движком сразу понравилась: так начинающим было бы гораздо легче освоить. Не знаю, на сколько это реально (не специалист в web), но если реально, то оно того стоит.

— unknown (26/08/2014 23:25, исправлен 27/08/2014 00:06)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Теперь согласен с вами. Всё, что пошифровано, должно быть и аутентифицировано по месту.



А вот в этом я смысла не понимаю. SPRFDID вычисляются из уже аутентифицированных параметров на месте и никуда не отправляются до следующего сеанса.


Предполагаю в следующей версии обозвать их для краткости Sid (Synthetic ID), а полное название SPRFDID оставить только где-нибудь в описании протокола. Пожалуй, есть смысл не запариваться над s и убрать s'. Там логичная и сочетающаяся перестановка параметров для Sid будет. Нельзя, есть золотое правило — для шифрования и аутентификации — разные ключи, пусть даже выведенные из одного общего. За исключением случаев режимов аутентифицированного шифрования за один проход (как в Keccak).



1. Простой веб-движок, типа MixTEX — ужасен, LaTeX-to-PNG — лучше.
2. Могут быть небольшие разночтения в отображении и особенностях поддержки синтаксиса того, что стоит на серваке с тем, чем привыкли пользоваться.
3. Установка LaTeX-движка резко снижает секьюрность сайта. Разве только такую возможность оставить только очень доверенным пользователям. Но вот один ценный пользователь у нас почти всё время, например, пишет из под гостя.
4. SATtva всё равно это не сделает по причине трудоёмкости даже более простых работ над новым движком.
— gegel (27/08/2014 00:00)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Хуже того, так же как Perfect Forward Secrecy, так и Perfect Forward Deniability ломается для последующих сеансов после одного скомпрометированного.

Это важно для протокола. Не хотел Вас сбивать, но лучше будет смотреть в сравнении, чтобы выдержать хотя-бы качества Axolotl.
Вот мой вариант (выпилил все лишнее, оставил саму суть; также можно считать, что все сообщения завернуты в PKE). Попробую тщательно сравнить с вашим на предмет утечки PFS/PFD при компроментации.

H: Keccak
sij – секрет, выведенный с Xi и Yj

IKE:

A:
генерирует x0 X 0
A->B: MDC PKEB (idA, X 0)

B:
генерирует y0 Y 0
B->A: MDC PKEA (Y 0, H(idB | s00))

Обмен:

A:
генерирует x1 X 1
kenc = H(s00 | s10)
A->B: SE kenc (PlaneText), MAC kenc (CiferText), X 1

B:
kdec = H(s00 | s10)
проверяем MAC, дешифруем
генерируем y1 Y 1

kenc = H(s10 | s11)
В->A: SE kenc (PlaneText), MAC kenc (CiferText), Y 1

A:
kdec = H(s10 | s11)
проверяем MAC, дешифруем
генерируем x2 X 2

kenc = H(s11 | s21)
A->B: SE kenc (PlaneText), MAC kenc (CiferText), X 2
— unknown (27/08/2014 00:07, исправлен 27/08/2014 00:12)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

[граммарнаци]
Plain и Cipher
[/граммарнаци]



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

— Гость (27/08/2014 01:40)   <#>

Лёгки на помине. А это тогда не вы ли были, случаем? ☺ Прочитал 14.01.02 как 01.04.02. Подумал, при чём тут сертификат на семейную практику (там разве что сертификат на отстрел охоту на фриков выдают, как Луговскому в своё время). Интересно, в ныне висящем опросе на главной странице вы к кому себя отнесли — технарям или гумманитариям? В любом случае, когда вы сюда заходите, здесь играет ваше второе нутро — электронщика-любителя (или даже электронщика-профессионала — ведь никто не говорил, что у вас нет второго в/о в какой-нибудь иной области).


К своему стыду, должен признаться, что никогда не читал медицинских работ (или глядел настолько быстро и поверхностно, что этот факт в голове не отложился). Мне всегда казалось, что если факты можно достоверно подтвердить и объяснить, то это биология, а если «мы не знаем, но надо же что-то делать!», то это медицина. Последняя была официально отделена от «науки» (естествознания) ещё с античных времён, как и право с музыкой, и эта ситуация сохраняется до сих пор. У них вместо arXiv'а/IACR'а PubMed, но это ещё пол беды... По ссылке пишут, что у них даже собственные индексаторы! Т.е. Web of science и скопус их типа не касаются(?). Впрочем, в биофизике есть подраздел

Медицинская физика (методы диагностики, физиотерапии и патогенез)

И у этой медфизики кафедры по всей стране. Чем они там занимаются — без понятия. Мне всегда казалось, что разрабатывают приборы для медицинской диагностики.


14.01.02 — это не по-гусарски, немножко переборщили, надо было 14.01.01. Впрочем, случаи «у меня ЗПР/ППР, помогите разобраться в себе» — это тоже неплохо. Если ребёнок в 10 лет пишет программы на C — это ППР или норма? Короче, изучайте LaTeX — достаточно взять файл-заготовку из сети и потом редактировать её под себя, есть очень хорошие стилевые файлы. А иначе unknown'у придётся поставить вам страшный диагноз «задержка CS-развития» и прописать гормоны CS-роста. Они опасны и могут привести к непредсказуемым результатам (ссылку на анастезиолога уже привели).


А всё равно некрасиво смотрится. Главное ведь — это форма, а не содержание. Внешний эстетизм очень важен, он отражает эстетизм внутренний, содержательный. Без него в криптографии никуда — даже пароли не сможете запомнить.

привлекали «магические» математические значки, которые «что-то значат», которыми можно «магически» предсказать результат измерения, не осуществляя эксперимент

Рисование и черчение значков надо любить.

В вики LaTeX-разметка тоже часто ужасно выглядит, хотя на некоторых сайтах (и даже страницах вики) находят способы сделать всё хорошим. Шрифты крупные, например, формулы поэтому на фоне основного текста смотрятся вычурно, как с другой планеты. Сразу скажу, что шрифт для формул в LeTeX'е связан со шрифтом основного текста, чтобы всё смотрелось органично (можно переопределить руками, но так обычно не делают). Т.е. если я в преамбуле сказал \usepackage{palatino} или \usepackage{times}, мне это поменяет и шрифт текста, и шрифт формул, чтобы всё было консистентно. Размер шрифтов текста и формул тоже, конечно, связан. Если по-хорошему, то LaTeX должен быть не в довесок к движку, а вместо него, т.е. и текст комментариев, и текст самих страниц wiki должен форматироваться LeTeX'ом. Понятно, что это слишком, SATtva упадёт в обморок от таких запросов на это не пойдёт. ☺


Вопрос, что делать с формулами и LaTeX'ом тут обсуждается уже 7 лет [1], [2]. ☺


Речь поди о флудере из этого поста? Я уже привык обходиться html- и wiki-разметкой. В сорсе выглядит коряво, но на печати получается намного лучше, чем присобаченный непонятно с какого боку (см. выше) LaTeX. Однако, другое дело, что тут разметка неполная — иногда надо лишние пробелы доставлять, нельзя поставить индекс один под другим и т.д. Всё это в новом движке можно было бы пофиксить. Ну, и, чтоб совсем трудно набирать не было, лучше имплементировать сабсет возожностей LeTeX'а в движке, совместимый с ним по синтаксису. Прежде всего, нужна умная экранировка, потому что (в CS это меньше, но, в принципе, тоже так) шрифт букв в формулах по умолчанию — курсив, а шрифт букв в основном тексте — по умолчанию прямой.


А меня в 5 лет на балет водили. Руководитель не смог замотивировать, поэтому быстро расхотелось и бросил (не без крови, синяков и скандалов, конечно, т.к. родители были против). Почему это было бы круто, понял лет 10 спустя, да поздно уже было.
— Гость (27/08/2014 01:52)   <#>

Лучше пишите так: A&rarr;B, или так: A &rarr; B. На печати будет: A→B или A → B.


i и j — переменные, а все переменные по конвенции пишутся курсивом, поэтому, если опускаться до буквоедства, то должно быть sij. Разметка:
""s""vv//ij//vv вместо ""s""vvijvv)
— Гость (27/08/2014 01:56)   <#>

Блин. Вообще, в LaTeX есть 3 стандартных шрифта: прямой, наклонный (\textsl{}) и курсив (\textit{}), т.е. италик/oblique. На pgpru.com курсива нет, но есть наклонный шрифт, поэтому местами получается чушь, но вы, думаю, поняли, к чему я (используем наклонный вместо курсива за неимением лучшего).
— unknown (27/08/2014 09:39, исправлен 27/08/2014 10:45)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

[искромётная ирония и тонкий юмор]
Идея с веб-эмулятором Linux сразу понравилась: так начинающим было бы гораздо легче освоить. Не знаю, на сколько это реально (не специалист в web), но если реально раздать всем шелл-доступ к серверу (лучше сразу рутовый) в javascript-эмуляторе терминала прямо в браузере, то оно того стоит.
[/искромётная ирония и тонкий юмор]


Сегодня (и уже давно вчера) все хотят LaTeX-движок, завтра заходят диаграммы, блок-схемы, графики и пр. Чтобы обойтись малой кровью предлагается пока рендерить это самостоятельно в PNG или SVG, а на сайт вместе с картинкой заливать исходник, только чтобы в будущем его можно было компактно убрать под кат, чтобы глаза не мозолил. Внёс такое пожелание.

— unknown (27/08/2014 12:20)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
V.0.02, перезагружайте картинки, если они у вас в браузере кэшируются.
— Гость (27/08/2014 16:39)   <#>

Вы не поверите, но латеховские пакеты позволяют делать всё вами перечисленное. Блок-схемы и картинки — откройте для себя tikz. Графики — забыл название, но тоже есть пакет, который можно подключить, ты ему набор точек (x,y), он тебе — график. Я обычно использую overpic — это позволяет нарисовать поверх графика всё, что угодно, как в тексте (формулы, стрелки, линии, пометки).
— unknown (27/08/2014 16:48, исправлен 27/08/2014 21:24)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Я знаю, но не стоит это всё прикручивать к движку. Веб-версия SAGE тоже существует.


V.0.021. Убрал KDF после MAC в выводе Sid.
V.0.022. В нулевом раунде каждый Sid считается через Ra и Rb, также как и в последующих

— gegel (27/08/2014 21:32, исправлен 27/08/2014 21:35)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
надо было 14.01.01

все из-за близорукости: нос был постоянно мокрый


А это тогда не вы ли были, случаем?

Прикольно: оказывается, я тут не одинок. Действительно, ЭхоКС также входила в инструментальные методы исследования в моей старой работе, и трактовать показатели КДО и КСО, конечно, могу. Но и отвязанный от TBB Tor тоже, вроде, настроить могу (судя по отывам педофилов, успешно пользующих Торфон).


V.0.022

Красиво: под МАС-ами вроде все параметры неповторяемо переставляются как для аутентификатора сообщения, так и для SID-ов.
Я не смог интуитивно на вскидку уловить, какие параметры стороны хранят между раундами и в течение раунда между запросом и ответом. От этого зависят последствия одномоментного компроментирования.
В моем варианте старые и новые DH-параметры (приватные ключи) одновременно существуют лишь в момент выведения ключей зашифровки и расшифровки (нужны и старые, и новые, чтобы вывести ключи раунда), поэтому последствия одномоментной утечки данных с диска сведены к минимуму.

— unknown (27/08/2014 21:37, исправлен 27/08/2014 21:58)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Вопрос: можно ли вообще выкинуть RA и RB? Раз уж под SE вместе с Message передаётся Xi+1 и Yi+1, то он и сам по себе играет роль такого R. В ранней версии дискуссии похожие R я уже выкидывал. Тогда сообщения с предыдущих раундов можно безопасно сохранять и безо всяких манипуляций с R. По ним всё равно нельзя будет восстановить аутентификацию, т.к. X и Y меняются от раунда к раунду.


Ответ: нельзя. RA и RB нужно сохранять в пределах текущего раунда, а для следующего надо хранить: Xi+1 и Yi+1, SidAi+1, SidBi+1. Так что сохранённые сообщения уже безопасно хранить по завершении текущего i-ого раунда, а если бы не было R, то безопасность хранения возникала бы только при завершении i+1 раунда.

На страницу: 1, ... , 12, 13, 14, 15, 16, ... , 20 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3