[image]

Шифрование/криптография и политика

Перенос из темы «Финансовые последствия»
 
1 4 5 6 7 8 9 10
EE Татарин #17.04.2014 20:40  @GOGI#17.04.2014 20:28
+
-
edit
 

Татарин

координатор
★★★★★
Татарин>> Нет. Это тоже хороший, годный баг, но как пример он менее интересен
GOGI> То-то я смотрю, описание на heartbleed слабо похоже. А про какой тогда? А то сейчас в гугле про какую-то другую уязвимость хрен что найдешь, все последней забито.
GOGI> P.S.-вообще, удивлен, что Heartbleed на а-базе никто не обсудил.
Для меня она проходит под внутренним номером, и можно, наверное, посмотреть индексы CEV или еще кого внешнего, если не поленились добавить. Буду на работе - посмотрю, если не забуду, и если интересно. Суть баги я описал.

Обсуждать... а что именно? Админы в курсе. Остальным неинтересно. Я даже не очень понимаю, почему именно этому багу сделана такая реклама. :)
   
RU GOGI #17.04.2014 20:46  @Татарин#17.04.2014 20:40
+
-
edit
 
Татарин>Остальным неинтересно. Я даже не очень понимаю, почему именно этому багу сделана такая реклама. :)
Нихрена себе, не интересно. Крупнейшая уязвимость одной из важнейших технологий современного Интернета.
А вот думаю, представляете, если это действительно случайная ошибка и о ней АНБ не знало. Как они рвут сейчас на себе волосы, сожалея об упущенных возможностях, мегаваттах, соженных на расшифровку и прочее, когда многое можно было сделать очень просто.
   28.028.0
EE Татарин #17.04.2014 20:47  @Mishka#17.04.2014 20:17
+
+3
-
edit
 

Татарин

координатор
★★★★★
Татарин>> И я не то даже чтоб спец по безопасности. Я просто чуток посмотрел на некоторые вещи изнутри, которые обычный ИТшник не копает и не видит... и сейчас у меня совсем другой взгляд на "информационную безопасность" в современном мире.
Татарин>> В двух словах: её нет.
Mishka> это норма, т.к. людей, которые разбираются очень глубоко в системе и в теории на любом проекте очень мало — часто один человек. Проверять некому. А остальные доверяют.
Именно так. Особенно, когда дело касается какого-нить реально сложного компонента с ненулевой долей матанов. И никакой эксперт, пару дней втыкающий в код, не найдет умную закладку от человека, который этот код писал и с ним живет. Блин, да что там говорить, если багофикс собственного кода в сложных случаях и окружениях может недели занимать? Даже зная, что проблема точно есть, и зная примерно в каких условиях проявляется...
   
EE Татарин #17.04.2014 20:51  @GOGI#17.04.2014 20:46
+
+3
-
edit
 

Татарин

координатор
★★★★★
GOGI> Нихрена себе, не интересно. Крупнейшая уязвимость одной из важнейших технологий современного Интернета.
Гм... не хотел тебя разочаровывать... но попробуй как-нить подписаться на рассылки об уязвимостях... Твоя вера в Человечество необоснованно высока. :)
Не то чтоб это повседневное дело, но вполне себе одно из дли-инного ряда... :)

GOGI> А вот думаю, представляете, если это действительно случайная ошибка и о ней АНБ не знало. Как они рвут сейчас на себе волосы, сожалея об упущенных возможностях, мегаваттах, соженных на расшифровку и прочее, когда многое можно было сделать очень просто.
См. выше. Не думаю, чтоб у АНБ были такие проблемы. Это КРАЙНЕ маловероятно.
   

Nikita

аксакал

GOGI> А вот думаю, представляете, если это действительно случайная ошибка и о ней АНБ не знало.

Сильно навряд ли. Инсайдеры уже писали, что контора была в теме минимум два года. Каждый коммит в OpenSSL гарантированно мониторится.

GOGI> мегаваттах, соженных на расшифровку

Да какая там расшифровка :facepalm: Вы материалы Сноудена читали ? NSA внедрилась на всех уровнях всего. Им ничего не надо было расшифровывать. То что они провернули превосходит самые смелые и считавшиеся фантастическими ожидания.
   11.011.0
US Mishka #17.04.2014 21:08  @Татарин#17.04.2014 20:51
+
-
edit
 

Mishka

