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

Nikita> Идём на третий круг. Как Вы собрались определять, что должен делать код, а что нет ?

По стандарту языка. Он однозначно определяет, что делает код.

U235> По стандарту языка.

Четвёртый круг. Стандарт языка это большая толстая книга с мелким шрифтом. Как Вы собрались с помощью книги определять что (не)должен делать код ? В голове его прокручивать ?

U235> Он однозначно определяет, что делает код.

Опять Вы сели в лужу. Всё ровно наоборот. Стандарты C\C++ массу вещей специально определяют неоднозначным образом. Дабы не вводить зависимость от конкретной платформы и не ограничивать реализации стандарта в оптимизациях.

Nikita> Задаче сделать библиотеку для работы с бинарными файлами Microsoft Office во всей полноте их форматов. Не сам Office сделать. Только читалку\писалку файлов.

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

Nikita> Вот именно. Их задача, в Вашем изложении, гораздо сложнее. Им нужны корректные, полные, соответствующие стандарту компиляторы, и при этом ещё и совместимые со всем промежуточным бинарным стеком инструментария Microsoft.

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

Nikita> Четвёртый круг. Стандарт языка это большая толстая книга с мелким шрифтом. Как Вы собрались с помощью книги определять что (не)должен делать код ? В голове его прокручивать ?

Для начала да. Проверить компилятор на все более усложняющихся примерах. Потом компилировать боевой код.

Nikita> Опять Вы сели в лужу. Всё ровно наоборот. Стандарты C\C++ массу вещей специально определяют неоднозначным образом. Дабы не вводить зависимость от конкретной платформы и не ограничивать реализации стандарта в оптимизациях.

Мы говорим не о стандартах C++ и прочих языков вообще, а о стандартах конкретной реализаций языков программирования на которых написан код Windows. Насколько я понимаю, это Microsoft Visual С++ и Microsoft Visual Basic

U235> Ты либо не в теме вопроса, либо умышленно вводишь людей в заблуждение.

Я приветствую Вашу самокритику. Да.

U235> OpenOffice спокойно читает файлы MsOffice.

Читает. Только вот мало что понимает из прочитанного. Ну в точности как Вы

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

Вы нагло врёте. Никаких ограничений такого толка нет. Microsoft приняла соответствующие обязательства. Под давлением антимонопольного расследования Еврокомиссии, разумеется

U235> Вполне решаемая задача

Конечно же решаемая. Только вот чудес не бывает. Затраты на такой подвиг будут как минимум сопоставимы с затратами Microsoft на оригинал.

U235> при открытии Майкрософтом своих форматов и стандартов, как показывает пример того же OpenOffice.

См. выше. OpenOffice и близко не стоит с Microsoft Office.

U235> Не только в Майкрософте умеют программировать и какими-то исключительными ноу-хау они там не обладают

Обладают. Многие вещи, которые способна сделать Microsoft, во всём мире смогут осилить ещё только от силы пара-тройка компаний. И то, если бросят заниматься всеми своими текущими делами.

U235> Для начала да. Проверить компилятор на все более усложняющихся примерах.

Замечательно. Едем дальше. Я написал компилятор, который миллион компиляций 2*2 превращает в 4, а в ходе миллион первой в 5. Как Вы собрались проверять такое ?

U235> Потом компилировать боевой код.

Пошли на пятый круг. Как Вы собрались сравнивать результаты работы "боевого" кода полученного Вашим компилятором и компилятором Microsoft ? А сотен мегабайт "боевого" кода ?

U235> Мы говорим не о стандартах C++ и прочих языков вообще, а о стандартах конкретной реализаций языков программирования на которых написан код Windows.

Ещё смешней. "Стандартом конкретной реализации" является собственно сама эта конкретная реализация.

U235> Насколько я понимаю, это Microsoft Visual С++ и Microsoft Visual Basic

"Я плакаль" © не мой

Nikita> Замечательно. Едем дальше. Я написал компилятор, который миллион компиляций 2*2 превращает в 4, а в ходе миллион первой в 5. Как Вы собрались проверять такое ?

Я ж сказал: написать свой компилятор, который не имеет такой функции. И не пользоваться чужими, либо пользоваться ими после проверки их исходных кодов.

Nikita> Пошли на пятый круг. Как Вы собрались сравнивать результаты работы "боевого" кода полученного Вашим компилятором и компилятором Microsoft ? А сотен мегабайт "боевого" кода ?

Не надо сравнивать. Надо написать свой компилятор, проверить, что он соответствует стандартам языка открытого кода, скомпилировать им программу и пользоваться ей.

Nikita> Ещё смешней. "Стандартом конкретной реализации" является собственно сама эта конкретная реализация.

Стандартом реализации является опубликованная документация по этой реализации. Описания всех функций и правил языка, для своих средств разработки Майкрософт опубликовал.

Nikita> "Я плакаль" © не мой

А на чем по-твоему написан Windows?

