У меня используется конфигурация raid1 поверх dm-integrity. Убивается аж три зайца — во-первых, смерть диска не фатальна, во-вторых, криптоконтейнер бонусом (aes-gcm-random, шифрование и аутентификация), а самое главное — защита от незаметного повреждения.
Так уж получается, что если зайти в спецификацию диска, взять оттуда bit error rate и перемножить на количество тех самых бит, получается очень грустная картина. В предельном случае не всегда гарантируется успешное чтение всего диска :)
Потому логика тут такая — если dm-integrity при чтении видит, что хеш не совпадает — то наверх возвращается I/O error. Совсем такая же, как будто сектор физически не читается. Дальше в дело вступает raid1, который при получении такой ошибки просто читает тот же сектор с другого диска, и попутно исправляет ошибку на сбойном, записывая правильные данные. Вероятность того, что ошибки будут в одном и том же месте, очень маленькая. Еженедельный запуск raid-check не дает им накапливаться, но при этом совсем ненавязчив.
Плюс решения в том, что оно абсолютно прозрачно для использования, и создает абстракцию надежного диска, куда можно просто класть файлы, и они там будут лежать.
Минусы такого решения:
Хеши жрут ощутимое количество места, от диска на 10 маркетинговых терабайт сначала остается 9.1 реальных, а потом 8.6 за вычетом хешей.
Для того, чтобы гарантировать атомарность записи (иначе есть риск испортить сектор при сбое питания, когда данные уже записаны, а хеш еще нет) dm-integrity использует журналирование. Потому производительность на запись очень далека от идеала. Но для моего сценария "холодного хранения" это не проблема.
Если включать шифрование, неплохо бы не потерять ключи :) К счастью в силу их небольшого размера их можно хоть на граните гравировать.
P.S.: Куда интереснее вопрос с георепликацией, чтобы пожар/потоп/маски-шоу и прочий форс-мажор не становился фатальной проблемой. Вот тут я решений, которые бы представляли похожую абстракцию "надежного диска" не знаю. Самое близкое — два инстанса minio и отдельный процесс синхронизации, при этом один инстанс становится строго мастером, а второй строго репликой.
Если человек может сам проверить, как учтён его голос, то никто не помешает потребовать это сделать в присутствии «контролёра».
Принципиально это разрешимо, стандартный метод решения проблем паяльника (что тут, что в криптоконтейнерах) — plausible deniability. Только в одном случае открывается ложный диск, а тут вот можно "проверить", что пользователь голосовал за любого кандидата (хоть за всех сразу).
Т.е. формулируя более строго — пользователь должен иметь возможность проверить голос, но не иметь возможности доказать.
Другое дело, что системы с таким свойством обычно получаются довольно сложные, и я не уверен, есть ли реализации на практике.
Ну конкретно поднесущую несложно — надо просто "принять сигнал повторно". Примерно так работали трехпрограммные радиоточки, только вместо приема радио они получали уже готовое аудио по проводам, а потом его демодулировали.
У ЦРУ было намного более продвинутое маскирование, когда сигнал кодировался положением импульса внутри двух "опорных", а сами пачки импульсов шли случайно. Вот тут намного менее тривиальный приемник должен быть.
Слайд 10, красным помечено выбранное разработчиками (например, см. предыдущие слайды — шифр представляет из себя SP-сеть, и она тоже помечена красным, ровно как и "Выбор пространства V8").
какая из следующих двух последовательностей длины 10 более случайная:
Речь таки идет о вероятности попадания в узкий класс. Какая из последовательностей длины десять более вероятна — где идет пять нулей подряд или где есть просто пять нулей в любых местах?
Институт стандартов NIST проводит два конкурса. В первом конкурсе AES участвуют 15 алгоритмов от различных авторов со всего мира, во втором, SHA-3 — 51 алгоритм. Какова вероятность того, что в обоих конкурсах победят алгоритмы от одного и того же автора? ;)
Ноль, конкурс прошел, команды авторов разные (пересекаются только в одном человеке).
Однако такая перестановка позволяет радикально упростить линейные и дифферинциальные методы криптоанализа.
Такая перестановка вырождает алгоритм до линейной операции. AES точно, кузнечик вроде похож. Можно хоть 100 раундов с такой перестановкой сделать, эффект будет как у одного.
И вот тут гораздо интереснее другое: существует ли набор метрик или тестов, который бы говорил о качестве блока перестановок в плане противостояния методам криптоанализа? Или это еще зависит от окружающего блок перестановк алгоритма?
Существует, например, корреляционная характеристика и дифференциальная характеристика. И это, кстати, один из ответов на вопрос "почему случайный s-box не всегда хорош" — если бы DES был со случайными S-Box-ами, он был бы сильно слабее.
И ведь вы таки снова уехали от темы. Авторы заявляют, что S-Box генерируется случайно (и заявляют, что потеряли программу, которая его генерировала), а по факту очень аккуратно попали в узкий осмысленный (!) класс перестановок.
Ведь там не только программа на ассемблере длиной в 80 байт. Программой просто пытались получить численные оценки сложности, которыми можно меряться. Перестановка осмысленная с точки зрения математики. Случайно там оказалось дискретное логарифмирование. Случайно она отображает регулярные множества. Всего перестановок 256! ≈ 2^1684, а перестановок TKlog ≈ 2^76. Различных программ на ассемблере длиной 80 байт ≤2^640 (не все из них валидны, многие из них делают одно и то же, но да ладно).
Масштаб удачи просто поражает. Случайно выбить событие с вероятностью порядка 10^-315 — это уметь надо.
Т.е. более предметно рассматривать вопрос, что авторы хотели вложить в перестановку. Я лично вижу три варианта:
бекдор (тогда не скажут)
анти-бекдор, перестановка защищает от какой-то секретной атаки на блочные шифры, известной ФСБ (тогда тоже не скажут)
быстрая аппаратная реализация за счет регулярности (такие действительно есть). Но этот вариант маловероятный — тогда бы так и сказали, а не говорили бы, что это случайность и программу потеряли.
И то что позже может быть найден достаточно короткий алгоритм формирующий эту последовательность вовсе не делает «враньем» первичный постулат о случайности создания этой перестановки.
Разумеется, не делает. Зато длина алгоритма позволяет говорить о вероятностях.
Есть вероятность, что они искренне случайно выбрали такую подстановку. И есть вероятность, что они просто наврали, а о реальных критериях выбора подстановки говорить не хотят или не имеют права.
Вероятность первого оценивается математически, учитывая, что каждый сэкономленный байт влияет на эту вероятность экспоненциально, она очень маленькая. Вероятность второго предлагаю каждому оценить самостоятельно, учитывая, что даже в США был пример с DES.
Если для вас это не так, то мне искренне жаль.
Я предпочитаю птицу, которая ходит как утка, выглядит как утка и крякает как утка, называть уткой. Хотя заметьте, я ни разу не делал ДНК-тест этих птиц и строго говоря утверждать о принадлежности к биологическому виду не могу.
Если вам более привычно сохранять свою картину мира, где есть всемирный заговор против стойкого алгоритма, ценой веры в события, вероятности которых имеют не один десяток нулей после запятой, то я не могу вас за это осуждать. В конце концов, вы далеко не один такой.
Возможно он будет длиннее самой таблицы, но такой алгоритм всегда найдется.
Это подразумевалось, да, из контекста первого сообщения. Имелся в виду "алгоритм короче, чем запись константой", который существует не всегда.
Но и делать выводы о надежности алгоритмов на основе домыслов — тоже не поддерживаю.
Потому что в криптографии действует презумпция ненадежности, вот и все. Особенно в конкурсах на стандарты. Все вышеизложенное вытекает из этого.
Вывод, кстати, делается не на основе домыслов, а на основе факта, что авторы врут. Это, в отличие от возможного бекдора, установлено с достаточной достоверностью.
Плюс, как я вон выше про кривые NIST привел, заменять возможно ненадежные алгоритмы — стандартная практика, даже если ненадежность не доказана (или доказана, но вычислительно недостижима).
Нет, про DES было ровно так же. Пришла NSA и сказала "ваши таблицы плохие, берите мои таблицы, они хорошие". И только спустя много лет выяснилось, почему же они были хорошие. А до этого все тоже гадали, что они в этих таблицах спрятали (но да, тогда там не смогли найти структуру, просто обмусоливали факт таблиц, хз откуда взявшихся). Но DES был очень давно и был единственным. А сейчас этих алгоритмов много, хочешь AES, хочешь Blowfish, хочешь ChaCha20-Poly1305.
И да, криптография в основном не является точной наукой. Там точно известны способы, как делать не надо, а способы, как делать надо — эмпирические, "вроде не поломали" и "на данный момент нет известных атак". Случаи, когда у примитивов есть доказанная стойкость, немногочисленны, и в основном опираются на (недоказанную) стойкость нижестоящего примитива. Единственный шифр с доказанной абсолютной стойкостью — вообще одноразовый блокнот. Обычно доказывают стойкость режимов шифрования или подписи (OAEP, XTS) в предположении, что нижележащий шифр (RSA, AES) соответствует какой-то модели безопасности.
"Случайно — нет алгоритма" правильно с точки зрения статистики. В среднем на случайную перестановку не найдется эффективные алгоритма, но да, есть некоторые вырожденные случаи — например, перестановка 1-2-3-4-5..., или та, что у ГОСТа. Вероятность попасть на вырожденный случай маленькая, а длина алгоритмов — как раз неплохая метрика для оценки вырожденности этого случая. Математически это называется "энтропия".
Ресурсы исследователей ограничены, и когда ты подаешь заявку на алгоритм — никто не будет разбираться "что имел в виду автор", и никто не будет исходить из тезиса "если это пока не нашли — значит этого нет". Потому с точки зрения международной стандартизации ГОСТ рассматривается именно как интересная задача "что же там сныкали", а не как криптографический примитив. Для прекращения его рассмотрения в качестве криптографического примитива достаточно самого факта, что что-то спрятали. Потому что есть другие примитивы, где ничего не прятали, и которые можно анализировать по существу, а не тратить время на поиски бекдора или на установление его отсутствия.
И да, я не говорю что ГОСТ плохой, я просто говорю, что при таких вводных им пользоваться никто не будет. Сфера его применения — офицеры ФСБ, которые темной ночью будут закрываться в кабинете и шифровать друг другу пакеты. Ну и все, кто от них зависит.
Аналогично сейчас так же обмусоливают эллиптические NIST-овые кривые, говоря о том, что они в общем-то хз откуда взялись и возможно принадлежат к какому-то секретному классу слабых кривых. И именно потому есть понятие "curve rigidity" и альтернативы в виде X25519 и X488. Заметьте — и это в сторону американских кривых, никаких скреп и новичков. Абсолютно те же самые принципы. Просто криптография так работает, вся. Вот оно, выделено жирным красным цветом — абсолютно те же заявления — "непонятно как получено".
Условно говоря, желающих жить с крокодилом немного, несмотря на то, что он вроде не кусается. Достаточно того, что зубы есть. Но да, математически наличие бекдора не доказано, если вы это хотели услышать. Другое дело, что от факта возможности, но недоказанности перспективы шифра лучше не становятся.
Если перестановка действительно случайная (как утверждают авторы) — то нельзя придумать алгоритм, который бы был по размеру меньше этой подстановки (для случайных данных самый простой способ записать их — привести как есть, константой). А тут вот получается, причем намного меньше.
Пример — сама таблица 256 байт, самая короткая программа на C для её генерации — 134 байта, на ассемблере есть реализация в 80 байт. Вероятность, что авторы выбрали случайную таблицу, а для неё случайно нашлась программа, в три раза её короче — ну, очень небольшая, это уж точно.
Основная претензия — авторы не говорят, зачем это нужно, и даже отрицают сам факт того, что это намеренно. Оправдание — "нууу мы тут выбрали случайную таблицу, а это оно само", что не выдерживает никакой критики, ибо класс таких таблиц очень узкий, и если оно действительно само — авторам стоит купить сотню лотерейных билетов — выиграют сотню квартир, машин, миллионов и что там еще в качестве призов предлагается.
В криптографии так не принято, когда автор одновременно выдвигает алгоритм в качестве стандарта и скрывает внутреннее устройство. Либо крестик (т.е. объяснить аномалию), либо трусы (т.е. идти и шифровать в недрах ФСБ, там такое любят). Они бы еще бинарник обфусцированный дали и предложили стандартизировать, а что — алгоритм? Алгоритм!
Возможно, что эта структура в таблице усиливает какие-то свойства алгоритма, а рассказать об этом не могут, т.к. раскрыть принцип формирования таблицы == раскрыть саму атаку. Такое уже было с DES, и тогда тоже все говорили о том, что возможно NSA вставила бекдор. Вопрос доверия ФСБ полагаю оставить за рамками этого комментария, лично у меня этого доверия нет. И в целом основывать защищенность на доверии одной спецслужбе — не самая лучшая идея.
Ну вот, повод взять МК поёмче и таки сделать возможность заливать туда пользовательскую часть прошивки для взаимодействия с диодами и I2C бейджа. Хотя в TSSOP20 поёмче найти сложно, конечно, но вот в LQFP уже легко. Да хоть тот же 103C8T6.
Например, комбинируя бутлоадер и скриптовый язык — по умолчанию в пользовательскую зону прошит интерпретатор, а кто хочет — может загрузчиком перешить на что-то своё.
Поскольку основные функции типа инициализации шины и ШИМ генератора для светодиодов уже будут в основной прошивке, для нативной части там даже сильно емче не надо делать — оно и так сойдет, т.к. API есть и только прикладная логика нужна. А вот для интерпретатора может и не хватить, это да.
Ну конкретных идей нет, есть только абстрактные, насчет просто I2C шины и прошивки.
Первое, что напрашивается — просто вывести возможность (например, через USB CDC) отправлять сырые запросы на шину, адрес-направление-буфер.
Второе — воткнуть туда какой-нибудь микропитон, луа или что-то похожее, если ресурсы МК позволяют, и активировать по какому-нибудь триггеру — и пусть владелец дальше питонячит.
Третье, самое хардкорное, это сделать в оригинальной прошивке функцию бутлоадера и отдать конец флеша под запись пользователю. Аналогично, по какому-то триггеру управление передается на ресет-вектор из пользовательского куска. Хотя, конечно, это имеет свои побочные эффекты — пользовательский кусок может читать основную прошивку, а при особом желании может и писать. Но если чтение не проблема, а те, кто её сам перезаписал — ССЗБ, то почему бы и нет.
Тут больше вопрос в том, насколько эффективно опенсорс-решения справляются с фильтрацией входящего спама. Эта задача выглядит сложнее, чем прохождение исходящих антиспам-проверок.
Из Docker-контейнера нельзя загрузить модуль ядра, т.к. ядро общее с хостом. Если не хочется, чтобы оно свои модулей в ядро насовало — можно запускать из-под юзера, если паранойя и тут — то из-под отдельного юзера или завернуть в SELinux, например.
Для огромных файлов разумно (и GPG/PGP так и делает, например) генерировать случайный сессионный ключ, им шифровать файл, а сам ключ уже шифровать для N устройств.
У меня используется конфигурация raid1 поверх dm-integrity. Убивается аж три зайца — во-первых, смерть диска не фатальна, во-вторых, криптоконтейнер бонусом (aes-gcm-random, шифрование и аутентификация), а самое главное — защита от незаметного повреждения.
Так уж получается, что если зайти в спецификацию диска, взять оттуда bit error rate и перемножить на количество тех самых бит, получается очень грустная картина. В предельном случае не всегда гарантируется успешное чтение всего диска :)
Потому логика тут такая — если dm-integrity при чтении видит, что хеш не совпадает — то наверх возвращается I/O error. Совсем такая же, как будто сектор физически не читается. Дальше в дело вступает raid1, который при получении такой ошибки просто читает тот же сектор с другого диска, и попутно исправляет ошибку на сбойном, записывая правильные данные. Вероятность того, что ошибки будут в одном и том же месте, очень маленькая. Еженедельный запуск raid-check не дает им накапливаться, но при этом совсем ненавязчив.
Плюс решения в том, что оно абсолютно прозрачно для использования, и создает абстракцию надежного диска, куда можно просто класть файлы, и они там будут лежать.
Минусы такого решения:
P.S.: Куда интереснее вопрос с георепликацией, чтобы пожар/потоп/маски-шоу и прочий форс-мажор не становился фатальной проблемой. Вот тут я решений, которые бы представляли похожую абстракцию "надежного диска" не знаю. Самое близкое — два инстанса minio и отдельный процесс синхронизации, при этом один инстанс становится строго мастером, а второй строго репликой.
Принципиально это разрешимо, стандартный метод решения проблем паяльника (что тут, что в криптоконтейнерах) — plausible deniability. Только в одном случае открывается ложный диск, а тут вот можно "проверить", что пользователь голосовал за любого кандидата (хоть за всех сразу).
Т.е. формулируя более строго — пользователь должен иметь возможность проверить голос, но не иметь возможности доказать.
Другое дело, что системы с таким свойством обычно получаются довольно сложные, и я не уверен, есть ли реализации на практике.
Ну конкретно поднесущую несложно — надо просто "принять сигнал повторно". Примерно так работали трехпрограммные радиоточки, только вместо приема радио они получали уже готовое аудио по проводам, а потом его демодулировали.
У ЦРУ было намного более продвинутое маскирование, когда сигнал кодировался положением импульса внутри двух "опорных", а сами пачки импульсов шли случайно. Вот тут намного менее тривиальный приемник должен быть.
Там, судя по контенту, одноразовый блокнот записан, т.е. просто циферки группами по пять.
Угу, оно самое.
https://cdn.virgilsecurity.com/assets/docs/memo-on-kuznyechik-s-box.pdf
Есть еще такое. Там упомянуты те самые ограничения и:
https://www.ruscrypto.ru/resource/archive/rc2013/files/03_shishkin.pdf
Слайд 10, красным помечено выбранное разработчиками (например, см. предыдущие слайды — шифр представляет из себя SP-сеть, и она тоже помечена красным, ровно как и "Выбор пространства V8").
Речь таки идет о вероятности попадания в узкий класс. Какая из последовательностей длины десять более вероятна — где идет пять нулей подряд или где есть просто пять нулей в любых местах?
Ноль, конкурс прошел, команды авторов разные (пересекаются только в одном человеке).
Sly_tom_cat
Такая перестановка вырождает алгоритм до линейной операции. AES точно, кузнечик вроде похож. Можно хоть 100 раундов с такой перестановкой сделать, эффект будет как у одного.
Существует, например, корреляционная характеристика и дифференциальная характеристика. И это, кстати, один из ответов на вопрос "почему случайный s-box не всегда хорош" — если бы DES был со случайными S-Box-ами, он был бы сильно слабее.
И ведь вы таки снова уехали от темы. Авторы заявляют, что S-Box генерируется случайно (и заявляют, что потеряли программу, которая его генерировала), а по факту очень аккуратно попали в узкий осмысленный (!) класс перестановок.
Ведь там не только программа на ассемблере длиной в 80 байт. Программой просто пытались получить численные оценки сложности, которыми можно меряться. Перестановка осмысленная с точки зрения математики. Случайно там оказалось дискретное логарифмирование. Случайно она отображает регулярные множества. Всего перестановок 256! ≈ 2^1684, а перестановок TKlog ≈ 2^76. Различных программ на ассемблере длиной 80 байт ≤2^640 (не все из них валидны, многие из них делают одно и то же, но да ладно).
Масштаб удачи просто поражает. Случайно выбить событие с вероятностью порядка 10^-315 — это уметь надо.
Т.е. более предметно рассматривать вопрос, что авторы хотели вложить в перестановку. Я лично вижу три варианта:
Разумеется, не делает. Зато длина алгоритма позволяет говорить о вероятностях.
Есть вероятность, что они искренне случайно выбрали такую подстановку. И есть вероятность, что они просто наврали, а о реальных критериях выбора подстановки говорить не хотят или не имеют права.
Вероятность первого оценивается математически, учитывая, что каждый сэкономленный байт влияет на эту вероятность экспоненциально, она очень маленькая. Вероятность второго предлагаю каждому оценить самостоятельно, учитывая, что даже в США был пример с DES.
Я предпочитаю птицу, которая ходит как утка, выглядит как утка и крякает как утка, называть уткой. Хотя заметьте, я ни разу не делал ДНК-тест этих птиц и строго говоря утверждать о принадлежности к биологическому виду не могу.
Если вам более привычно сохранять свою картину мира, где есть всемирный заговор против стойкого алгоритма, ценой веры в события, вероятности которых имеют не один десяток нулей после запятой, то я не могу вас за это осуждать. В конце концов, вы далеко не один такой.
Это подразумевалось, да, из контекста первого сообщения. Имелся в виду "алгоритм короче, чем запись константой", который существует не всегда.
Потому что в криптографии действует презумпция ненадежности, вот и все. Особенно в конкурсах на стандарты. Все вышеизложенное вытекает из этого.
Вывод, кстати, делается не на основе домыслов, а на основе факта, что авторы врут. Это, в отличие от возможного бекдора, установлено с достаточной достоверностью.
Плюс, как я вон выше про кривые NIST привел, заменять возможно ненадежные алгоритмы — стандартная практика, даже если ненадежность не доказана (или доказана, но вычислительно недостижима).
Нет, про DES было ровно так же. Пришла NSA и сказала "ваши таблицы плохие, берите мои таблицы, они хорошие". И только спустя много лет выяснилось, почему же они были хорошие. А до этого все тоже гадали, что они в этих таблицах спрятали (но да, тогда там не смогли найти структуру, просто обмусоливали факт таблиц, хз откуда взявшихся). Но DES был очень давно и был единственным. А сейчас этих алгоритмов много, хочешь AES, хочешь Blowfish, хочешь ChaCha20-Poly1305.
И да, криптография в основном не является точной наукой. Там точно известны способы, как делать не надо, а способы, как делать надо — эмпирические, "вроде не поломали" и "на данный момент нет известных атак". Случаи, когда у примитивов есть доказанная стойкость, немногочисленны, и в основном опираются на (недоказанную) стойкость нижестоящего примитива. Единственный шифр с доказанной абсолютной стойкостью — вообще одноразовый блокнот. Обычно доказывают стойкость режимов шифрования или подписи (OAEP, XTS) в предположении, что нижележащий шифр (RSA, AES) соответствует какой-то модели безопасности.
"Случайно — нет алгоритма" правильно с точки зрения статистики. В среднем на случайную перестановку не найдется эффективные алгоритма, но да, есть некоторые вырожденные случаи — например, перестановка 1-2-3-4-5..., или та, что у ГОСТа. Вероятность попасть на вырожденный случай маленькая, а длина алгоритмов — как раз неплохая метрика для оценки вырожденности этого случая. Математически это называется "энтропия".
Ресурсы исследователей ограничены, и когда ты подаешь заявку на алгоритм — никто не будет разбираться "что имел в виду автор", и никто не будет исходить из тезиса "если это пока не нашли — значит этого нет". Потому с точки зрения международной стандартизации ГОСТ рассматривается именно как интересная задача "что же там сныкали", а не как криптографический примитив. Для прекращения его рассмотрения в качестве криптографического примитива достаточно самого факта, что что-то спрятали. Потому что есть другие примитивы, где ничего не прятали, и которые можно анализировать по существу, а не тратить время на поиски бекдора или на установление его отсутствия.
И да, я не говорю что ГОСТ плохой, я просто говорю, что при таких вводных им пользоваться никто не будет. Сфера его применения — офицеры ФСБ, которые темной ночью будут закрываться в кабинете и шифровать друг другу пакеты. Ну и все, кто от них зависит.
Аналогично сейчас так же обмусоливают эллиптические NIST-овые кривые, говоря о том, что они в общем-то хз откуда взялись и возможно принадлежат к какому-то секретному классу слабых кривых. И именно потому есть понятие "curve rigidity" и альтернативы в виде X25519 и X488. Заметьте — и это в сторону американских кривых, никаких скреп и новичков. Абсолютно те же самые принципы. Просто криптография так работает, вся. Вот оно, выделено жирным красным цветом — абсолютно те же заявления — "непонятно как получено".
Условно говоря, желающих жить с крокодилом немного, несмотря на то, что он вроде не кусается. Достаточно того, что зубы есть. Но да, математически наличие бекдора не доказано, если вы это хотели услышать. Другое дело, что от факта возможности, но недоказанности перспективы шифра лучше не становятся.
Если перестановка действительно случайная (как утверждают авторы) — то нельзя придумать алгоритм, который бы был по размеру меньше этой подстановки (для случайных данных самый простой способ записать их — привести как есть, константой). А тут вот получается, причем намного меньше.
Пример — сама таблица 256 байт, самая короткая программа на C для её генерации — 134 байта, на ассемблере есть реализация в 80 байт. Вероятность, что авторы выбрали случайную таблицу, а для неё случайно нашлась программа, в три раза её короче — ну, очень небольшая, это уж точно.
Основная претензия — авторы не говорят, зачем это нужно, и даже отрицают сам факт того, что это намеренно. Оправдание — "нууу мы тут выбрали случайную таблицу, а это оно само", что не выдерживает никакой критики, ибо класс таких таблиц очень узкий, и если оно действительно само — авторам стоит купить сотню лотерейных билетов — выиграют сотню квартир, машин, миллионов и что там еще в качестве призов предлагается.
В криптографии так не принято, когда автор одновременно выдвигает алгоритм в качестве стандарта и скрывает внутреннее устройство. Либо крестик (т.е. объяснить аномалию), либо трусы (т.е. идти и шифровать в недрах ФСБ, там такое любят). Они бы еще бинарник обфусцированный дали и предложили стандартизировать, а что — алгоритм? Алгоритм!
Возможно, что эта структура в таблице усиливает какие-то свойства алгоритма, а рассказать об этом не могут, т.к. раскрыть принцип формирования таблицы == раскрыть саму атаку. Такое уже было с DES, и тогда тоже все говорили о том, что возможно NSA вставила бекдор. Вопрос доверия ФСБ полагаю оставить за рамками этого комментария, лично у меня этого доверия нет. И в целом основывать защищенность на доверии одной спецслужбе — не самая лучшая идея.
Ну вот, повод взять МК поёмче и таки сделать возможность заливать туда пользовательскую часть прошивки для взаимодействия с диодами и I2C бейджа. Хотя в TSSOP20 поёмче найти сложно, конечно, но вот в LQFP уже легко. Да хоть тот же 103C8T6.
Например, комбинируя бутлоадер и скриптовый язык — по умолчанию в пользовательскую зону прошит интерпретатор, а кто хочет — может загрузчиком перешить на что-то своё.
Поскольку основные функции типа инициализации шины и ШИМ генератора для светодиодов уже будут в основной прошивке, для нативной части там даже сильно емче не надо делать — оно и так сойдет, т.к. API есть и только прикладная логика нужна. А вот для интерпретатора может и не хватить, это да.
Ну конкретных идей нет, есть только абстрактные, насчет просто I2C шины и прошивки.
Тут больше вопрос в том, насколько эффективно опенсорс-решения справляются с фильтрацией входящего спама. Эта задача выглядит сложнее, чем прохождение исходящих антиспам-проверок.
А чем обусловлено отсутствие I2C-интерфейса на разъемах?
В том, что это не Domain-Validated сертификат, а значит — его выпуск требует не только владения доменом, а еще, например, юрлица.
Комментарий удален
Это если слово
privateиспользовать при объявлении. А если не использовать (члены класса по умолчанию приватны) — то не получится.