модератор
★★★
Татарин> См. выше. Не думаю, чтоб у АНБ были такие проблемы. Это КРАЙНЕ маловероятно.
Есть уже сведения, что инфу таким способом целенаправленно собирали. Вроде, даже по логам смотрели. Вроде, NSA среди сборщиков заметили намного раньше, чем неофициальная волна пошла.
   28.028.0
RU GOGI #17.04.2014 21:18  @Татарин#17.04.2014 20:51
+
-
edit
 
Татарин> Гм... не хотел тебя разочаровывать... но попробуй как-нить подписаться на рассылки об уязвимостях...
Вот эта уязвимость из тех, о которых узнают даже без подписки на спец. рассылки.

P.S.-про уязвимость с генерацией ключей я уже нашел.
   28.028.0

Nikita

аксакал

GOGI> То-то я смотрю, описание на heartbleed слабо похоже. А про какой тогда?

Похоже на старинный баг с косяком в генераторе псевдослучайных чисел. Статический анализатор - к вопросу о сертификации :D - выдавал ложные срабатывания на какие-то манипуляции внутри функции. Чувак решил "пофиксать". И закомментил две строчки кода. В итоге размер "случайности" упал до 15 бит :facepalm:
   11.011.0
RU Алдан-3 #17.04.2014 21:28  @Nikita#17.04.2014 21:18
+
-
edit
 

Алдан-3

аксакал
★★☆
Nikita> Чувак решил "пофиксать".

Люди которые лезут "фиксить" или не дай бог "оптимизировать" криптографию без письменного разрешения от минимум трёх специально обученных математиков должны гореть огне.
   28.028.0
EU Татарин #17.04.2014 21:38  @Nikita#17.04.2014 21:18
+
-
edit
 

Татарин

координатор
★★★★★
GOGI>> То-то я смотрю, описание на heartbleed слабо похоже. А про какой тогда?
Nikita> Похоже на старинный баг с косяком в генераторе псевдослучайных чисел.
Как-то так, да...

[pkg-openssl] Diff of /openssl/trunk/rand/md_rand.c

Parent Directory | Revision Log | Patch // anonscm.debian.org
 

Изменение - 2006-й год.

Обаг обнаружен и опубликован в 2008-м.

А вот исследование 2009-го года:

Интересные картинки, да? И это - для всем известного бага много-много месяцев после обнаружения.
   33.0.1750.15433.0.1750.154

U235

координатор
★★★★★
Mishka> PLM — это специально созданная или нет?

Я не владею английской терминологией. Что такое PLM? Это ПЛИС? Ну так ПЛИС после прошивки становится специализированной микросхемой с заданной разработчиком прошивки внутренней логической схемой, за это, быстродействие специализированных ИС в узкоспециальных приложениях, ПЛИС и любят. Так что аппаратура на специально прошитых под шифрование ПЛИС это естественно аппаратные шифраторы. Анкад, например, свои аппаратные шифраторы на ПЛИСах делает.
   8.08.0
Это сообщение редактировалось 18.04.2014 в 02:39
+
+1
-
edit
 

U235

координатор
★★★★★
Nikita> Похоже на старинный баг с косяком в генераторе псевдослучайных чисел. Статический анализатор - к вопросу о сертификации :D - выдавал ложные срабатывания на какие-то манипуляции внутри функции. Чувак решил "пофиксать". И закомментил две строчки кода. В итоге размер "случайности" упал до 15 бит :facepalm:

В ФСБ сертификацией занимаются люди, которые в криптографии кое что понимают. Кстати майкрософтовский системный генератор случайных чисел нашими регулирующими органами не считается криптографически стойким. Даже криптосредства низшего уровня стойкости должны иметь свой генератор случайных чисел, который сертифицируется на криптографическую стойкость вместе со всей программой, а на более высокие уровни стойкости сертифицируют только средства использующие сертифицированный аппаратный датчик случайных чисел
   8.08.0

U235

