А причину "не тянет" вы примерно сформулировали, но стоит уточнить что сделать обработку сильно независимой там нельзя. До какой-то степени можно разнести обработку по ядрам с обменом через общую память, но довольно быстро всё упирается именно в обмен.
В целом всё похоже на тренировку нейросетей, когда 4-ре акселератора через InfiniBand иногда дают лишь 30% прироста.
Не согласен с формулировкой.
Подобное противопоставление (они — мы) просто еще один шаг к "чебурнету".
В итоге просто будут функциональные форки/клоны OpenSSL (и других библиотек), отдельные версии браузеров и т.д.
Хотя такой сценарий нельзя назвать совсем плохим — будет создан спрос на соответствующие компетенции и их локальную наработку.
Осмелюсь повторить, что умеренное ослабление — крайне маловероятно, мягко говоря, ибо 275 УК как "Деятельность, направленной против безопасности Российской Федерации").
Т.е. вижу примерно один сценарий (авторы Стриборг/Кузненик получили готовый или исправленный SBOX и были не в курсе его структуры). Как вариант, возможно повторение истории.
Scratch, мне кажется стоит аккуратно обозначить в статье возможные причины "мухлежа со структурой".
Уместно вспомнить об истории с таблицей замен в Магме, где таблица замен была загружаемым параметром.
IMHO для Стрибог авторы взяли уже готовый S-BOX, либо он был им предоставлен в какой-то момент. Соответственно, я допускаю, что авторы не знали об алгоритме генерации, т.е. не являются авторами S-BOX. Поэтому и решились давать объяснения в виде "поиска от случайного" и затем "потеряли сиды".
В принципе это соответствует практическим традициям применения крипто-схем с таблицами замен. Причем как с отечественными традициями (явная выдача разных таблиц), так и с зарубежными (тоже самое, только "не столь публично" как у нас).
То что алгоритм генерации решили не раскрывать (или не решились раскрывать) — точно не является плюсом для публичного национального стандарта.
Думаю, стало неожиданным, что алгоритм генерации был восстановлен так быстро. Предполагаю был с умом запущен подбор набора уравнений в GPU-кластере и т.п., но и утечки нельзя исключать. Ну а для авторов Стриборга и Кузненича это стало facepalm-ом.
Крики "бэкдор" и "мы все умрем" IMHO только от "около диванных" аналитиков. Тут у меня несколько тезисов:
Наличие структуры не говорит о бэкдоре или слабости. В массе S-BOX-ов есть структура. Нужен глубокий анализ с выводами/доказательствами и никак иначе. Мягко говоря, крайне маловероятно, что в S-BOX умышленно внесли слабость (ибо 275 УК). IMHO структура как-раз от обратного, т.е. для стойкости (но безусловно хотелось-бы увидеть доказательства).
Факт замалчивания структуры неприятен и по-хорошему заставляет ждать публичных результатов криптоанализа "еще три года" после раскрытия алгоритма генерации S-BOX. Т.е. если вы НЕ попадаете под требования регулятора и вольны не использовать Стрибог/Кузненик, то еще года три (видимо) будете относится к ним как к молодым (не проверенными временем) крипто-схемам.
К заявлениям "в наших SBOX не структуры" стоит относится очень осторожно. Это примерно невозможно доказать. Соответственно, утверждение "в SBOX не структуры" никогда не означает что структуры действительно нет, и нас ждет еще несколько каминг-аутов.
Гипотетическая смена таблицы замен не должна стать проблемой, поскольку AFAIK чуть менее чем во всех отечественных "железных" реализациях предусматривается такая возможность (закладывается в требования).
Собственно уже установлено что sbox не случайный, ибо вероятность подобных совпадений — примерно как выиграть во все лотереи по одному билету (набору цифр).
Говорить о бекдоре и "поможет взлому" — нельзя без доказательств, т.е. будет крайней желтизной. Надо отдать должное Scratch за то что не перешел эту грань (хотя рядом) и в статье всё есть, включая основной вопрос — Зачем отрицалось наличие структуры.
Тем не менее, всё таки стоит явно отметить, что наличие структуры в sbox — это не плохо и не хорошо само по себе, а не-идеальные mix/max нелинейности не облегчают атаки.
Использование bit banding для GPIO даёт чуть больше удобства/выгоды, чем подсчитано в статье.
Потому-что операции bit banding атомарны, что избавляет от необходимости запрещать/разрешать прерывания для изменения отдельных бит.
При этом затраты на запрещение/разрешения прерываний, как правило, больше чем просто пара инструкций CPSID/CPSIE.
Потому-что непосредственно использование CPSIE в большом/сложном проекте (и/или в повторное используемом коде), как правило, недопустимо.
Потому-что прерывания могут быть уже запрещены ранее по стеку вызова или потоку выполнения кода и будут разрешены позже, т.е. прерывания могут быть запрещены для более широкого контекста, внутри которого может быть вызван ваш GPIO-код.
Соответственно, вместо__disable_irq()/__enable_irq() требуется сохранять и восстанавливать маску прерываний или флаги CPU. Например, см local_irq_save() / local_irq_restore(). Но при использовании bin banding всего этого можно избежать, как минимум использовать реже (при операциях над несколькими регистрами и т.п.).
В случае управления "выходами" GPIO речь не о memory barries и/или memory ordering, а о потенциальном переключении процессора на другую задачу и/или обработчик прерываний, которые могут обращаться к тому-же GPIO. Соответственно будет прелестный heisenbug, если переключение произойдет между LDR и STR.
Кроме этого, CPSIE не всегда подходит, например если прерывания были запрещены выше по стеку вызовов для более широкого контекста. Соответственно, нередко перед CPSID приходится сохранять маску, а вместо CPSIE ёё восстанавливать.
Поставляли, а после из этого старательно сделали (и продолжают) "байку", ибо Butthurt (но уже не у всех). Собственно рецепт "деланья" баек стар, проверен, главное начинать с "незамутненных" голов )
Но для объективности нужно заметить:
там действительно были "длинные" контракты, предположительно с какими-то штрафами за неисполнение.
поставляли не все (взвешенную пропорцию не посчитать, но и зачем?), кто-то из капиталистов (особенно с еврейскими корнями и/или деньгами) отказался не смотря на гипотетические штрафы и потерю "деловой репутации".
другие решили что "просто бизнес, ничего личного" и до-выполняли контракты даже через подставных (псевдо)посредников, их потом назвали "нехорошими" и повторили "не делайте так" (но не более).
Если подытожить, то "в стране не без ходорковских", а для первой половины 20-го (до ООН-просветления и кучи всяческих деклараций) позиций "нашей крови нет — не наше дело" была в поле в головах правителей, т.е. позиция "руководства" США ожидаема в координатах морали того времени.
Из всей этой истории с разборками США и Китая понятно только то, что все организации, стандартизирующее что-либо, должны находиться в юрисдикции не какой-то страны, тем более не тех, кто там с имперскими комплексами.
А вот это правильный вывод, но де-факто имеем ровно обратное.
Так по вашей ссылке более-менее растолковано — не нравятся китайца инфантильные мультяшки, которые имеют символические ассоциации в современной китайской культурной традиции. Имеют право не хотеть.
https://www.comsol.ru/
А причину "не тянет" вы примерно сформулировали, но стоит уточнить что сделать обработку сильно независимой там нельзя. До какой-то степени можно разнести обработку по ядрам с обменом через общую память, но довольно быстро всё упирается именно в обмен.
В целом всё похоже на тренировку нейросетей, когда 4-ре акселератора через InfiniBand иногда дают лишь 30% прироста.
Не согласен с формулировкой.
Подобное противопоставление (они — мы) просто еще один шаг к "чебурнету".
В итоге просто будут функциональные форки/клоны OpenSSL (и других библиотек), отдельные версии браузеров и т.д.
Хотя такой сценарий нельзя назвать совсем плохим — будет создан спрос на соответствующие компетенции и их локальную наработку.
Осмелюсь повторить, что умеренное ослабление — крайне маловероятно, мягко говоря, ибо 275 УК как "Деятельность, направленной против безопасности Российской Федерации").
Т.е. вижу примерно один сценарий (авторы Стриборг/Кузненик получили готовый или исправленный SBOX и были не в курсе его структуры). Как вариант, возможно повторение истории.
Это будет означать наличие двойных стандартов и дискриминации.
Scratch, мне кажется стоит аккуратно обозначить в статье возможные причины "мухлежа со структурой".
Уместно вспомнить об истории с таблицей замен в Магме, где таблица замен была загружаемым параметром.
IMHO для Стрибог авторы взяли уже готовый S-BOX, либо он был им предоставлен в какой-то момент. Соответственно, я допускаю, что авторы не знали об алгоритме генерации, т.е. не являются авторами S-BOX. Поэтому и решились давать объяснения в виде "поиска от случайного" и затем "потеряли сиды".
В принципе это соответствует практическим традициям применения крипто-схем с таблицами замен. Причем как с отечественными традициями (явная выдача разных таблиц), так и с зарубежными (тоже самое, только "не столь публично" как у нас).
То что алгоритм генерации решили не раскрывать (или не решились раскрывать) — точно не является плюсом для публичного национального стандарта.
Думаю, стало неожиданным, что алгоритм генерации был восстановлен так быстро. Предполагаю был с умом запущен подбор набора уравнений в GPU-кластере и т.п., но и утечки нельзя исключать. Ну а для авторов Стриборга и Кузненича это стало facepalm-ом.
Крики "бэкдор" и "мы все умрем" IMHO только от "около диванных" аналитиков. Тут у меня несколько тезисов:
Гипотетическая смена таблицы замен не должна стать проблемой, поскольку AFAIK чуть менее чем во всех отечественных "железных" реализациях предусматривается такая возможность (закладывается в требования).
Собственно уже установлено что sbox не случайный, ибо вероятность подобных совпадений — примерно как выиграть во все лотереи по одному билету (набору цифр).
Говорить о бекдоре и "поможет взлому" — нельзя без доказательств, т.е. будет крайней желтизной. Надо отдать должное Scratch за то что не перешел эту грань (хотя рядом) и в статье всё есть, включая основной вопрос — Зачем отрицалось наличие структуры.
Тем не менее, всё таки стоит явно отметить, что наличие структуры в sbox — это не плохо и не хорошо само по себе, а не-идеальные mix/max нелинейности не облегчают атаки.
Хороший пример как правильно сделать vendor lock-in.
+1
Соответственно, вместо__disable_irq()/__enable_irq() требуется сохранять и восстанавливать маску прерываний или флаги CPU. Например, см local_irq_save() / local_irq_restore(). Но при использовании bin banding всего этого можно избежать, как минимум использовать реже (при операциях над несколькими регистрами и т.п.).
Видимо есть недопонимание "атомарности".
В случае управления "выходами" GPIO речь не о memory barries и/или memory ordering, а о потенциальном переключении процессора на другую задачу и/или обработчик прерываний, которые могут обращаться к тому-же GPIO. Соответственно будет прелестный heisenbug, если переключение произойдет между
LDRиSTR.Кроме этого,
CPSIEне всегда подходит, например если прерывания были запрещены выше по стеку вызовов для более широкого контекста. Соответственно, нередко перед CPSID приходится сохранять маску, а вместо CPSIE ёё восстанавливать.На запрещение/разрешение прерываний уходит более чем достаточно как байтов кода, так и таков.
Думаю вам стоит поправить/доработать статью.
Вы не ту технику ремонтируете, (видимо) поэтому "не в курсе".
Поставляли, а после из этого старательно сделали (и продолжают) "байку", ибо Butthurt (но уже не у всех). Собственно рецепт "деланья" баек стар, проверен, главное начинать с "незамутненных" голов )
Но для объективности нужно заметить:
Если подытожить, то "в стране не без ходорковских", а для первой половины 20-го (до ООН-просветления и кучи всяческих деклараций) позиций "нашей крови нет — не наше дело" была в поле в головах правителей, т.е. позиция "руководства" США ожидаема в координатах морали того времени.
см Договор о патентной кооперации и Парижская конвенция.
Не "коммунистический", а сатирический и достаточно объектный, в том числе в том, всего что касается социалистической действительности.
Так двигайтесь от конца списка к началу, если угодно.
Кого там китайцы бомбили за последние 25 лет (имеется ввиду после конфликта с Вьетнамом)?
А ядреным жахнули, или канцерогенными дефолиантами полили?
Кто не хочет кормить свой "хуавей", будет кормить чужой.
Осталось выбрать.
А вот это правильный вывод, но де-факто имеем ровно обратное.
Так по вашей ссылке более-менее растолковано — не нравятся китайца инфантильные мультяшки, которые имеют символические ассоциации в современной китайской культурной традиции. Имеют право не хотеть.