|
| 1.3, InuYasha (??), 21:03, 09/01/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
Криптография - это такая область где скорость процессоров порой только мешает )
| | |
| |
| 2.7, Карлос Сношайтилис (ok), 22:30, 09/01/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
 При чем здесь скорость процессора?
Проблема в разном наборе операций в конкретном блоке кода из за оптимизаций компилятора. Возможность провести атаку будет и на медленном и на быстром проце.
| | |
| |
| 3.69, qetuo (?), 01:38, 11/01/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Бред. Никакого отношения к данной уязвимости компилятор не имеет.
>Проблема в том, что время операции деления не является константой и в различных окружениях **число выполняемых для деления циклов CPU зависит от входных данных**. | | |
| |
| 4.81, Аноним (81), 08:03, 12/01/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
как раз таки именно компилятор и имеет.
Авторы Kyber прекрасно знали, что деление уязвимо к атакам по таймингу. Но у них в оригинальном коде выполняется деление на константу, известную во время компиляции. Поэтому при компиляции с оптимизациями (а у них в Makefile безусловно задано -O3) никакой уязвимости не будет - компилятор заменит это деление нужными умножениями, сдвигами и т.п.
Проблема в том, что Бернштейн скомпилировал свой пример с -Os, там компилятор уже не стал оптимизировать это место, и получилась атака по таймингу. Ну а всякие сказочные криптоэксперты из cloudflare, aws и т.п. просто скопировали оригинальный код, не потрудившись разобраться в нем.
| | |
|
|
| 2.13, Аноним (-), 00:12, 10/01/2024 [^] [^^] [^^^] [ответить] | +5 +/– | Вон то совершенно не зависит от скорости проца Только от факапов с зависимостью... большой текст свёрнут, показать | | |
| |
| |
| 4.26, penetrator (?), 03:28, 10/01/2024 [^] [^^] [^^^] [ответить]
| +2 +/– | |
там есть деление с приватной частью ключа, которая выполняется с разной скоростью
какая разница есть там ветвление или нет
нужна только корреляция между обрабытывемымти секретными данными и временем обработки - ВСЁ
| | |
| 4.39, Аноним (39), 10:18, 10/01/2024 [^] [^^] [^^^] [ответить] | +/– | А какая разница какие там ветвления В формулировке этого класса вулнов не прису... большой текст свёрнут, показать | | |
|
| |
| |
| 5.45, Аноним (45), 12:13, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
Как вариант улучшить тело цикла:
...
flag = flag | (input1[i] != input2[i]);
// branchless version of
// flag = flag || (input1[i] != input2[i]);
// which is no-early-return version of
// if(input1[i] != input2[i]) return FAIL;
...
| | |
| |
| 6.47, Аноним (39), 13:05, 10/01/2024 [^] [^^] [^^^] [ответить] | +/– | Эм в принципе может быть рассмотрен как условный оператор, кто б его там з... большой текст свёрнут, показать | | |
| |
| 7.56, Аноним (45), 16:22, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
Но |= всё равно логично использовать вместо +=, чтобы переполнение в ноль было принципиально невозможно.
| | |
| |
| 8.59, Аноним (-), 19:31, 10/01/2024 [^] [^^] [^^^] [ответить] | +/– | По своему прикольный ход мыслей, спасибо Впрочем, переполнение можно рубануть и... текст свёрнут, показать | | |
| |
| 9.77, Аноним (-), 16:08, 11/01/2024 [^] [^^] [^^^] [ответить] | +/– | p s кстати бонусом - кажется ЭТО еще и к rowhammer относительно устойчиво Чтоб... текст свёрнут, показать | | |
|
|
|
|
| 5.66, Sw00p aka Jerom (?), 20:54, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
> 2) нет зависимости поведения от входных данных, всегда жует 100 байтов хоть
> что.
а зачем это, зачем делать константой количество циклов, в вашем примере главное не останавливаться при первом же несоответствии, а это вы решили путем прохода по всем битам и применения битовых операций. Остается только доказать, что эти битовые операции не коррелируют, то есть:
(0^0), (0^1), (1^0), (1^1) - константны по времени исполнения. Они могут быть константны по времени, а по всяким там энергетическим параметрам они будут такими же? Разве переходной процес из 0 -> 1 и 1 -> 0 константен?
| | |
| |
| 6.75, Аноним (-), 15:37, 11/01/2024 [^] [^^] [^^^] [ответить] | +/– | Чтобы не утекать никакой полезной информации атакующему А вы что подумали В то... большой текст свёрнут, показать | | |
| |
| |
| 8.79, Аноним (79), 19:56, 11/01/2024 [^] [^^] [^^^] [ответить] | +/– | Атакующий чаще всего знает лимиты И даже если это новое знание, круто, знаете ч... большой текст свёрнут, показать | | |
| |
| 9.80, Аноним (79), 20:22, 11/01/2024 [^] [^^] [^^^] [ответить] | +/– | Кстати говоря вспомнил что DJB в своих алго любит такое для относительно мелких ... текст свёрнут, показать | | |
| |
| |
| 11.88, Аноним (-), 15:29, 14/01/2024 [^] [^^] [^^^] [ответить] | +/– | Убивает портабельность и читаемость кода - something to avoid в общем случае И... большой текст свёрнут, показать | | |
| |
| |
| 13.90, Аноним (-), 23:26, 14/01/2024 [^] [^^] [^^^] [ответить] | +/– | Ну дык Мне асмовый выхлоп прочекать там где оно реально важно, 1 раз на версию ... большой текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
|
| 3.34, Аноним (34), 06:59, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ваш код содержит синтаксические ошибки. Кроме того - вот оно! Если массивы были выделены динамически (скорее всего, это так), будет вероятная утечка памяти. И причем тут C?
| | |
| |
| 4.40, Аноним (39), 10:32, 10/01/2024 [^] [^^] [^^^] [ответить] | +/– | man псевдокод , он не обязан совпадать с существующимм ЯП, только иллюстрироват... большой текст свёрнут, показать | | |
| 4.85, Коммуникатор (?), 09:12, 12/01/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Если массивы были выделены динамически
нужно корректно освободить память после завершения процедуры, в том числе при аварийном завершении.
| | |
|
|
| 2.84, Аноним (34), 09:09, 12/01/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Криптография - это такая область где скорость процессоров порой только мешает )
Криптография - это такая область, где скорость процессоров компенсирует неудачные реализации алгоритмов )
| | |
|
| 1.4, Аноним (-), 21:40, 09/01/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Я сталкивался с тем, что в геометрии деления - ноно, всё что угодно только не деления, но выясняется, что в криптографии тоже. :)
| | |
| |
| 2.15, anonymous (??), 00:50, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
причем тут геометрия - устройство деления всегда дольше отрабатывает чем например умножения, ибо надо как бы предсказывать результат от старших разрядов, то есть гораздо больше логических операций.
| | |
| |
| 3.52, Аноним (-), 14:11, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
В геометрии с делением проблема не со скоростью, а с тем, что деление не является равномерно-непрерывной функцией на своей области определения. Это было бы не важно, если бы компьютер считал в вещественных числах, но он считает во float.
| | |
|
|
| 1.5, Витюшка (?), 21:51, 09/01/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– | |
Уже исправлена в Zig. Интересно как безопасные языки решают эту проблему :))
В zig например есть такая issue https://github.com/ziglang/zig/issues/1776 для гарантированных константных операций в блоке кода.
Т.е. zig будет гарантировать что все операции константные и все выходы будут с одинаковым временем (не будет раннего выхода из блока)
timeconst {
// in this block all math operations become constant time
// and it is a compile error to call non timeconst functions
}
Вот это уровень! Это очень круто, если будет реализовано. Вот что я считаю безопасным языком программирования.
| | |
| |
| |
| 3.9, Аноним (9), 23:23, 09/01/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
при майнинге битка. гарантированно будешь обнаруживать блок каждую секунду
| | |
| |
| |
| 5.43, Аноним (39), 11:46, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– | |
В реалтайме нас может волновать точные предсказуемые времянки. И иногда отработать быстрее чем ожидалось не меньший фэйл чем не успеть к дедлайну.
Только представь что тебе открывали дверь приводом на 30 секунд, например, в лифте, ты привык к этому, спокойно заходишь - и тут тебя вдруг хренакс дверями по бокам! Кодер заоптимизировал - теперь за 5 секунд таймаут отрабатывает! Вот и втискивайся за 5 секунд теперь, или вот те дверью по бочине, на выбор! :)
| | |
|
|
|
| 2.65, Аноним (-), 20:31, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
А как это поможет, если в делении ветвлений нет, а скорость выполнения разная?
Будет иллюзия безопасности, типа посмотрите у нас все в timeconst блоке, а по факту - нет.
| | |
| 2.82, Аноним (81), 08:39, 12/01/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Интересно как безопасные языки решают эту проблему
если ты про раст, то очень просто: допускают CVE, получают репорт, исправляют, над исправленным местом пишут комментарий "// SAFETY: this is safe". Не то что в этих ваших устаревших сишках с плюсами, понимать надо.
| | |
|
| 1.11, Ivan_83 (ok), 23:27, 09/01/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 DJB всё не даёт покоя что кто то пользуется алгоритмами которые не он создал.
Вот пусть по сетке продемонстрирует, в стандартных юзкейсах типа вебсервера с TLS, а то на стенде можно много всего насочинять.
| | |
| |
| 2.14, Аноним (-), 00:19, 10/01/2024 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> DJB всё не даёт покоя что кто то пользуется алгоритмами которые не он создал.
Покажи ему уязвимости в его алго в ответ, хренли.
> Вот пусть по сетке продемонстрирует, в стандартных юзкейсах типа вебсервера с TLS,
> а то на стенде можно много всего насочинять.
С RC4 такие господа уже довыступались - им показали так что WEP теперь секунд за 30 выносится. Вот тоже господа с увереной рожей рассказывали что мол небольшой bias конечно фи, но как бы продемонстрируйте... блин, а вот продемонстрировали! И правы оказались - параноики, считавшие что это фи.
"Безопасность бывает 2 уровней - high и нехай".
| | |
|
| |
| |
| 3.23, Аноним (10), 02:55, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
Потому что сишный код имеет очень далёкое отношение к тому, что реально будет выполнено на железе. Сейчас не семидесятые. Все эти хитрые ужимки и прыжки с магией битовых операций нивелируются любым обновлением компилятора или архитектуры, каждый из который перекроит код как захочет.
| | |
| |
| 4.31, Аноним (31), 04:58, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
Нужно на ассемблере писать? А нет, там не пойдет, там же спекулятивные вычисления и всякие Meltdown/Spectre. Надо отдельную плату паять на транзисторах и лампах? Нет, там ЭМ излучение и жужжание дросселей. А-а-а, все фигня переходим на http://
| | |
| 4.38, Аноним (45), 09:53, 10/01/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
А memory-mapped IO как до сих пор работает? В сях есть возможность сказать компилятору: "если я приказал делать бессмысленные вещи шаг за шагом, как написано, то бери и делай" - как раз, чтобы MMIO можно было реализовать.
https://godbolt.org/z/f73GrThK3
| | |
| |
| 5.49, Аноним (49), 13:28, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
И какое отношение имеет дизассемблерный псевдокод к тому что исполнится на железе? Кстати хороший пример, процессор просто посмотрит на состояние кеша и регистров и оптимизирует это. На x86 даже все эти регистры типа eax уже виртуальные, ибо внутри там что-то RISC-подобное крутится с переименованием реальных регистров. Это всё фейк, призрак древних времён.
| | |
| |
| 6.55, Аноним (45), 16:07, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
Этот код имеет прямое отношение к:
> нивелируются любым обновлением компилятора
.
> посмотрит на состояние кеша
Ну да, для MMIO на умном процессоре этого маловато, хотя на x86 всё-таки есть дремучие способы отключить кэширование для региона памяти и есть S/L/MFENCE.
Но чего мы хотим и что ты в комменте, начинающем ветку, предлагаешь в качестве альтернативы?
| | |
|
|
| 4.44, Аноним (39), 12:06, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Потому что сишный код имеет очень далёкое отношение к тому,
Булшит. Как правило си это довольно тонкий shim над железом. И аккуратно сделанная математика - таки, вот, прокатывает.
> что реально будет выполнено на железе. Сейчас не семидесятые.
> Все эти хитрые ужимки и прыжки с магией битовых операций нивелируются
> любым обновлением компилятора или архитектуры, каждый из который
> перекроит код как захочет.
В общем случае не перекроит. Хотя для сильно специфичных случаев есть например volatile.
| | |
| |
| 5.50, Аноним (49), 13:32, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Как правило си это довольно тонкий shim над железом.
Вот это точно булшит. Сам придумал, или вдохновился классической книжкой Кернига и Ричи 1978 года выпуска?
| | |
| |
| 6.60, Аноним (-), 19:42, 10/01/2024 [^] [^^] [^^^] [ответить] | +/– | Вдохновился програмингом фирмварей МК например Я одним си Cortex M с ноля по... большой текст свёрнут, показать | | |
|
|
|
|
|
| 1.18, Аноним (18), 02:10, 10/01/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Почему бы раз и навсегда не закрыть данную уязвимость путём обёртки уязвимого API в
template <typename ...ArgsT>
std::tuple<uint64_t, ResT> doMeasured(ArgsT ...args){
auto t1 = getTicks();
auto res = doCryptoOp(args...);
auto t2 = getTicks();
return {t2-t1, res};
}
auto maxTime = doMeasured(etalon, args).get<0>();
template<typename... ArgsT>
ResT doProtected(ArgsT ...args){
auto [delay, res] = doMeasured(args...);
auto delta = maxTime - delay;
if(delta>0){
delayLoop(delta);
} else {
delayLoop(0);
}
return res;
}
| | |
| |
| 2.21, Вы забыли заполнить поле Name (?), 02:25, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Проблема в том, что время операции деления не является константой и в различных окружениях число выполняемых для деления циклов CPU зависит от входных данных. | | |
| |
| 3.22, Аноним (22), 02:34, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
Причём тут деление/modinverse? Я говорю об универсальной защите. Функция внутри - это серый ящик, для которого известен только его worst-case по времени. Анализ и отслеживания деталей реализации не нужен для такой защиты, можно хоть поломать constant-time свойство функции, такая защита всё равно должна работать.
| | |
| |
| 4.24, Аноним (10), 03:04, 10/01/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
Это всё прекрасно, но производители процессоров даже с криптографическими AES инструкциями умудрились облажаться в плане атак по таймингу. А вы говорите "серый ящик".
| | |
| |
| 5.25, Аноним (25), 03:19, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
Какая блин разница, если можно простотвремя выполнения кода искусственно выравнивать?
| | |
| |
| 6.29, Sw00p aka Jerom (?), 03:55, 10/01/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
какого кода?, опять засрали свои мозги абстракциями высочайших языков программирования, корреляцию можно снимать с элементарной инструкции, а ваша функция "серый" ящик которая, это набор инструкций. И защититься можно лишь в том случае если нет этой кореляции, даже при установки бита в 0 или 1 уже есть кореляция по времени, зависит от гранулярности измерения.
| | |
|
| 5.46, Аноним (39), 12:16, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Это всё прекрасно, но производители процессоров даже с
> криптографическими AES инструкциями умудрились облажаться
> в плане атак по таймингу. А вы говорите "серый ящик".
В AES на структурном уровне проблема: S-box это априори проблемная конструкция. Поэтому более современные алго типа Salsa/Chacha/... - состоят из чистой простой математики в "core", и это не зависит от доступа к памяти. Поэтому S-box based алго сейчас считают, в общем то, плохим устаревшим дизайном. На современных процах с кешами это уязвимо к атакам на тайминги. И кроме теоретических - были и вполне практичные демо как спереть из соседней виртуалки ключи. И зачем нам спрашивается виртуализация, если сосед ключи сворует?!
| | |
|
|
|
| 2.42, sidewalker (?), 11:39, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
Этот метод имеет две очевидные мне проблемы:
1) Надо задавать время, а время зависит от железа и нагрузки, и мы либо замедляем до неприличия, либо получаем случае вылета за этот кейс.
Да это осложняет вытягвание информации, но те самые уязвимости в процессоре раньше тоже считались неприминимыми...
2) Утечка по сторонним каналам.
Ну те этот код ограничивает время ответа на оригинальный запрос. Но есть еще нагрузка на проц, которую он никак не меняет и её утечка через другие запросы и прочие, так как сервер не один этот код выполняет.
Опять же, да вроде сложно, но вспоминаем дыры в процах или ров-хаммеры, там не сильно легче...
| | |
| |
| 3.51, Аноним (51), 13:54, 10/01/2024 [^] [^^] [^^^] [ответить] | +/– | Я не программист, но у меня такое предложение, чтобы неплохо отгородиться от тай... большой текст свёрнут, показать | | |
| |
| 4.61, Аноним (-), 19:47, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
> границе 3го квартиля). Те, кто выполняется быстрей, в конце получают бонус
> в качестве заданного количества nop'ов для выравнивания (или тут-то и проблема,
> чтобы точно посчитать это количество?). Те кто медленней (оставшиеся 25%) растворяется
> и тонет в усредненном море.
Осталось придумать как это все прикрутить в кодогенерацию компилерам...
| | |
| |
| 5.68, Аноним (68), 23:32, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
Во время выполнения? Типа собрать метрику (mycrypto --getbias), и в условный /etc/timebias сохранить значение времени под который подгонять время выполнения, чтобы добить нужным количеством nop?
| | |
| |
| 6.76, Аноним (-), 15:48, 11/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Во время выполнения? Типа собрать метрику (mycrypto --getbias), и в условный /etc/timebias
> сохранить значение времени под который подгонять время выполнения, чтобы добить нужным
> количеством nop?
Просто это получится довольно сложная и интрузивная фигня типа profile guided optimization. На которую в силу гиморности ее использования (почти) все как раз и забивают.
Т.е. так в принципе можно - но это добавит прилично головняка и програмерам и авторам компилеров, и в силу первого на это все равно почти все забьют. Вон там Zig лучше придумал, но у него фича с багом оказалась. И совсем не факт что это единственный баг в такой фиче. На этом фоне аккуратно выписать критичный сегмент кода выглядит несколько более внушающим доверие мероприятием, как по мне.
| | |
|
|
|
| 3.71, Аноним (71), 13:19, 11/01/2024 [^] [^^] [^^^] [ответить] | +/– | Зависит, но мы сначала это время профилируем на локальной машине Не зависит, ес... большой текст свёрнут, показать | | |
|
|
| 1.36, Бывалый смузихлёб (?), 08:53, 10/01/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
> криптоалгоритмов, стойких к подбору на квантовом компьютере
Окей, устойчивый к квантовым штукам
> Таким образом, на основании изменения времени операций
> можно получить представление о характере используемых
> при делении данных
Они мерили время выполнения на квантовом компе или на обычном ?
На обычном - никто ничего не обещал
> Для успешного проведения атаки необходимо,
[ завоняло израильскими учоными-грантоедами ]
> чтобы задаваемый атакующим шифротекст обрабатывался
> с использованием одной и той же пары ключей
> и чтобы можно было точно измерить время выполнения операции
> чтобы можно было точно измерить время выполнения операции
Подумаешь, мелочь. Ерунда. Для многоядерного проца то, у которого потоков больше чем ядер, со спекулятивным выполнением и обвесом из со-процессоров.
Всего лишь точно регулярно измерять время выполнения операций и чтобы ничего другого не менялось. Ну точь-в-точь израильские уч.ные.
Они что, в гугол переехали или это очередная их операция "под другим флагом". Всех кто поприличней решили тоже обмазать )
| | |
| 1.37, Аноним (37), 09:21, 10/01/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Квантовых компьютеров не существует! Их придумали лишь для того чтобы гребсти бабло и получать гранты. А постквантовые алгоритмы делают вместо уже надёжных проверенных классических вот для таких "уязвимостей"! (шутка)
| | |
| |
| 2.54, Аноним (54), 15:09, 10/01/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Напишите это на картонке, повесьте на шею и ходите так по улицам. Найдете единомышлеников, обещаю.
| | |
|
| |
| 2.53, Аноним (-), 14:11, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
А потом получить узвимость из-за предсказания "алгоритма случайных чисел" который эту задержку генерирует)
| | |
| |
| 3.62, ИмяХ (ok), 19:48, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
 А потом героически исправить эту уязвимость и получить за это премию.
| | |
|
| 2.63, Аноним (-), 19:53, 10/01/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Что мешает в таких случаях просто вставлять в каждый цикл случайную задержку?
Тут мешает некомпетентность коментаторов опеннета - которые видимо не в курсе что качественная генерация случайных чисел весьма отдельный топик.
А некачественная... благодаря ей большинство вафельниц у хомячков типа вас крякается очень сильно быстрее чем вы там себе это представляли. Нет, ваш дофигасимвольный уникальный пароль вам не поможет. И хреновый рандом играет определенную роль в этом шоу.
| | |
|
| 1.58, Аноним (58), 19:07, 10/01/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Уязвимость остаётся неисправленной в библиотеках:
rustpq/pqcrypto/pqcrypto-kyber (5 января исправление добавлено в libsignal, но в самом pqcrypto-kyber уязвимость пока не исправлена).
rust, фу таким быть! а ещё его безопасным называют! rust будь как zig !
| | |
| 1.67, ааноним (?), 21:04, 10/01/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Так не честно - алгоритм для квантового компьютера, а код выполнили на распи 2.
| | |
|