координатор
★★★★★
Mishka> Извини, ты не никакой не спец, ты просто любитель, если так объясняешь. :( Jitter вызывается кучей причин.

Я где-то говорил, что джитинг вызывается только шифратором? Его и прочее сетевое оборудование прекрасно вызывает, если, напрмиер, QoS и прочие средства обеспечения приоритета чувствительного к джитингу трафика не сконфигурированы как следует, ну или само оборудование в принципе кривое по этому параметру. Я говорил что шифратор может ухудшать эту характеристику канала, если у него время шифрования пакета плавает, что как раз характерно для программных шифраторов. Чтоб джиттинг в канале был в перделах нормы, все сетевое оборудование, через которое проходит трафик в том числе и шифровальное, должно быть качественным по этому параметру и правильно сконфигурировано. Будет хоть одно слабое звено - и все усилия прахом, ну или придется в конце канала джиттинг на задержку разменивать через антиджиттинговый буфер, а это дополнительная нагрузка на ресурсы оборудования, да и пользователи не очень любят, если ощутимая в разговоре задержка появляется.
   8.08.0
EE Татарин #18.04.2014 02:55  @U235#18.04.2014 02:18
+
+4
-
edit
 

Татарин

координатор
★★★★★
U235> В ФСБ сертификацией занимаются люди, которые в криптографии кое что понимают.
Ты не понял сути примера. Разработкой OpenSSL занимались люди, которые в криптографии кое-что понимали. Тем не менее, на обнаружение этой "ошибки" ушло два года. У людей, которые разрабатывали эту библиотеку и понимали её нутрёшки. Причём, строки верного кода были честно оставлены в коде и закоменчены с идиотским комментарием (благодаря которому ошибку и нашли).

Если ты просто вывалишь на абстрактного математика кучу сырцов и потрохов какой-нить криптобиблиотеки, да ещё и со вставочками, оптимизирующими под "ускоряющие наборы" векторных инструкций разных процов, то "финал немного предсказуем"(с).

U235> Даже криптосредства низшего уровня стойкости должны иметь свой генератор случайных чисел, который сертифицируется на криптографическую стойкость вместе со всей программой, а на более высокие уровни стойкости сертифицируют только средства использующие сертифицированный аппаратный датчик случайных чисел
Это всё фразы типа "не будем ссать себе в ботинок, нам станет сухо и тепло". :) Не то чтоб это правило неверно, не то чтоб кто-то с этим спорил... :) всё это очевидно, но при том недостаточно.
Всё это, конечно, соблюдается. И тем не менее, катастрофические дыры в криптосфте случаются и "случаются" сплошь и рядом.
   1414
RU U235 #18.04.2014 03:00  @Татарин#17.04.2014 18:38
+
-
edit
 

U235

координатор
★★★★★
Татарин> Я дам один простой пример из недавнего прошлого: в библиотеке OpenSSL (открытые исходники), которую использовало как бы не большинство разных продуктов шифрования (в том числе - очень платных) совсем недавно (случайно) была найдена и опубликована критическая уязвимость (не само шифрование, просто генерация ключей давала характерное распределение, зная которое, можно было радикально сократить объём вычислений при атаке).

Датчик случайных чисел - известная уязвимость. Я уже выше писал: ДСЧ обызательно проверяется криптографами сертифицирующих органов, причем не только по статистике выдаваемого результата, но и по алгоритмам. Разработчики КриптоКома как-то расказывали, как долго их гоняли ФСБшники по алгоритму их программного ДСЧ. И это только для первых ступеней стойкости. Более серьезные уровни сертифицируются только с обязательным условием использования аппаратного ДСЧ опять же прошедшего криптографическую сертификацию.

Эта самая OpenSSL, если б ее исходники попали в лапы ФСБ, сертификацию никогда бы не прошла с таким явным для криптографов багом.

Собственно сейчас уже появляются решения SSL на отечественных ГОСТах с сертифицированным ФСБ программным кодом, кстати по-моему как раз КриптоКом там сертифицированное ГОСТовское шифрование и писал.
   8.08.0
RU U235 #18.04.2014 03:16  @Татарин#18.04.2014 02:55
+
-
edit
 

U235

координатор
★★★★★
Татарин> Ты не понял сути примера. Разработкой OpenSSL занимались люди, которые в криптографии кое-что понимали.

Но их не проверяли сильные независимые спецы. Свою ошибку сложно найти. Особенно если ты по образованию именно разработчик, а не специалист по взлому шифров. Очень похоже на то, что ошибка находилась даже грамотным статистическим тестом который у разработчиков просто некому было провести. Такие вещи именно криптоаналитики должны проверять, а не сами разработчики.

Татарин> Если ты просто вывалишь на абстрактного математика кучу сырцов и потрохов какой-нить криптобиблиотеки, да ещё и со вставочками, оптимизирующими под "ускоряющие наборы" векторных инструкций разных процов, то "финал немного предсказуем"(с).

