Вообще, мне довольно сложно вам аргументированно что нибудь сказать, я не криптоаналитик, не математик и не физик.
Вы написали про доказательства верности выкладок, их непротиворечивость. Но ведь даже если выкладки верны — это не значит, что в них нету никаких уязвимостей. Например, история MD5:
разработали в 1991 году
теоретические уязвимости в 1993 году
первая практическая атака в 2005 году
практические атаки за приемлемое количество времени в 2006 году
У меня есть сомнения, что все учёные в мире были 10 лет слепы :) Подозреваю, что тут как с программами: показать и доказать, что правильно работает какой нибудь printf — это одно, а найти в нём багу — совсем другое.
На самом деле есть методы верификации ГПСЧ, которые могут сказать, что он сломан. Я сейчас детали не вспомню, читал давно, но изучаются статистический свойства сгенерированной последовательности. То есть в случае с закладкой в исходниках эти методы могут рассказать про закладку. А вот в случае из поста — вряд ли, на сколько я понимаю, там не были ухудшены статистические характеристики генератора.
Так, закладка на уровень выше. Берёте алгоритм, реализовываете на его основе кошерный open-source код, а там бац — и бэкдор. OpenSSL — отличная библиотека, развивается и поддерживается отличными разработчиками, используется чуть ли не на половине компьютеров мира, однако же не они написали про уязвимость алгоритма.
Использование столь сложных штук — это скорее вопрос веры, потому что для проверки собственными силами вам надо будет потратить несколько лет, и то не факт, что получится понять всю эту математику. Вот вы чуть ниже спрашиваете, используется ли Dual_EC_DRBG при генерации параметров в ECDSA в OpenSSL. Если используется не он, а другой — как вы проверите, что в нём нету подобных закладок на уровне самого алгоритма?
Вы путаете ПО и алгоритмы. Так закладки подобного рода в алгоритмы закладывают (или не закладки, а баги, которые потом используют кому надо). Алгоритмы тоже публичны, можете свободно читать, как, например, sha2 устроен. Сможете там багу или закладку найти? Я — точно нет, хотя считаю себя неплохим программистом.
Те, кто алгоритмы разрабатывают — они не программисты совсем, а скорее математики. Они не могут разрабатывать ПО, потому что не умеют. У них своя песочница, со своими конференциями и прочим, всё это довольно слабо пересекается с программированием. И про всякие допуски секретности не забывайте.
А вот проверить, что ПО правильно написано и реализует алгоритм правильно — вот это уже по силу разработчикам софта, баги типа дебиановских могут быть починены таким способом. Правда, чтобы найти такой баг, скорее всего нужен уже криптоаналитик.
Я уже писал несколько раз в комментариях к подобным статьям на хабре, что тут open source не помощник. Ну прочитаете вы исходник, и что? Найти такую уязвимость в Dual_EC_DRBG программист не может, это может криптоаналитик. А хороших криптоаналитиков всего тысячи в мире, и я не буду удивлён, если большая часть из них прямо или косвенно работает на правительство США, а большая часть из оставшихся — на правительства своих стран.
Вот типичный пример, отлично иллюстрирующий мою мысль:
In order to keep a warning from being issued by the Valgrind analysis tool, a maintainer of the Debian distribution applied a patch to the Debian implementation of the OpenSSL suite, which inadvertently broke its random number generator in the process. The broken version was included in the Debian release of September 17, 2006 (version 0.9.8c-1). Any key generated with the broken random number generator, as well as data encrypted with such a key, was compromised. The error was reported by Debian on May 13, 2008.
Смысл прост — установка руткита, который нельзя найти. Как вы наверное знаете, в x86 архитектуре есть кольца защиты, ring0 — ring3, в 0 кольце работает ядро, в 3 — пользовательский код. Остальные кольца в популярных ОС, на сколько я знаю, не используются. Кольца нужны для одной цели — код не видит ничего глубже своего кольца. То есть пользовательский код из ring3 никогда не прорвётся даже в ring2, не говоря уж про ring0. Гипервизоры с этой точки зрения работают в ring -1. Именно на этом была основана концепция blue pill ( ru.wikipedia.org/wiki/Blue_Pill ) от Рутковски: антивирусы работают в ring0, если мы сделаем фейковый гипервизор, который и является руткитом, то антивирус не сможет его найти.
Уже больше 20 лет у x86 процессоров есть специальный режим работы, который называется System Management Mode (SMM, ru.wikipedia.org/wiki/System_Management_Mode ). Интересен он тем, что выделяеся кусочек памяти, где выполняется собственно код по управлению конкретной системой (например, вентиляторами управлять надо). Более того, этот кусочек не видно из ring0, и даже гипервизор его не видит, только сам процессор, когда ловит специальное прерывание. Интел в середине двухтысячных годов сделали патчик в биосе, который запрещает как либо изменять содержимое этого кусочка памяти, тут как раз сильно помогает руткит в биосе или прошивке железа.
Есть и ещё интересные методы. Например, в процессоре сетевой карточки Broadcom. Вот слайды: esec-lab.sogeti.com/dotclear/public/publications/11-recon-nicreverse_slides.pdf. Зловред перехватывает пакеты со специальным заголовком и перенаправляет их на все остальные карточки broadcom, которые стоят в машине, а те высылают опять в сеть. То есть файрволл уже пал, правда у него всего 64 килобита в секунду получилось пересылать. Тот же мужик разработал мини шелл, который запускается на видеокарте, и сетевая посылает пакеты с опять же специальными заголовками в тот шелл. Тоже практически невозможно определить.
Читал ещё про один вариант: заражать ядро, которое находится в южном мосту материнок с Intel vPro. Там всё сложно, т.к. надо образ системного BIOS править, но результат ещё лучше, чем в предыдущем варианте. Аналогично — с руткитами в iLo и прочих IPMI, но я про такое ещё не слышал.
Вы всё придумываете новые и новые примеры, в каких ситуациях GPS не будет работать. К чему это? Чтобы доказать, что я не профессиональный геодезист? Так я и не утверждал этого. Я всего лишь интересуюсь темой GPS в частности и GNSS в целом (заметьте, не геодезией или картографией, а именно GPS). И меня интересует именно техническая часть, а не юридические заморочки.
А примеров привести, когда GPS не работает, кучу можно. В узком колодце ещё не будет работать. И под водой. И в плотной городской застройке тоже так себе. Но я не зря упомянул открытое небо. Будете утверждать, что не существует таких ущелий, где дрон из поста смог бы работать и получать координаты с приемлемым значением GDOP? К тому же в посте описывается, как картографировали Маттерхорн, причём с дрона, как это связано с ущельями и получением координат с высоты человеческого роста?
Ага, теперь ваша проблема понятна, зачем всё это было нужно.
Кстати, если задумаетесь таки менять — присмотритесь к пультам DEVO от Валькеры: www.walkera.com/en/category.php?id=23&parent_id=23. Для них появилась и активно пилится альтернативная прошивка www.deviationtx.com/, которая поддерживает много протоколов прям на родном железе. Модулей, правда, нету, зато есть модельки с экранами и 5.8GHz видео-приёмниками с выводом на экран пульта. Не уверен, что это удобно на улице, но фича для indoor полётов интересная.
Так у разных модулей ВЧ часть на разных чипах сделана же. Спектрумовские почти всегда на CyRF, например.
На четвёртой фотке ситуацию бы спас пигтеил с угловым SMA (или RP-SMA, какой он там) разъёмом и защитная нахлобучка. А много модулей делают уже с выступом и разъёмом, идущим наверх, с ними антенна пройдёт между дугой ручки и корпусом пульта, примерно вот так: www.horizonhobby.co.uk/aeroonline/e6spektrum/e6_modules/e6_jr_module/e6_jr_compatbile_module_installed.jpg. Но антенна, торчащая из корпуса из штатной дырки, ИМХО, всё равно удобней, так что пигтеил и тут пригодится.
Мы прилично шагнули вперёд, разработчиков стало больше, обкатанных решений больше. И научились готовить бесконечные по объёму хранилища, но об этом ещё будут статьи.
А, ещё в Новосибе офис открыли, можно телемост сделать :) Ну или вы к нам в Московский офис заходите.
Да, судя по этой и другим картинкам ( homepage.ntlworld.com/paul.robinson16/roll.jpg ), сайдстики напрямую с ELAC соединены. Почему-то я был уверен, что через FMGC. Получается, что при правильных ELAC два комплекта органов управления (сайдстик и педали) должны автоматически правильно заработать. Жаль, что подробные доки в интернетах не найти.
Может, я не прав, но в таком описании, когда pmFBW накладывает ограничения и передаёт в FCU — это Boeing-way какой-то. А может это только мои тараканы и на самом деле там всё ок, и ведёт себя похоже на правду :)
А вот ELAC, SEC и FAC — это здорово. А супер-про версия пока только у них есть, или уже на ваш А320 примеряли?
Вот эти ребята обещают прям новый уровень реализма систем и авионики: www.flightsimlabs.com/aircraft/a320/.Но обещают они уже давно, а покупать пока нечего. В QPAC, на сколько это видно снаружи, правильная реализация самолёта, с FMGS (это мои догадки, код я естественно не видел), но системы, можно сказать, отсутствуют. В project magenta FBW реализован как прослойка между реальным и виртуальным джойстиком, а это не имеет ничего общего с настоящим A320.
Вообще, разговоры о правильной реализации A320, с FMGS, FAC, ELAC ведутся на разных форумах регулярно, но до финальной стадии, то есть модели с плагином, обычно не доходят. Но сразу вспоминается арбуз от JARDesign, они начали и сделали таки модель, памятник за это надо ставить. Но я его не пробовал ещё, хотя описания многообещающие.
Можете сравнить elliptics и ceph как хранилища объектов, без упора на eblob?
Elliptics — DHT, ceph — CRUSH.
Почему у ceph 100500 настроек а у elliptics 2?
Потому что разработчики ceph по непонятной лично мне причине решили, что пусть админ думает обо всём. У нас, конечно, не 2 настройки, а пара десятков, но бОльшая часть забот о перенастройке маршрутизации при изменении конфигурации кластера делает сам Elliptics, а не админ, и, с нашей точки зрения, это очень правильно.
Как жить без сишной либы?
ЗАМЕЧАТЕЛЬНО! Нет, правда, новый API намного лучше почти во всех случаях, а уж написать поверх него сишную обёртку можно, если очень надо.
Чем можно отправдать отсутствие возможности просмотра списка содержимого в кластере elliptics?
Вам куда отправить список из 50 миллиардов ключей? Итерироваться по ключам, кстати, можно.
Планируется ли когда-нибудь стабильная, долгоподдерживаемая версия API eblob и elliptics?
Elliptics 2.24 стал стабильным летом этого года, поддерживаться будет до лета следующего года. Релиз следующей стабильной версии в планах на эту зиму, будем стараться раз в пол года релизиться.
У нас обычные SATA 3.5" диски, полки — потому что так дешевле в пересчёте на гигабайт места в хранилище. Обычно 1 или 2 полки на 24 диска. Памяти стараемся побольше поставить (96 гигов, например), чтобы page cache хоть сколько либо эффективно работал. В общем, ничего шикарного. Вот если бы у нас были машинки с 256 гигами и SSD дисками (привет, MongoDB), нас можно было бы обвинять в поедании чёрной икры руками :)
Кусочек из большого файла у нас можно получить без проблем, в команде write можно задать offset и size, так что тут никакой проблемы нету. Есть смысл бить файл на куски только если у вас количество активных файлов сравнимо с количеством дисков в хранилище. Сходу приходит в голову пример с образами дисков для виртуализации.
Очень много — это по-разному. В одном из сервисов сейчас порядка 50 миллиардов ключей в трёх копиях, обслуживает их суммарно 12 машин (то есть примерно по 15 миллиардов ключей и по 4 машины в каждом ДЦ). Но там записи мелкие, единицы килобайт. Нагрузка порядка 10к запросов на чтение в секунду в вечернее время.
Есть другие сервисы, там файлы намного больше, десятки мегабайт. Существенно меньше файлов, зато по объёму — почти петабайт (опять же, в трёх копиях). Планируем перешагнуть рубеж в 10 петабайт в следующем году.
Нам очень легко разбираться с файлами, мы не обращаем внимание на размер. У нас есть большое преимущество перед файловыми системами — мы заранее знаем, какой будет размер записи, и применяем наиболее эффективный метод записи — append записи в конец большого блоба. В итоге мы максимально эффективно используем дисковое пространство, оверхэд составляют только служебные заголовки. При этом мы минимизируем количество random seek, запись превращается в линейную. Мы не испытываем никаких проблем с фрагментацией, которые обязательно возникнут при попытке запихать несколько мелких записей в блок. И ещё надо где-то держать список пустых блоков.
Что касается чтения — если вы начинаете хранить файл кусками, вам сразу надо придумывать механизм склеивания этих кусков, какой-то мэппинг. При обращении к файлу вам надо делать +1 seek, чтобы поднять файл мэппинга, и линейное чтение превращается в уже не столь линейное. При записи придётся синхронизировать запись блока и обновление маппинга, желательно делать это атомарно с точки зрения клиента. Конечно, у такой схемы есть и плюсы: не надо проводить большую дефрагментацию блобов, можно хранить неограниченно большие файлы.
Для раздачи больших файлов мы научили nginx раздавать их непосредственно из блобов, и тут запись одним куском идеально подходит и сильно упрощает процесс.
А сейчас я расскажу немножко о магии. В Elliptics есть возможность запускать server-side скрипты непосредственно на той ноде, где лежат данные. То есть, если действительно есть большая необходимость хранить файлы кусками, то это можно сделать, написав не очень большую программу на языке, поддерживаемом Cocaine: C++, Python, Java, Javascript. Вы будете отправлять запись на ноду в этот скрипт, а он уже будет разбираться с мэппингом, записью в правильный блок (блок при этом записывается как обычная запись), склеиванием блоков при чтении.
Вы написали про доказательства верности выкладок, их непротиворечивость. Но ведь даже если выкладки верны — это не значит, что в них нету никаких уязвимостей. Например, история MD5:
разработали в 1991 году
теоретические уязвимости в 1993 году
первая практическая атака в 2005 году
практические атаки за приемлемое количество времени в 2006 году
У меня есть сомнения, что все учёные в мире были 10 лет слепы :) Подозреваю, что тут как с программами: показать и доказать, что правильно работает какой нибудь printf — это одно, а найти в нём багу — совсем другое.
Использование столь сложных штук — это скорее вопрос веры, потому что для проверки собственными силами вам надо будет потратить несколько лет, и то не факт, что получится понять всю эту математику. Вот вы чуть ниже спрашиваете, используется ли Dual_EC_DRBG при генерации параметров в ECDSA в OpenSSL. Если используется не он, а другой — как вы проверите, что в нём нету подобных закладок на уровне самого алгоритма?
Те, кто алгоритмы разрабатывают — они не программисты совсем, а скорее математики. Они не могут разрабатывать ПО, потому что не умеют. У них своя песочница, со своими конференциями и прочим, всё это довольно слабо пересекается с программированием. И про всякие допуски секретности не забывайте.
А вот проверить, что ПО правильно написано и реализует алгоритм правильно — вот это уже по силу разработчикам софта, баги типа дебиановских могут быть починены таким способом. Правда, чтобы найти такой баг, скорее всего нужен уже криптоаналитик.
Вот типичный пример, отлично иллюстрирующий мою мысль:
In order to keep a warning from being issued by the Valgrind analysis tool, a maintainer of the Debian distribution applied a patch to the Debian implementation of the OpenSSL suite, which inadvertently broke its random number generator in the process. The broken version was included in the Debian release of September 17, 2006 (version 0.9.8c-1). Any key generated with the broken random number generator, as well as data encrypted with such a key, was compromised. The error was reported by Debian on May 13, 2008.
Уже больше 20 лет у x86 процессоров есть специальный режим работы, который называется System Management Mode (SMM, ru.wikipedia.org/wiki/System_Management_Mode ). Интересен он тем, что выделяеся кусочек памяти, где выполняется собственно код по управлению конкретной системой (например, вентиляторами управлять надо). Более того, этот кусочек не видно из ring0, и даже гипервизор его не видит, только сам процессор, когда ловит специальное прерывание. Интел в середине двухтысячных годов сделали патчик в биосе, который запрещает как либо изменять содержимое этого кусочка памяти, тут как раз сильно помогает руткит в биосе или прошивке железа.
Есть и ещё интересные методы. Например, в процессоре сетевой карточки Broadcom. Вот слайды: esec-lab.sogeti.com/dotclear/public/publications/11-recon-nicreverse_slides.pdf. Зловред перехватывает пакеты со специальным заголовком и перенаправляет их на все остальные карточки broadcom, которые стоят в машине, а те высылают опять в сеть. То есть файрволл уже пал, правда у него всего 64 килобита в секунду получилось пересылать. Тот же мужик разработал мини шелл, который запускается на видеокарте, и сетевая посылает пакеты с опять же специальными заголовками в тот шелл. Тоже практически невозможно определить.
Читал ещё про один вариант: заражать ядро, которое находится в южном мосту материнок с Intel vPro. Там всё сложно, т.к. надо образ системного BIOS править, но результат ещё лучше, чем в предыдущем варианте. Аналогично — с руткитами в iLo и прочих IPMI, но я про такое ещё не слышал.
А примеров привести, когда GPS не работает, кучу можно. В узком колодце ещё не будет работать. И под водой. И в плотной городской застройке тоже так себе. Но я не зря упомянул открытое небо. Будете утверждать, что не существует таких ущелий, где дрон из поста смог бы работать и получать координаты с приемлемым значением GDOP? К тому же в посте описывается, как картографировали Маттерхорн, причём с дрона, как это связано с ущельями и получением координат с высоты человеческого роста?
Кстати, если задумаетесь таки менять — присмотритесь к пультам DEVO от Валькеры: www.walkera.com/en/category.php?id=23&parent_id=23. Для них появилась и активно пилится альтернативная прошивка www.deviationtx.com/, которая поддерживает много протоколов прям на родном железе. Модулей, правда, нету, зато есть модельки с экранами и 5.8GHz видео-приёмниками с выводом на экран пульта. Не уверен, что это удобно на улице, но фича для indoor полётов интересная.
На четвёртой фотке ситуацию бы спас пигтеил с угловым SMA (или RP-SMA, какой он там) разъёмом и защитная нахлобучка. А много модулей делают уже с выступом и разъёмом, идущим наверх, с ними антенна пройдёт между дугой ручки и корпусом пульта, примерно вот так: www.horizonhobby.co.uk/aeroonline/e6spektrum/e6_modules/e6_jr_module/e6_jr_compatbile_module_installed.jpg. Но антенна, торчащая из корпуса из штатной дырки, ИМХО, всё равно удобней, так что пигтеил и тут пригодится.
А, ещё в Новосибе офис открыли, можно телемост сделать :) Ну или вы к нам в Московский офис заходите.
А вот ELAC, SEC и FAC — это здорово. А супер-про версия пока только у них есть, или уже на ваш А320 примеряли?
Вообще, разговоры о правильной реализации A320, с FMGS, FAC, ELAC ведутся на разных форумах регулярно, но до финальной стадии, то есть модели с плагином, обычно не доходят. Но сразу вспоминается арбуз от JARDesign, они начали и сделали таки модель, памятник за это надо ставить. Но я его не пробовал ещё, хотя описания многообещающие.
Elliptics — DHT, ceph — CRUSH.
Почему у ceph 100500 настроек а у elliptics 2?
Потому что разработчики ceph по непонятной лично мне причине решили, что пусть админ думает обо всём. У нас, конечно, не 2 настройки, а пара десятков, но бОльшая часть забот о перенастройке маршрутизации при изменении конфигурации кластера делает сам Elliptics, а не админ, и, с нашей точки зрения, это очень правильно.
Как жить без сишной либы?
ЗАМЕЧАТЕЛЬНО! Нет, правда, новый API намного лучше почти во всех случаях, а уж написать поверх него сишную обёртку можно, если очень надо.
Чем можно отправдать отсутствие возможности просмотра списка содержимого в кластере elliptics?
Вам куда отправить список из 50 миллиардов ключей? Итерироваться по ключам, кстати, можно.
Планируется ли когда-нибудь стабильная, долгоподдерживаемая версия API eblob и elliptics?
Elliptics 2.24 стал стабильным летом этого года, поддерживаться будет до лета следующего года. Релиз следующей стабильной версии в планах на эту зиму, будем стараться раз в пол года релизиться.
Кусочек из большого файла у нас можно получить без проблем, в команде write можно задать offset и size, так что тут никакой проблемы нету. Есть смысл бить файл на куски только если у вас количество активных файлов сравнимо с количеством дисков в хранилище. Сходу приходит в голову пример с образами дисков для виртуализации.
Очень много — это по-разному. В одном из сервисов сейчас порядка 50 миллиардов ключей в трёх копиях, обслуживает их суммарно 12 машин (то есть примерно по 15 миллиардов ключей и по 4 машины в каждом ДЦ). Но там записи мелкие, единицы килобайт. Нагрузка порядка 10к запросов на чтение в секунду в вечернее время.
Есть другие сервисы, там файлы намного больше, десятки мегабайт. Существенно меньше файлов, зато по объёму — почти петабайт (опять же, в трёх копиях). Планируем перешагнуть рубеж в 10 петабайт в следующем году.
Нам очень легко разбираться с файлами, мы не обращаем внимание на размер. У нас есть большое преимущество перед файловыми системами — мы заранее знаем, какой будет размер записи, и применяем наиболее эффективный метод записи — append записи в конец большого блоба. В итоге мы максимально эффективно используем дисковое пространство, оверхэд составляют только служебные заголовки. При этом мы минимизируем количество random seek, запись превращается в линейную. Мы не испытываем никаких проблем с фрагментацией, которые обязательно возникнут при попытке запихать несколько мелких записей в блок. И ещё надо где-то держать список пустых блоков.
Что касается чтения — если вы начинаете хранить файл кусками, вам сразу надо придумывать механизм склеивания этих кусков, какой-то мэппинг. При обращении к файлу вам надо делать +1 seek, чтобы поднять файл мэппинга, и линейное чтение превращается в уже не столь линейное. При записи придётся синхронизировать запись блока и обновление маппинга, желательно делать это атомарно с точки зрения клиента. Конечно, у такой схемы есть и плюсы: не надо проводить большую дефрагментацию блобов, можно хранить неограниченно большие файлы.
Для раздачи больших файлов мы научили nginx раздавать их непосредственно из блобов, и тут запись одним куском идеально подходит и сильно упрощает процесс.
А сейчас я расскажу немножко о магии. В Elliptics есть возможность запускать server-side скрипты непосредственно на той ноде, где лежат данные. То есть, если действительно есть большая необходимость хранить файлы кусками, то это можно сделать, написав не очень большую программу на языке, поддерживаемом Cocaine: C++, Python, Java, Javascript. Вы будете отправлять запись на ноду в этот скрипт, а он уже будет разбираться с мэппингом, записью в правильный блок (блок при этом записывается как обычная запись), склеиванием блоков при чтении.