U235> Я ж сказал: написать свой компилятор, который не имеет такой функции.

А это и не функция. Это просто ошибка

U235> И не пользоваться чужими, либо пользоваться ими после проверки их исходных кодов.

Очередной круг. Как Вы собрались проверять исходные коды ?

U235> Не надо сравнивать. Надо написать свой компилятор, проверить, что он соответствует стандартам языка открытого кода, скомпилировать им программу и пользоваться ей.

Чего-чего ? Вы хотите сказать, что версии Windows используемые в государственных органах РФ скомпилированы каким-то левым ФСБшным компилятором ?

*Вы должны отобрать никнейм у Bredonosec. Он потерял право его носить

U235> Стандартом реализации является опубликованная документация по этой реализации.

Сия документация описывает в основном только внешнее поведение. Внутреннее взаимодействие с ОС, например, в ней почти не рассматривается. А это ключевой момент.

U235> А на чем по-твоему написан Windows?

Да уж не на Visual Basic

U235> Насколько я понимаю, это Microsoft Visual С++ и Microsoft Visual Basic
А на чём написан Microsoft Visual C++?

U235> Для начала да. Проверить компилятор на все более усложняющихся примерах. Потом компилировать боевой код.
Сори, но ты в топике ерунду городишь. Никита прав, ты - нет.

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

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

Проверка исходников винды (не формальная, настоящая ) на безопасность - задача запредельной сложности, по трудоёмкости на порядки (десятичные) превосходящая, собссно, написание с нуля своей безопасной ОС со сравнимой функциональностью.
И. Нет и не может быть никаких сомнений, что винда содержит ненаходимые и неустранимые за любое разумное время преднамеренные закладки.

Я дам один простой пример из недавнего прошлого: в библиотеке OpenSSL (открытые исходники), которую использовало как бы не большинство разных продуктов шифрования (в том числе - очень платных) совсем недавно (случайно) была найдена и опубликована критическая уязвимость (не само шифрование, просто генерация ключей давала характерное распределение, зная которое, можно было радикально сократить объём вычислений при атаке). Весь софт, использующий OpenSSL (подчёркиваю настоящее время), - по факту бесполезен, все данные, защищенные этим софтом - доступны злоумышленнику.
Так вот: чейндж-лист какбэ намекает, что уязвимость была внесена намеренно. Есть больше 146% гарантии, что факт наличия этой дыры был известен кому-надо (и нет, это не ФСБ) задолго до, и человек, сделавший внешне-верные изменения с закладкой работал на кого-надо.
Страусов в наше время пугать не принято, проблема стала "широко известной в узких кругах", основная масса пользователей об таких вещах не слышит. Но если прикинуть, количество поаффекченых софта, машин, устройств, пользователей и данных, то это катастрофа безопасности планетарного масштаба, Сноуден отдыхает. И это лишь один мелкий эпизод, сложно представить себе уровень свободы людей, которые имеют в загашнике хотя бы пару сотен (а то и тысяч) таких "зеро дэй" закладок.
Есть ВСЕ основания полагать, что подобная работа велась и ведётся системно на постоянной основе не только с конкретной OpenSSL, а со всем критичным софтом. И даже совсем некритичным.

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

И, кстати, пример с OpenSSL я привёл с умыслом (не только потому, что у меня по поводу винды есть NDA). Это намёк на то, что подход "у меня Линукс, я в домике" - не работает. Не работал. Не будет работать. И работать не может.
Системы с открытыми для тебя исходниками - точно так же (если не более) уязвимы для системной работы правильных людей. Просто в случае с виндой это американские кто-надо, а в случае с открытыми исходниками ты даже не знаешь, кто.

Это одна из причин (многих), по которой движение "перейдём на опен-сорс" в европейских правительствах как-то слегка заглохло. Им быстро объяснили, что с виндой за ними удобно шпионить американцам, а с Линуксом... удобно и американцам, и китайцам, и ну, как уж выйдет. И взятки гладки.

И я не то даже чтоб спец по безопасности. Я просто чуток посмотрел на некоторые вещи изнутри, которые обычный ИТшник не копает и не видит... и сейчас у меня совсем другой взгляд на "информационную безопасность" в современном мире.
В двух словах: её нет.

U235> Не надо сравнивать. Надо написать свой компилятор, проверить, что он соответствует стандартам языка открытого кода, скомпилировать им программу и пользоваться ей.
...угу. Сделать свой набор компиляторов "по стандартам" , построить на нём билд-систему (замечу, оригинал билд-системы МС предоставлять был не обязан) и собрать винду по исходникам. В рамках работ по сертификации, да.
Ты не представляешь себе объём этой работы.

А главное - не понимаешь, что даже это бесполезно.

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

U235> Не будет работать только в одном случае: если компилятор не соответствует заявленному стандарту языка. А это уже залет.
Нет. Есть много, что лежит за пределами просто программы написанной на языке. Я тебе могу дать исходники программки без makefile (или imakefile или что там используюется) и посмотрю, сколько времени займёт у тебя займёт откомпилировать программу. В случае МелкоМягкого Никита прав — надо всю среду сборки. А вот её давать не подписывались.