Ну все же в сертифицирующих органах есть свое разделение труда: одни выясняют алгоритмы работы софта по исходному коду, а другие - анализируют эти самые алгоритмы. Ну и статистические тестирования выдаваемой случайной последовательности профессиональные математики-криптоаналитики способны провести на уровне на несколько порядков выше, чем даже хорошо знакомые с криптографией разработчики. А такие исследования часто позволяют понять, что с ДСЧ что-то сильно не так даже если ошибка в его алгоритме еще не обнаружена.

Татарин> Всё это, конечно, соблюдается. И тем не менее, катастрофические дыры в криптосфте случаются и "случаются" сплошь и рядом.

Обычно они случаются, когда разработчики не контролируются сильной криптоаналитической службой. А так как ни одному коммерческому разработчику не по карману содержать такой штат профессиональных криптоаналитиков, то подобные катастрофы случаются регулярно. Поэтому, собственно, у нас по закону криптография и проходит сертификацию в нашей государственной криптографической службе. Это намного понижает вероятность, что катастрофический баг в криптографическом продукте дойдет до потребителей.
   8.08.0
+
+4
-
edit
 

Kernel3

аксакал

U235> Эта самая OpenSSL, если б ее исходники попали в лапы ФСБ, сертификацию никогда бы не прошла с таким явным для криптографов багом.

:facepalm: Чтоб ты знал: OpenSSL используется в куче софта, в т.ч. коммерческого, в т.ч. отечественного, в т.ч. сертифицированного ФСТЭК/ФСБ. Так что учи матчасть, в следующий раз появится шанс сойти за умного.

А вообще, твоя веря в великость и могучесть ФСБ, которое в сфере не только информационной безопасности, но и вообще технологий, без взаимодействия с гражданскими аутсорсерами может чуть больше, чем совсем ничего, является довольно интересным феноменом психологического или дальше психиатрического характера :-F Но с этим уже пусть профильные спецы разбираются.
   34.0.1847.11634.0.1847.116
+
+2
-
edit
 

Kernel3

аксакал

GOGI> А то сейчас в гугле про какую-то другую уязвимость хрен что найдешь, все последней забито.

Вот же: OpenSSL: OpenSSL vulnerabilities

Так много весёлого, но Heartbleed всё же, ИМХО, самый смешной. Переполнение буфера - это всегда смешно :)
   34.0.1847.11634.0.1847.116
+
+3
-
edit
 

Kernel3

аксакал

Kernel3> А вообще, твоя веря в великость и могучесть ФСБ, которое в сфере не только информационной безопасности, но и вообще технологий, без взаимодействия с гражданскими аутсорсерами может чуть больше, чем совсем ничего...

Кстати, как следствие, число этих самых аутсорсеров со временем увеличивается. Только я только в Москве знаю около десятка контор, занимающихся разработкой в интересах трёхбуквенных ведомств разных интересных штук как оборонительного, так и наступательного действия. Причём для двух из этих контор это основное направление деятельности.

Но до того же Stuxnet и всей веселухи, раскрытой Сноуденом, этим штукам довольно далеко.
Непрекращающаяся утечка мозгов не может не сказываться.
   34.0.1847.11634.0.1847.116
+
+1
-
edit
 

U235

координатор
★★★★★
Kernel3> :facepalm: Чтоб ты знал: OpenSSL используется в куче софта, в т.ч. коммерческого, в т.ч. отечественного, в т.ч. сертифицированного ФСТЭК/ФСБ.

Не сертифицирует ФСБ просто так стороннюю криптографию, тем более еще и не на наших алгоритмах. Хоть один продукт, в составе которого ФСБ сертифицировал криптостойкость OpenSSL и где использовался бы его дырявый ДСЧ, назови :)

Kernel3> А вообще, твоя веря в великость и могучесть ФСБ, которое в сфере не только информационной безопасности, но и вообще технологий, без взаимодействия с гражданскими аутсорсерами может чуть больше, чем совсем ничего, является довольно интересным феноменом психологического или дальше психиатрического характера

???
Где я такое говорил? ФСБ - и заказчик работ, и сертификатор. Криптоаналитики у них сильнейшие, поэтому ляпов за собой по этой части не оставляют. Сертификация у них много ступеней имеет. Та же Windows, например, сертифицирована только для обработки коммерческой секретной информации не слишком высокой степени секретности и только с отечественными криптомодулями. Обработка гостайны на Windows-платформах разрешена только при условии изоляции ПЭВМ от сетей общего пользования. Лучше спецов ФСБ не только у нас, но и в мире мало кто из разработчиков в вопросах криптографической и информационной безопкасности разбираются. Так что сертификация ими реально полезна, чтоб таких вот дыр, как в OpenSSL, не появлялось.

