В Cryptocat (http://www.opennet.me/opennews/art.shtml?num=34438), нацеленном на обеспечение приватности web-чате, в котором шифрование производится на стороне браузера клиента и на сервер поступают уже зашифрованные данные, выявлена (http://tobtu.com/decryptocat.php) проблема безопасности, делающая возможным доступ к отправленным сообщениям. Проблема проявляется начиная с выпуска 2.0 и заканчивая версией 2.0.41, таким образом все сообщения отправленные с 17 октября 2011 года по 15 июня 2013 года подвержены указанной уязвимости.Cryptocat позиционируется как проект, использующих для защиты частной переписки надёжные технологии шифрования, такие как алгоритм AES-256 и методы криптогрфии по эллиптическим кривым (http://ru.wikipedia.org/wiki/%D0%AD%D0%B.... История поучительна тем, что тривиальная ошибка в коде свела всю надёжность системы на нет и поставила под вопрос доверие к компаниям, осуществляющим аудит и сертификацию в области безопасности - компания Veracode утвердила Cryptocat на уровень безопасности Veracode Level 2 и оценила качество кода как 100/100. Негативный осадок также остался после попытки разработчиков Cryptocat скрыть свою ошибку, указав (https://github.com/cryptocat/cryptocat/commit/f199fcbe4b5c5d... что исправление произведено для решения проблем с обратной совместимостью.
При создании ключа шифрования, для обхода проблем с качественном генерацией случайных чисел на стороне браузера, пользователю предлагается ввести 256 случайных символов. Из-за неправильной конвертации строк в качестве случайной последовательности поступает не массив из 15-разрядных целых чисел, а массив из чисел от 0 до 9, т.е. вероятность подбора каждого числа снижается с 2^15 до 10 вариантов. В итоге ключи создаются в условиях недостаточной энтропии и могут быть подобраны с использованием bruteforce-атак. По заявлению исследователя, выявившего уязвимость, зашифрованные записи чата могут быть дешифрованы за считанные минуты. Разработчики Cryptocat уже устранили (https://blog.crypto.cat/2013/07/new-critical-vulnerability-i... уязвимость, но утверждают, что проблеме подвержены только групповые чаты с более чем двумя участниками.
URL: http://www.h-online.com/open/news/item/Cryptocat-s-false-sen...
Новость: http://www.opennet.me/opennews/art.shtml?num=37370
> что исправление произведено для решения проблем с обратной совместимостью.Вот такая вот обратная совместимость...
А потом некоторые удивляются, почему для продакшна лучше брать "древности", которым не один год. Вот поэтому.
Ну да, прикольно же юзать не фикшеную версию.Да и вон дебианщики умудрились и вполне себе древний OpenSSL соптимизировать. Криптография просто чувствительна к "небольшим" продолбам. Вот и все.
> Да и вон дебианщики умудрились и вполне себе древний OpenSSL соптимизировать. Криптография просто чувствительна к "небольшим" продолбам. Вот и все.User294, еще не надоело про одну и ту же проблему многолетней давности рассказывать? Может быть найдешь несколько более свежих примеров?
Все идет, все меняется... Но некоторые посетители этого форума остаются законсервированными.
> User294, еще не надоело про одну и ту же проблему многолетней давности
> рассказывать? Может быть найдешь несколько более свежих примеров?Я не злопамятный, но злой и память у меня хорошая. Знаешь, мне пришлось резко отрекеить энное количество машин. А это некоторая возня. Так что вот.
> Все идет, все меняется... Но некоторые посетители этого форума остаются законсервированными.
Общие принципы и подходы применяемые в криптографии не так уж и изменились, а грабли все те же :)
А причём тут дебиан? Это проблема аудита, как и в этой кстати новости написано. То обновление Debian проверили и одобрили авторы OpenSSL.
> Это проблема аудита, как и в этой кстати новости написано.Ну да, конечно. У разработчиков, конечно, никаких проблем - это ведь не их косяк?
> То обновление Debian проверили и одобрили авторы OpenSSL.
Ну если очень сильно вырывать из контекста, то да, одобрили (убрав, например, первую часть фразы):
> If it helps with debugging, I'm in favor of removing them.
>> If it helps with debugging, I'm in favor of removing them.Отсюда ниоткуда не следует что это приведет к проблемам. Так что оба хороши.
пока где слово "подходит для релиза"? в местах связаных с криптухой - это чуть чуть разные вещи.
>>> If it helps with debugging, I'm in favor of removing them.
> Отсюда ниоткуда не следует что это приведет к проблемам. Так что оба
> хороши.Не следует, но я не увидел ничего наподобие: "yes, it's safe to remove them", поэтому не считаю это ни одобрением, ни взятием на себя ответственности.
> Отсюда ниоткуда не следует что это приведет к проблемам. Так что оба хороши.В целях дебага код можно корежить любым образом, отрезая любые куски функциональности.
Именно поэтому такой код не должен выходить за рамки личных бранчей экспериментатора.
> В целях дебага код можно корежить любым образом, отрезая любые куски функциональности.Дебажить криптографию не в том виде каком она будет у юзерей - довольно странный подход.
> Дебажить криптографию не в том виде каком она будет у юзерей - довольно странный подход.С вашей логикой нужно полностью похоронить юнит-тестирование - ведь оно тестирует отдельные участки кода, а пользователь использует продукт целиком.
> С вашей логикой нужно полностью похоронить юнит-тестирование - ведь оно тестирует отдельные
> участки кода, а пользователь использует продукт целиком.Пиндеж. Тестируются участки кода в виде как они будут у юзера. А если вы там поотключали половину а потом у юзерей включили обратно - это не юнит тестирование а буллшит, толку с которого будет буй.
Впрочем, сказ о полезности юнит-тестирования сильно преувеличен. Я видел сотни, если не тысячи случаев когда по юнит тестам все за...сь, а в релизе крутейшие и очевиднейшие баги. Так что да, я как специалист в области могу подтвердить эту мысль: юнит-тестирование далеко не панацея и многие классы багов не замечает как таковые. Т.к. взаимодействие кусков кода между собой как раз никак и не тестирует.
> Тестируются участки кода в виде как они будут у юзера.Пиндеж. У юзера будет _весь_ код целиком, и никак иначе.
> Пиндеж. У юзера будет _весь_ код целиком, и никак иначе.И именно поэтому основную массу тестирования имеет смысл проводить когда все собрано уже именно в таком виде. Если что - лично видел как при обложенности юнит-тестами совершенно эпические баги улетали в релиз. Такая фигня.
>> В целях дебага код можно корежить любым образом, отрезая любые куски функциональности.
> Дебажить криптографию не в том виде каком она будет у юзерей -
> довольно странный подход.Дебажить все что угодно не "в конечном виде" это вполне естественный подход. Добавляешь, убираешь, временно меняешь, да все что угодно творишь. Цель-то найти ошибки, недостатки и т. п. А уж после исправлений и доработок собираешь все как должно быть и тестируешь уже в таком виде как будет у юзверей.
> Дебажить все что угодно не "в конечном виде" это вполне естественный подход.Только заканчивается это тем что теоретически все вроде работает а на практике юзеры грохочут кирпичами от кучи крутейших багов.
>> Дебажить все что угодно не "в конечном виде" это вполне естественный подход.
> Только заканчивается это тем что теоретически все вроде работает а на практике юзеры грохочут кирпичами от кучи крутейших багов.Ой, а может расскажете как можно найти какую-нибудь нетривиальную ошибку не внося каких-либо временных изменений (ну чтоб оставалось "в конечном виде")?
Общего рецепта вообще не существует, в ряде случаев отлов бага может быть весьма индивидуальной операцией. Более того - иногда бывает феерическое западло когда при включении расширенного логгинга, трассировке или что там еще - условия немного меняются и баг вообще пропадает. Ну мало ли, был race condition а при попытке его словить - времянки чутка уехали. Вот это уже вообще полный ахтунг. А ведь такое бывает, и все бурно радуются - у них в дебажном режиме все работало, а у юзера - бабах. Да еще и информацию о проблеме не собрать никак - порой баг пропадает или становится редким :)
Да все индивидуально. Но даже пропадание бага при включении отладки - это уже кое-какая информация и уже некий путь к нахождению проблемы (если повезет). Но меня-то пытались убедить что вообще внесение каких-либо временных изменений для дебага - это странно ибо "будет не как у конечного пользователя". Любые изменения, которые могут дать информацию о проблеме - оправданы и правильны для дебага. Вот пихать свои отладочные "заглушки" в релиз - вот это странный подход, но речь-то шла не об этом.
> Да все индивидуально. Но даже пропадание бага при включении отладки - это
> уже кое-какая информация и уже некий путь к нахождению проблемыЗачастую такая ситуация является полным ребусом, на распутывание которого можно убить очень много времени всех участников процесса.
> (если повезет). Но меня-то пытались убедить что вообще внесение каких-либо
> временных изменений для дебага - это странно ибо "будет не как у конечного
> пользователя".Именно так. Нормальная практика - тестировать софт по максимуму в том виде каком он будет у юзеря. Один в один. Вот тогда есть надежды что эпического масштаба баги до релиза не доживут. Юнит-тесты проверяют лишь корректность работы отдельных кирпичей. А свойства того что из них построили - не проверяют. И как-то так получается что один строит сарай а другой - дворец. Хотя кирпичи вроде одинаковые по качеству. У кого-то потом все рушится, а у кого-то стоит веками. Хотя казалось бы, кирпичи одинаковые. Оказывается, влияет еще и как их между собой стыковали. А юнит-тесты на это вообще плюют.
> Любые изменения, которые могут дать информацию о проблеме - оправданы
Когда как, когда как. Если при изменениях баг вообще ныкается под ковер - это вообще свинство форменное :). Потому что и оставить так нельзя, и отловить сложно.
> и правильны для дебага. Вот пихать свои отладочные "заглушки" в релиз
> - вот это странный подход, но речь-то шла не об этом.Ну так основное тестирование должно приходится на релизную версию все-таки. Потому что после включения отладочных фич баг может пойматься. А может и не пойматься. Прецеденты были.
ой, «плавающие» баги — это сказка, конечно. чем дальше — тем страшнее.и да: в релизных версиях я, например, обычно оставляю всё логирование, оно просто вырублено глобальным флажком. часто в локализации бага, который у меня вообще не проявляется никак, помогает просьба запустить со включеными логами и потом прислать этот выхлоп. это при условии, что с логами баг не пропал, конечно. а если пропал… ну… «запускайте с логами, мы тут сами всем офисом ничего не понимаем!» :3
> Именно так. Нормальная практика - тестировать софт по максимуму в том виде
> каком он будет у юзеря. Один в один.Вот! Ключевое слово - "тестировать"! Тестировать - да, именно то, что будет у юзверей. Но дебажить - нет. Для отладки корежу все и как хочу - лишь бы найти и исправить (все остальное, что вы описываете это просто возможная нетривиальность отладки - кто ж спорит что всякое бывает, если баг "уходит" при попытке поймать одними средствами, значит надо ловить с другой стороны и т. п.).
Повторю еще раз - меня убеждали в том, что даже для поиска ошибок ничего трогать не надо. Речь шла НЕ про тестирование "релиза" в максимально приближенных к боевым условиях (стал бы я с этим спорить), а именно про дебаг - процесс поиска и устранения ошибок, что их тоже надо искать в таких же условиях, на что я возражал, что для поиска и устранения логично менять все что угодно лишь бы ошибки лучше проявлялись, отлавливались и устранялись.
Само собой, бывают и "неудачные" случаи, типа тех, что вы описываете, ну да - не можешь искусственно создать условия проявления бага в удобном тебе окружении - дебаж ничего не меняя (хоть просто исходники читай до просветления), но почему даже попробовать что-то временно поменять (для сбора информации о проблеме, в попытках ухудшить условия так чтоб баг "попер", в попытках локализовать примерное место в коде и т. д.) считают "странной идеей" мне не понять.>> Любые изменения, которые могут дать информацию о проблеме - оправданы
> Когда как, когда как. Если при изменениях баг вообще ныкается под ковер - это вообще свинство форменное :).Значит эти изменения не дали много информации - самое время сделать другие, которые могут что-то и дать. И уж точно не прекратить все трогать.
> Потому что после включения отладочных фич баг может пойматься. А может и не пойматься. Прецеденты были.
Не поймался - лови дальше, просто изменения, которые придется сделать чтоб поймать, более существенны чем просто включить "отладочные фичи". То есть выходит-то наоборот - в этом случае надо делать еще больше временных изменений чтоб поймать.
> Ну да, прикольно же юзать не фикшеную версию.А вы юзайте старые пофикшеные версии ;)
> А вы юзайте старые пофикшеные версии ;)Necromancy is a forbidden art. Хотя некоторым может и нравится получать сплойтами по древностям которые давно починили в апстриме.
Нормальные люди фиксы бекпортят. А фичи с багами оставляют в новых версиях.
> Нормальные люди фиксы бекпортят. А фичи с багами оставляют в новых версиях.Ага, и фиксы к старым багам там же оставляют. Спасибо, я уже видел как в 3.2...3.9 ядре работает usb 3.0 стек. Сам такую стабильноту юзай, ибо 3.10RC - в пять раз стабильнее.
И часто вам нужен USB-3 стек на продакшне? Я ж вроде не о домашних машинках говорил.Но вообще я больше не версии имел в виду, а продукты - грубо говоря, вот пожил Nginx лет... пять, что ли - вот тогда его и стали разумные люди всерьёз воспринимать. Когда все шишки уже были набиты в некритичных приложениях. Вон скале сколько лет? А воспринимать всерьез ее только начинают понемногу, и это правильно.
> И часто вам нужен USB-3 стек на продакшне? Я ж вроде не о домашних машинках говорил.А чем мой домашний комп хуже продакшна, собственно? И почему там допустима какая-то нестабильность? Невозможность прочитать usb3 носитель может мне довольно дорого обойтись.
> Но вообще я больше не версии имел в виду, а продукты -
Но вообще, попытки быть святее папы римского^W^W апстрима - имеют свойства заканчиваться "как в дебиане". Если уж апстрим начал гнать лажу и в новом коде багов больше чем в старом - вы очень напрасно таким софтом пользуетесь, пожалуй. Ибо он скатился в УГ.
> грубо говоря, вот пожил Nginx лет... пять, что ли - вот
> тогда его и стали разумные люди всерьёз воспринимать.Ну знаете, рамблер им пользовался весьма давно. А невкусные баги находят и сейчас. Как бы процесс разработки софта в общем случае - непрерывная активность. И с течением времени обычно должен быть прогресс а не наоборот. Поэтому свежие версии в нормальной ситуации имеют все шансы быть качественнее старых. Иначе люди не умеют делать работу над ошибками и пользоваться таким софтом - себе дороже получается.
> Когда все шишки уже были набиты в некритичных приложениях. Вон скале сколько лет? А
> воспринимать всерьез ее только начинают понемногу, и это правильно.Как ни странно - это никак не оправдывает юзеэ древних версий.
> Нормальные люди фиксы бекпортят. А фичи с багами оставляют в новых версиях.позвольте - читали последную новость о локальный DoS для RedHat? так это был бэкпорт фикса..
Вот так редхат пофиксил другую уязвимость, получив еще один локальный DoS.
Ну а, бывает. Будете спорить, что с новыми фичами багов прилетает больше, чем в таких случаях?
> Ну а, бывает. Будете спорить, что с новыми фичами багов прилетает больше,
> чем в таких случаях?Вот это кстати еще большой вопрос где и каких багов больше. При бэкпортах обычно не чинят все что не касается секурити. Т.к. объем портирования взлетает до небес.
Как минимум в дебиане - обычно чинят. Хотя, конечно, не исключен вариант чего-то, что будет пропущено по причине монструозности.
> Как минимум в дебиане - обычно чинят.Напротив, обычно они чинят только секурити по моим наблюдениям. Остальное им в общем случае до пи...
Доходило до того что народу отгружали например Nexuiz старой версии. Бессмысленно и беспощадно. При том что почти все админы серверов перешли на новую версию серверов и их протокол просто не совместим с тем что отгружали в дебиане. Спору нет, можно пережить и без nexuiz. Но вот отгружать заведомо поломанную и неработоспособную программу - где логика, где разум?
Или вон у древнего 3.2 кернеля - работа с более-менее свежим оборудованием как-то не фонтан. Но никто не будет это силно перенапиливать из 3.10 какого-нибудь в 3.2. Даже у богатых парней из редхата на это хватает ресурсов в весьма лимитированном объеме.
> А потом некоторые удивляются, почему для продакшна лучше брать "древности", которым не
> один год. Вот поэтому.поправочка для продакшна лучше не брать код написанный в бессознательном состоянии или under influence. а старый он или новый значения не имеет.
хотя да, древние патриархи все же кунфу владели лучше en mass.
> en massen masse тогда уж...
Н-да, честные люди не пытались бы отмазаться. Случайна ли ошибка? Стиль по-своему изящный, напоминает ту старую попытку протащить в ядро Linux дырку на "сравнивании" через сломанный kernel cvs с экспортом из bitkeeper.
> Стиль по-своему изящный, напоминает ту старую попытку протащить в ядро LinuxНа самом деле тому кто хоть немного разбирается в криптографии сразу понятно что попытка сделать в вебе чатик путем загрузки клиенту JS - это популизм и пудрение мозгов.
Ну вот например: а что помешает атакующему MITM слегонца заменить JS с шифрованием на свой собственный? Врядли юзеры будут перечитывать скрипты от и до. Даже в случае HTTPS сертификат может выписывать толпа удостоверяющих центров, надежность половины из которых весьма под сомнением (comodohacker подтверждает).
При таком раскладе секурность этого супер-пупер-чатика заведомо декоративная и надеяться на то что это выдержит атаку сколь-нибудь подготовленного злодея - шибко оптимистично. Поэтому заведомо понятно что граждане просто пиарились.
>> en mass
> en masse тогда уж...tushe!
> Н-да, честные люди не пытались бы отмазаться. Случайна ли ошибка?
> Стиль по-своему изящный, напоминает ту старую попытку протащить в ядро Linux
> дырку на "сравнивании" через сломанный kernel cvs с экспортом из bitkeeper."Любопытную версию выдвинул Сысой Свиридович Сидоров для объяснения тайны загадочной улыбки Моны Лизы. Не исключено, считает исследователь, что она просто была дурой."
> tushe!touché!
out!
> tushe!Douche. Douchebag :)
> Случайна ли ошибка?Дадада, всюду враги.
Бритва Хенлона.
Почему всюду?
В конкретных местах в общем то.
К черту бритвы. Элементарная логика в виде "вебня + опенсорс" = "граждане решили попиариться" и хрен оспоришь. Поскольку ... кто угодно может подменить сайт или скрипт и даже HTTPS зарекомендовал себя весьма декоративным из-за кучи ауторитей.
Речь о том, что старый код больше гоняли и больше смотрели. А в каких его там состояниях писали (в том числе какие-то конкретные куски) - этого уже не узнать.
С другой стороны, редкий програмер портит свою программу с течением времени. Зато очень многие свои программы с течением времени улучшают. Если это не так - вы, вероятно, допустили ошибку в выборе программы.
"все сообщения отправленные с 17 октября 2011 года по 15 июня 2013 года подвержены указанной уязвимости"
Вроде тоже не один год, но уязвимость есть.
Уж лучше новые версии в который добавляют исправления. И да бекпортирование на старую версию не лучше подход так как надо тестировать правильно ли все было бекпортировано и не всплыли ли при этом регрессиии так что принципиальной разници от новой версии нет.
это же голимая вебня, наверняка там таких граблей дохерища. В нормальной среде не понадобилось бы заставлять пользователя "повышать" энтропию хотя бы.
> это же голимая вебня, наверняка там таких граблей дохерища.Да, и первая из них - вы никак не сможете проверить что вам в браузер вгрузился именно правильный скрипт, только он и никак не пропатченный. Забавная такая фигня. То-есть если некто посторонний вам отгрузит нечто с тем же внешним видом - вы это никак не заметите особо. Вероятность того что вы при каждом использовании чатика будете весь его код анализировать - около нуля.
> А потом некоторые удивляются, почему для продакшна лучше брать "древности", которым не один год. Вот поэтому.Чтобы там _гарантированно_ встретился такой нежданчик?
Чтобы туда были гарантированно сбекпортированы фиксы к нежданчикам за последние N лет, чтобы был накоплен опыт применения - "вот эта опция полезная, вот эта - нужна в таких-то обстоятельствах, а вот это врубать не надо никогда", чтобы был наработан опыт рекавери из разных неприятных ситуаций, выросли спецы, которые хорошо знают данную технологию в достаточном количестве...
> Чтобы туда были гарантированно сбекпортированы фиксы к нежданчикам за последние N лет,Сама фраза "бэкпортирование" означает что сначала это было починено где-то еще, а потом уже через сколько-то там времени - запортировано куда-то еще. И вот в этот период врмени хаксоры уже могли знать о дырке (сорц апстрима они читать могут, да?) а вот у вас фикса еще не было (програмеры рыли землю и бэкпортили в это время). Интересная логика в общем.
Ну так юзайте дистрибутивы, где секьюрити тим не такой тормозной. Дебиан вполне шустр обычно, к примеру.
> Ну так юзайте дистрибутивы, где секьюрити тим не такой тормозной. Дебиан вполне
> шустр обычно, к примеру.И тем не менее, сначала фикс делается апстримом и только потом секурити тим его портирует. Спору нет - в целом ответственные граждане. Но понимать где причина а где следствие - стоит.
> Чтобы туда были гарантированно сбекпортированы фиксы к нежданчикам за последние N летЧтобы фиксы были сбекпортированы, их сначала нужно закоммитить в актуальную версию.
Ясное дело. Причем бекпорт секьюрити фикса может быть довольно быстрым, а вот с новой версией получается чудесный выбор - либо ждать её релиза (хрен знает сколько, мало ли сколько фич туда разработчик напихать еще не успел) либо использовать сборки из транка, что точно чревато массой багов.
Как показывает практика, бекпорты умеют вызывать баги не хуже транка.
> Как показывает практика, бекпорты умеют вызывать баги не хуже транка.А чего б им? Что так малопротестированное изменениие в коде, что этак.
> А потом некоторые удивляются, почему для продакшна лучше брать "древности", которым не один год. Вот поэтому.Точно. Вот нафига BIND юзают самый свежий? Известно всем гуру что версия на пару мажорных версий старее - самая безопасная.
И лучше фряхи 3.х ничего нет
// Generates a random string of length `size` characters.
// If `alpha = 1`, random string will contain alpha characters, and so on.
// If 'hex = 1', all other settings are overridden.
Cryptocat.randomString = function(size, alpha, uppercase, numeric, hex) {
var keyspace = ''
var result = ''
if (hex) { keyspace = '0123456789abcdef' }
else {
if (alpha) { keyspace += 'abcdefghijklmnopqrstuvwxyz' }
if (uppercase) { keyspace += 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' }
if (numeric) { keyspace += '0123456789' }
}
for (var i = 0; i !== size; i++) {
result += keyspace[Math.floor(Cryptocat.random()*keyspace.length)]
}
return result
}
-// Generate private key (32 byte random number)
-// Represented in decimal
+// Generate private key (64 random bytes)
multiParty.genPrivateKey = function() {
var rand = Cryptocat.randomString(64, 0, 0, 1, 0)http://catmacros.files.wordpress.com/2009/06/its_beautiful.jpg
начиная от параметров randomString, и заканчивая каментами в коде.
хосподи, а я тут на некоторых своих коллег наезжаю по мелочам. пойду извинюсь.
look ma no hands! and no brain too…
> хосподи, а я тут на некоторых своих коллег наезжаю по мелочам. пойду извинюсь.А чё не так, давай подробнее?!
Поясни плз, что не так? Я вижу лишь несоответствие комментария к функции тому, что делает эта функция на практике (вместо заявленных 64 случайных байт, она выдаёт 64 случайных цифры). Но я не программист-профи, и вероятно чего-то не понимаю. А любопытство распирает: что здесь не так?Да, и это не пустое любопытство. У меня есть нечто похожее для генерации паролей. Может мой код тоже косячен?
А! Может дело в Math.floor(Cryptocat.random()*keyspace.length)? Максимальное значение Cryptocat.random(), надо полагать равно единице, и ежели единица выпадет, то после всех округлений получится индекс выходящий за границы массива. Так? Но может быть единица не может выпасть?
> Поясни плз, что не так?DNA авторов. это — говнокод. с первой и до последней строчки говнокод. начиная уже с сигнатуры функции говнокод.
>> Поясни плз, что не так?
> DNA авторов. это — говнокод. с первой и до последней строчки говнокод.
> начиная уже с сигнатуры функции говнокод.А, понятно. И как только я сам не догадался.
> А, понятно. И как только я сам не догадался.потому что ты тоже говнокодер. возможно, от недостатка опыта. а возможно — от недостатка мозга. об этом я в данном обсуждении судить не берусь (если, конечно, ты не продемонстрируешь доказательства второго варианта добровольно).
p.s. благодарю. в удалённом посте было отличное доказательство утверждения номер два из #88.
> DNA авторов. это — гoвнокод. с первой и до последней строчки гoвнокод.
> начиная уже с сигнатуры функции гoвнокод.Если это гoвнокод - то покажи, как правильно.
Если сам не гoвнокодер, конечно (в этом случае пойдут отмазы "я тут работать не нанимался, гони бабки, тогда выдам свой мега-убер-код").
командовать одноклассниками будешь, если позволят. свободен.
Поэтому юзайте жаббер внутри ЕСП/ГРЕ и будет вам щястье
> Поэтому юзайте жаббер внутри ЕСП/ГРЕ и будет вам щястьеА потом обнаружьте что сервант расшифровывает сообщения и по этому поводу может спокойно их логгировать и прочая если захочет.
Если уж интересует приватность переписки в IM, нечто типа OTR в руки имхо.
Не боись, анониный брат! Факты передачи OTR и GPG сообщений через публичные сервисы тоже записываются и отправляются куда надо. А для серьезных разговоров есть серьезные системы связи (дупло в дереве в глухом лесу, например).
> Не боись, анониный брат! Факты передачи OTR и GPG сообщений через публичные
> сервисы тоже записываются и отправляются куда надо.Записывать потенциально может кто угодно и что угодно. Поэтому с точки зрения криптографии стоит рассматривать пессимистичный вариант. И в этом плане OTR достаточно интересная штука. Особенно в свете реализации perfect forward secrecy. После завершения сессии ключ которым можно расшифровать просто перестает существовать.
> А для серьезных разговоров есть серьезные системы связи
> (дупло в дереве в глухом лесу, например).А вражеский агент на хвосте, конечно же, не рассматривается? :).
> Не боись, анониный брат! Факты передачи OTR и GPG сообщений через публичные
> сервисы тоже записываются и отправляются куда надо.на здоровье. штука не в том, чтобы «не услышали», а в том, чтобы не поняли, даже если и услышат.
OTR - очень сомнительно. Уж лучше GPG, но будьте готовы, что лет через 10-15 все ваши сообщения могут быть прочитаны.
И чем оно сомнительно?
> И чем оно сомнительно?видимо, тем, что «яничегонепонимаютам».
Раз тебе непонятно, то продолжай использовать этот чёрный ящик с, вроде бы, приятными штуками.
> Раз тебе непонятно, то продолжай использовать этот чёрный ящик с, вроде бы,
> приятными штуками.как и следовало ожидать, внятного ответа от тебя нет. а я уж думал, ты действительно нашёл там Страшные Дыры, хотел бежать цифропанков пугать: они столько лет старались зря…
> Раз тебе непонятно, то продолжай использовать этот чёрный ящик с, вроде бы,
> приятными штуками.Вообще-то есть описание протокола и исходники. Wtf is "черный ящик"?
>> Раз тебе непонятно, то продолжай использовать этот чёрный ящик с, вроде бы,
>> приятными штуками.
> Вообще-то есть описание протокола и исходники. Wtf is «черный ящик»?и статьи от авторов с описаниями алгоритмов и причин выбора оных. но оно альтернативно развитое, само на криптоанализ не способно, потому что в криптографии ничего не понимает, а «Известные Авторитеты», видишь ты, ничего об OTR не писали. вот оно и не может «мнения составить»: скопипастить-то неоткуда.
>> Раз тебе непонятно, то продолжай использовать этот чёрный ящик с, вроде бы,
>> приятными штуками.
> Вообще-то есть описание протокола и исходники. Wtf is "черный ящик"?Речь про использование "как чёрного ящика". Просто полагаясь на корректность протокола и реализации.
> Речь про использование "как чёрного ящика". Просто полагаясь на корректность протокола и реализации.Ну так он именно для такого использования и сделан. Он делает довольно мало допущений о свойствах протокола под ним и не требует от применяющего каких-то особых познаний в криптографии. То-есть, если интересно как оно внутри сделано - есть описальник, где все популярно расжевано, как что и почему. А если не интересно - можно просто дергать либу. Это же не OpenSSL где вы при должной дуроте сможете 40-битный ключ поюзать, который школьник шутя сломает на GPU за пару часов :)
Тем, что никакого полноценного криптоанализа не было проведено/представлено. Невозможно даже примерно оценить, чего можно ожидать от OTR, насколько оно надёжно и надёжно ли вообще.
Там используются вполне обычные алгоритмы, криптоанализ которых как ни странно был произведен. Просто они между собой так состыкованы что получается ряд интересных свойств у протокола и вообще.А у GPG своих known issues есть:
1) Компрометация ключа даже "опосля" позволяет расшифровать всю зашифрованную переписку. В OTR такая проблема не стоит: он на IM ориентирован и оперирует понятием сессии и сессионным ключом. Который безнадежно грохается из оперативы по окончании сессии. Далее шифрованный трафф расшифровке уже не подлежит.
2) В GPG можно достоверно установить что именно вот этот обладатель ключа послал это сообщение. И хотя содержимое сообщения не видно, сам факт предъявить вполне можно. В OTR у сообщений нет подписей или чего либо подобного. Поэтому научно доказать что сообщение послал именно этот индивид с этим ключом - вообще нельзя. Иногда такое свойство может быть полезным.3) В плане верификации собеседника оно чем-то похоже на gpg - тоже оперирует фингерпринтами ключей.
не вижу смысла метать бисер: оно не поймёт ни слова.
>не вижу смысла метать бисер: оно не поймёт ни слова.Не надо выпендриваться.
Это форум, на котором люди получают знания. И слава Богу.
Ваше "метать бисер" = давать знания.
Ваше "свиньи" (см. "оно") = пользователи форума.
---
Пусть так и будет. Аминь.
обучение основам криптографии — за деньги. ибо задача сложная, требует от обучаемого как минимум наличия рабочего мозга.
> не вижу смысла метать бисер: оно не поймёт ни слова.Мое дело попытаться. Дальше мозг или включается или нет.
Понятное дело, что известные алгоритмы. Но само сочетание толком не изучено. Где гарантии, что всё действительно всё хорошо, и что в ближайшем будущем не будут выявлены незаявленные разработчиками "возможности"? Полагаться на допущение - странная стратегия.Поэтому да, до тех пор, пока не проведено комплексного анализа, OTR выглядит для очень сомнительно.
Касательно GPG - всё верно, только ты перечислил "проблемы" которые существуют by design. Но, в отличие от ORT, OpenPGP изучено и предсказуемо. И это главный плюс.
Ещё раз, для PGP известна оценка стойкости "сверху"; а для OTR что? Я не хочу сказать, что "OTR - плохо", нет. Мне нравится OTR, мне нравятся его возможности, но я не вижу причин его применять только из-за этого.
> Понятное дело, что известные алгоритмы. Но само сочетание толком не изучено. Где
> гарантии, что всё действительно всё хорошо, и что в ближайшем будущем
> не будут выявлены незаявленные разработчиками "возможности"? Полагаться на допущение
> - странная стратегия.С таким же успехом продолб может всплыть и в любом ином протоколе. Из описания протокола и алгоритмов я не вижу каких-то особо очевидных косяков. А так - грабли и в GPG могут вылезти. А в pgp были даже запалены попытки бэкдоринга (внедрежа левых ключей которыми можно расшифровать копию сообщения) - с тех пор им пришлось сорс публиковать, на слово им уже никто не верит.
> Поэтому да, до тех пор, пока не проведено комплексного анализа, OTR выглядит
> для очень сомнительно.Все алгоритмы использованные там, придуманы не вчера. Похожие связки применяются не первый день. Почему сделано так а не иначе - описано в мануальнике протокола. Теоретически там может всплыть косяк, но в целом протокол задизайнен с головой на плечах и пониманием проблематики. Поэтому вероятность этого IMHO не выше чем где-то еще. Это ж не популистская наколенная поделка на яваскрипте под веб, писаная лишь потому что "модно-стильно-молодежно + удобная тема для пиара".
> Касательно GPG - всё верно, только ты перечислил "проблемы" которые существуют by
> design. Но, в отличие от ORT, OpenPGP изучено и предсказуемо.Ну я рад что задокументировано, но это не отменяет того факта что подобные свойства могут быть нежелательны в ряде применений. Эти свойства могут заведомо ставить крест на некоторых применениях.
> И это главный плюс.
"Этот самолет не летает. Это документировано. Это его главный плюс". Как-то так? :)
> Ещё раз, для PGP известна оценка стойкости "сверху";
Это вообще не есть "оценка стойкости" - это всего лишь свойства реализации, вытекающие из принятых в дизайне решений по использованию связок алгоритмов. Это особенности дизайна. Они такие изначально задумывались. И частично даже преподносились как фича (можно проверить что собеседник - именно он, а не кто-то еще, даже пост-фактум).
В OTR это несколько хитрее: уверенность насчет собеседника есть лишь в момент сессии. После этого никаких методов проверить кто участвовал в сесии на основании шифрованного траффика - нет. Это тоже фича. Этот шифрованный мусор невозможно однозначно и доказуемо кому-то пришить. И ключи можно с чистой совестью отдать.
> а для OTR что?
Пока для него никто не нашел никакого крупного криминала, хотя он существует не первый год а алгоритмы примененные там - и подавно.
> Я не хочу сказать, что "OTR - плохо", нет. Мне нравится
> OTR, мне нравятся его возможности, но я не вижу причин его
> применять только из-за этого.Грубо говоря, OTR и GPG - совершенно разные по свойствам. По поводу чего их сравнивать как-то особо и не получится. Там где будет использоваться OTR, GPG может быть заведомо неприемлим по свойствам.
> А у GPG своих known issues есть:
> 1) Компрометация ключа даже "опосля" позволяет расшифровать всю зашифрованную переписку.
> В OTR такая проблема не стоит: он на IM ориентирован и
> оперирует понятием сессии и сессионным ключом. Который безнадежно грохается из оперативы
> по окончании сессии.Вопрос от непрофи:
А если эти сессионные ключи сохраняются в БД на сервере-передатчике (сейчас ведь нет проблем с экономией дискового пространства?)
> Вопрос от непрофи:
> А если эти сессионные ключи сохраняются в БД на сервере-передатчике (сейчас ведь
> нет проблем с экономией дискового пространства?)а откуда он их возьмёт-то? ты же не думаешь, что ключи просто так, открытым текстом передаются?
p.s. луркай Diffie–Hellman key exchange.
> OTR - очень сомнительно.У него есть ряд интересных свойств, которые GPG недоступны. В частности - продолб ключа не ведет к расшифровке предыдущих сообщений из шифрованного траффы. Так что при угрозе терморектального криптоанализа или судебного преследования вы можете с чистой совестью сдать все ключи. А то что ими траффик нельзя расшифровать - ну да, протоколец так работает. Извините, дескать :)
там ещё и deniability есть. тоже приятная штука.
> там ещё и deniability есть. тоже приятная штука.Угу. Особенно во всяких муд...цких юрисдициях где за отказ дать ключ могут посадить. А так сдал все ключи - и долбитесь с расшифровкой как хотите, товарищ майоры. Честный гражданин все выполнил, а остальное - не его проблемы уже :). Так что если гражданин не писал лог чатика на диск - товарища-майорам будет очень интересно выкусить на шифрованной копии траффика тот факт что она на этот момент времени вообще никак не расшифровывается и даже нет пруфа что то наверняка послал именно тот кто сдал ключи.
> сервант расшифровывает сообщения_своим_ жабером.
> _своим_ жабером.А переписываться потом самому с собой? Иначе для как минимум 1 участника сервак будет уже не "свой" :)
нет, с соратниками по конспирации.
> нет, с соратниками по конспирации.Для кого-то из них сервер будет уже не его, стало быть.
это не уязвимость а фича, фбр тут не причём
> это не уязвимость а фича, фбр тут не причёмВы путаете с OpenBSD.
Уууу, сколько теперь народу посодют...
... или наградят пАчЁтной грамотой :)