U235> Шифрование ухудшает эту характеристику, если шифратор хреновый. Еще раз и по буквам, ибо устал объяснять одно и то же: любое шифрование создает задержку передачи пакета, т.к. на его преобразование уходит какое-то время. Если эта задержка является величиной переменной, то шифратор вносит джитинг в канал связи, в котором он стоит.
Извини, ты не никакой не спец, ты просто любитель, если так объясняешь. Jitter вызывается кучей причин. Это интегральная характеристика и к шифрованию он имеет не просто отдалённое, а очень отдалённое отношение, только как характеристика канала.

U235> А тут то в чем проблема? Ровно так же: есть стандарт языка - значит можно написать компоновщик и при правильно написаном исходнике все должно собираться и работать. Если у Майкрософта по стандарту языка написано одно, а реально код их средствами собирается по-другому, то просто не сертифицируют его продукцию, и все: скомпилированный код не соответствует исходному тексту.
Стандарт языка не определяет всю семантику. Стандарты языка очень сложные логические системы и вполне содержат противоречия. Стандарты языка оставляют кучу вещей на усмотрение написателя компилятора. Сборка кода покрывается в очень небольшом количестве компиляторов и уж явно не в С,С++ на которых в большинстве написана Винда. Есть ещё миллион маленьких "но". Но с этим надо работать, а не читать книжки "Интерет для идиотов".

U235> Опять же ровно то, что я и говорил. Программный шифратор - это программа работающая на не созданной специально для криптографических задач вычислительной машине.
PLM — это специально созданная или нет?

U235> Код исполняет то, что должен согласно написанной программе, и не исполняет того, что не должен.
Это и называется ППЦ.

Татарин> Проблема верификации кода - это огромная, нерешённая проблема даже при очень ограниченом коде очень небольшой системе, полных исходных кодах компилятора, своей доверенной платформе и т.д.

Я сейчас только одним глазом поглядываю на современные работы. Эта задача до сих пор считается (и не предвидется её переклассификации) NP полной.

Татарин> И я не то даже чтоб спец по безопасности. Я просто чуток посмотрел на некоторые вещи изнутри, которые обычный ИТшник не копает и не видит... и сейчас у меня совсем другой взгляд на "информационную безопасность" в современном мире.
Татарин> В двух словах: её нет.
Во, ещё один прозрел. Если вспомнить давние споры на Базе про писательство вирусов, преимущества Open Source и прочего, то можно найти, как я рассказывал, что мы обсуждали в команде ради хохмы возможности писания специальных компиляторов со всторенными механизмами распространения вирусов (ага, писали компилятор с Алгола 68) и специальной "генетической" составляющей для изменения кода с изменением сигнатуры. Оптимизаторный проход просто идеально подходит для этого. Ну и говорил я, что специальные закладки, подобные той, что случились в OpenSSL — это норма, т.к. людей, которые разбираются очень глубоко в системе и в теории на любом проекте очень мало — часто один человек. Проверять некому. А остальные доверяют.

Татарин>> Я дам один простой пример из недавнего прошлого: в библиотеке OpenSSL (открытые исходники), которую использовало как бы не большинство разных продуктовшифрования (в том числе - очень платных) совсем недавно (случайно) была найдена и опубликована критическая уязвимость (не само шифрование, просто генерация ключей давала характерное распределение, зная которое, можно было радикально сократить объём вычислений при атаке)
GOGI> Это ты сейчас про Heartbleed говорил?!!
Нет. Это тоже хороший, годный баг, но как пример он менее интересен: слишком известен и для использования требует соответствующего окружения, НЯП; неуниверсален. Ну и "слишком мощный", слишком простой для закладки.

Татарин> А главное - не понимаешь, что даже это бесполезно.
Ну, тут очень хорошая иллюстрация нонче есть — OpenSSL — компилировалась разными компиляторами, соотвествовала стандартам С/С++, "читалась" многими людьми, ещё и делала именно то, на что была расчитана.

GOGI> Это ты сейчас про Heartbleed говорил?!!
Про неё родимую.

Татарин> Нет. Это тоже хороший, годный баг, но как пример он менее интересен: слишком известен и для использования требует соответствующего окружения, НЯП; неуниверсален. Ну и "слишком мощный", слишком простой для закладки.
О, тогда это второй такой уже известный широко случай. И таких случаев будет становится только больше.

Татарин> Нет. Это тоже хороший, годный баг, но как пример он менее интересен: слишком известен и для использования требует соответствующего окружения, НЯП; неуниверсален. Ну и "слишком мощный", слишком простой для закладки.

Есть мнение, что был сделан специально, но не совсем хватило квалификации. Типа закладка от хаккеров. Но вполне был использован и спецслужбами тоже.

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

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