Сторонним конторам они тоже работы заказывают, только это обычно очень специфические разработчики, опять же вышедшие некогда из-под крыла 8го ГУ или созданные бывшими сотрудниками спецслужб, работавших в этой тематике
   28.028.0
+
+2
-
edit
 

Kernel3

аксакал

U235> Криптоаналитики у них сильнейшие, поэтому ляпов за собой по этой части не оставляют.

Это тебя обманули. Все отечественные криптоалгоритмы построены на методах, разработанных в США.
При этом тот же ГОСТ Р 34.11-2012 разработан парой из "Инфотекса" (гражданский аутсорсер, ага) взамен старого стандарта, оказавшегося - сюрприз! - дырявым. Где были твои сильные аналитики до, во время, и после? С чего ты вообще взял, что они когда-либо у нас были? Именно уровня американских? Где на отечественного Рона Ривеста посмотреть можно?
   34.0.1847.11634.0.1847.116
+
+3
-
edit
 

Kernel3

аксакал

U235> Хоть один продукт, в составе которого ФСБ сертифицировал криптостойкость OpenSSL и где использовался бы его дырявый ДСЧ, назови :)

А зачем тебе именно криптостойкость? Сертификат "Классификация по уровню контроля отсутствия недекларированных возможностей" 4-го уровня тебя не устроит? Для проекта, включающего исходники OpenSSL? Если нет, то почему? :)
   34.0.1847.11634.0.1847.116
+
+1
-
edit
 

U235

координатор
★★★★★
Kernel3> При этом тот же ГОСТ Р 34.11-2012 разработан парой из "Инфотекса" (гражданский аутсорсер, ага) взамен старого стандарта, оказавшегося - сюрприз! - дырявым. Где были твои сильные аналитики до, во время, и после?

Чтоб, блин, его современники были хоть столько же "дырявыми"! :lol:

Опрубликованная в 92ом хэш-функция MD5 уже сломана практически. Китайцы опубликовали практически применимый алгоритм нахождения коллизий. Трудоемкость нахождения коллизий SHA-1, опубликованного в 1995ом, при применении ныне найденных атак составляет 263 операций. Найденные же атаки на ГОСТ 34.11-94 позволяют сократить трудоемкость взлома лишь до 2105, что в 4 триллиона раз больше нынешней стойкости SHA-1, атака на которую тоже пока что практически не реализуема при нынешних вычислительных мощностях.

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

Ну и разработать криптоалгоритм - это даже не пол-дела. Оценить его стойкость - дело намного более сложное. Разработка и оценка стойкости хэше-функции велась в тесном взаимодействии с Центром защиты информации и специальной связи ФСБ России и он является соразработчиком этого алгоритма наряду с ИнфоТексом.

Kernel3> С чего ты вообще взял, что они когда-либо у нас были? Именно уровня американских? Где на отечественного Рона Ривеста посмотреть можно?

В большом здании в Олимпийской деревне на некоторых посмотреть можно, только их фамилии тебе ничего не скажут: они редко печатаются или не печатаются вовсе.
   28.028.0
Это сообщение редактировалось 18.04.2014 в 14:21

U235

координатор
★★★★★
Kernel3> А зачем тебе именно криптостойкость? Сертификат "Классификация по уровню контроля отсутствия недекларированных возможностей" 4-го уровня тебя не устроит? Для проекта, включающего исходники OpenSSL? Если нет, то почему? :)

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

Описаная вами выше ошибка генератора случайных числе в модуле реализации хэш-функции MD5 - это уязвимость криптографии. А MD5 - он и без ошибки в реализации уже сплошная уязвимость и несертифицируем в России в приниципе.
   28.028.0
+
+2
-
edit
 

U235

координатор
★★★★★
Kernel3> Это тебя обманули. Все отечественные криптоалгоритмы построены на методах, разработанных в США.

Это на каких таких методах разработанных в США построен ГОСТ 28147-89? :)
И ты прям настолько крут, что знаешь все отечественные криптоалгоритмы, которые в большинстве своем СС и ОВ? :D Ты знаешь всего лишь один симметричный блочный шифр, причем вряд-ли лучший и самый свежий из разработанных отечественной криптографической службой, два несимметричных криптоалгоритма, и две хэш-функции. Все. И по этому мизеру ты берешь на себя смелость о таких вещах судить?
   28.028.0
1 4 5 6 7 8 9 10

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru