forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Уязвимость в реализациях постквантового алгоритма шифрования Kyber, opennews (??), 09-Янв-24, (0) [смотреть все]

Ну это в реализации, это не считово , Аноним (1), 20:54 , 09-Янв-24, (1) +8
Криптография - это такая область где скорость процессоров порой только мешает , InuYasha (??), 21:03 , 09-Янв-24, (3) –4 //

При чем здесь скорость процессора Проблема в разном наборе операций в конкретном, Карлос Сношайтилис (ok), 22:30 , 09-Янв-24, (7) –2 //

Бред Никакого отношения к данной уязвимости компилятор не имеет , qetuo (?), 01:38 , 11-Янв-24, (69) +1 //

как раз таки именно компилятор и имеет Авторы Kyber прекрасно знали, что деление, Аноним (81), 08:03 , 12-Янв-24, (81) +1

Вон то совершенно не зависит от скорости проца Только от факапов с зависимостью, Аноним (-), 00:12 , 10-Янв-24, (13) +5 //

В данной уязвимости нет логического ветвления, Карлос Сношайтилис (ok), 01:27 , 10-Янв-24, (17) +1 //

там есть деление с приватной частью ключа, которая выполняется с разной скорость, penetrator (?), 03:28 , 10-Янв-24, (26) +2
А какая разница какие там ветвления В формулировке этого класса вулнов не прису, Аноним (39), 10:18 , 10-Янв-24, (39)

а флагои ZF и CF в 0 или 1 разве за константное время , Sw00p aka Jerom (?), 03:39 , 10-Янв-24, (27) –1
а где пример трушного кода nooby негодует , Sw00p aka Jerom (?), 04:01 , 10-Янв-24, (30) //

На правах первой идеи пришедшей в голову code flag 0 for i 0 i 10, Аноним (39), 11:24 , 10-Янв-24, (41)

Как вариант улучшить тело цикла code flag flag 124 input1 i input2, Аноним (45), 12:13 , 10-Янв-24, (45)

Эм в принципе может быть рассмотрен как условный оператор, кто б его там з, Аноним (39), 13:05 , 10-Янв-24, (47)

Но 124 всё равно логично использовать вместо , чтобы переполнение в ноль б, Аноним (45), 16:22 , 10-Янв-24, (56)

По своему прикольный ход мыслей, спасибо Впрочем, переполнение можно рубануть и, Аноним (-), 19:31 , 10-Янв-24, (59)

p s кстати бонусом - кажется ЭТО еще и к rowhammer относительно устойчиво Чтоб, Аноним (-), 16:08 , 11-Янв-24, (77)

а зачем это, зачем делать константой количество циклов, в вашем примере главное , Sw00p aka Jerom (?), 20:54 , 10-Янв-24, (66)

Чтобы не утекать никакой полезной информации атакующему А вы что подумали В том, Аноним (-), 15:37 , 11-Янв-24, (75)

1 значение константное, уже утекло знание, что input или равен меньше этой конс, Sw00p aka Jerom (?), 16:53 , 11-Янв-24, (78)

Атакующий чаще всего знает лимиты И даже если это новое знание, круто, знаете ч, Аноним (79), 19:56 , 11-Янв-24, (79)

Кстати говоря вспомнил что DJB в своих алго любит такое для относительно мелких , Аноним (79), 20:22 , 11-Янв-24, (80)

конопатить лучше на асм, что там наконопатит компилятор языка Х - тайна , а про, Sw00p aka Jerom (?), 23:34 , 12-Янв-24, (86)

Убивает портабельность и читаемость кода - something to avoid в общем случае И , Аноним (-), 15:29 , 14-Янв-24, (88)

ну вот, собственно ясно , Sw00p aka Jerom (?), 16:57 , 14-Янв-24, (89)
Ну дык Мне асмовый выхлоп прочекать там где оно реально важно, 1 раз на версию , Аноним (-), 23:26 , 14-Янв-24, (90)
https git kernel org pub scm linux kernel git torvalds linux git diff include , Sw00p aka Jerom (?), 23:41 , 14-Янв-24, (91)
Ответил в другом топике где вы спросили то же самое Struct в си - они как бы поч, Аноним (-), 01:45 , 15-Янв-24, (92)
лол, кек - выходит это ассемблерщикам надо понимать и помнить, что есть память, Sw00p aka Jerom (?), 02:46 , 15-Янв-24, (93)

Ваш код содержит синтаксические ошибки Кроме того - вот оно Если массивы были , Аноним (34), 06:59 , 10-Янв-24, (34) //

man псевдокод , он не обязан совпадать с существующимм ЯП, только иллюстрироват, Аноним (39), 10:32 , 10-Янв-24, (40)
нужно корректно освободить память после завершения процедуры, в том числе при ав, Коммуникатор (?), 09:12 , 12-Янв-24, (85)

Криптография - это такая область, где скорость процессоров компенсирует неудачны, Аноним (34), 09:09 , 12-Янв-24, (84)

Я сталкивался с тем, что в геометрии деления - ноно, всё что угодно только не де, Аноним (-), 21:40 , 09-Янв-24, (4) //

причем тут геометрия - устройство деления всегда дольше отрабатывает чем наприме, anonymous (??), 00:50 , 10-Янв-24, (15) //

В геометрии с делением проблема не со скоростью, а с тем, что деление не являетс, Аноним (-), 14:11 , 10-Янв-24, (52) //

Наркоман Действительные числа никак не помогают справляться с точками разрыва, Аноним_2го_Рода (?), 20:14 , 10-Янв-24, (64)

Уже исправлена в Zig Интересно как безопасные языки решают эту проблему В zi, Витюшка (?), 21:51 , 09-Янв-24, (5) –3 //

Ради интереса, кроме шифрования это где-нибудь полезно , Аноним (8), 23:11 , 09-Янв-24, (8) +2 //

при майнинге битка гарантированно будешь обнаруживать блок каждую секунду, Аноним (9), 23:23 , 09-Янв-24, (9) –1
Отвечу за анонима выше, возможно real-time что-нибудь , Аноним (10), 23:26 , 09-Янв-24, (10) +1 //

а чем алгоритм, с асимптотой O n допустим, отличается в реалтайие и не реалтайи, Sw00p aka Jerom (?), 05:06 , 10-Янв-24, (32)

В реалтайме нас может волновать точные предсказуемые времянки И иногда отработа, Аноним (39), 11:46 , 10-Янв-24, (43)

А где оно есть, если ишью еще открыта , Аноним (16), 01:21 , 10-Янв-24, (16)
Только в zig ее поправили как и в остальных реализациях, изменив выполняемые опе, Вы забыли заполнить поле Name (?), 02:12 , 10-Янв-24, (19) +1
так как и в сях, заменив деление умножением явно, penetrator (?), 03:48 , 10-Янв-24, (28)
А как это поможет, если в делении ветвлений нет, а скорость выполнения разная Бу, Аноним (-), 20:31 , 10-Янв-24, (65)
если ты про раст, то очень просто допускают CVE, получают репорт, исправляют, н, Аноним (81), 08:39 , 12-Янв-24, (82)

DJB всё не даёт покоя что кто то пользуется алгоритмами которые не он создал Вот, Ivan_83 (ok), 23:27 , 09-Янв-24, (11) //

Покажи ему уязвимости в его алго в ответ, хренли С RC4 такие господа уже довысту, Аноним (-), 00:19 , 10-Янв-24, (14) +3

Что оригинальный код, что патч https github com pq-crystals kyber commit dda2, Аноним (10), 23:30 , 09-Янв-24, (12) –1 //

Почему это хак , Вы забыли заполнить поле Name (?), 02:15 , 10-Янв-24, (20) //

Потому что сишный код имеет очень далёкое отношение к тому, что реально будет вы, Аноним (10), 02:55 , 10-Янв-24, (23) //

Нужно на ассемблере писать А нет, там не пойдет, там же спекулятивные вычислени, Аноним (31), 04:58 , 10-Янв-24, (31)
А memory-mapped IO как до сих пор работает В сях есть возможность сказать компи, Аноним (45), 09:53 , 10-Янв-24, (38) +1

И какое отношение имеет дизассемблерный псевдокод к тому что исполнится на желез, Аноним (49), 13:28 , 10-Янв-24, (49)

Этот код имеет прямое отношение к Ну да, для MMIO на умном процессоре этого мал, Аноним (45), 16:07 , 10-Янв-24, (55)

Булшит Как правило си это довольно тонкий shim над железом И аккуратно сделанн, Аноним (39), 12:06 , 10-Янв-24, (44)

Вот это точно булшит Сам придумал, или вдохновился классической книжкой Кернига, Аноним (49), 13:32 , 10-Янв-24, (50)

Вдохновился програмингом фирмварей МК например Я одним си Cortex M с ноля по, Аноним (-), 19:42 , 10-Янв-24, (60)

это строго доказанные математические формулы, не беспокойся, Аноним (81), 08:46 , 12-Янв-24, (83)

Почему бы раз и навсегда не закрыть данную уязвимость путём обёртки уязвимого AP, Аноним (18), 02:10 , 10-Янв-24, (18) //

Уязвимость в реализациях постквантового алгоритма шифрования..., Вы забыли заполнить поле Name (?), 02:25 , 10-Янв-24, (21) //

Причём тут деление modinverse Я говорю об универсальной защите Функция внутри , Аноним (22), 02:34 , 10-Янв-24, (22) //

Это всё прекрасно, но производители процессоров даже с криптографическими AES ин, Аноним (10), 03:04 , 10-Янв-24, (24) +2

Какая блин разница, если можно простотвремя выполнения кода искусственно выравни, Аноним (25), 03:19 , 10-Янв-24, (25)

какого кода , опять засрали свои мозги абстракциями высочайших языков программир, Sw00p aka Jerom (?), 03:55 , 10-Янв-24, (29) +1

В AES на структурном уровне проблема S-box это априори проблемная конструкция , Аноним (39), 12:16 , 10-Янв-24, (46)

Этот метод имеет две очевидные мне проблемы 1 Надо задавать время, а время зави, sidewalker (?), 11:39 , 10-Янв-24, (42) //

Я не программист, но у меня такое предложение, чтобы неплохо отгородиться от тай, Аноним (51), 13:54 , 10-Янв-24, (51) //

Осталось придумать как это все прикрутить в кодогенерацию компилерам , Аноним (-), 19:47 , 10-Янв-24, (61)

Во время выполнения Типа собрать метрику mycrypto --getbias , и в условный et, Аноним (68), 23:32 , 10-Янв-24, (68)

Просто это получится довольно сложная и интрузивная фигня типа profile guided op, Аноним (-), 15:48 , 11-Янв-24, (76)

Зависит, но мы сначала это время профилируем на локальной машине Не зависит, есл, Аноним (71), 13:19 , 11-Янв-24, (71)

Окей, устойчивый к квантовым штукамОни мерили время выполнения на квантовом комп, Бывалый смузихлёб (?), 08:53 , 10-Янв-24, (36) –1
Квантовых компьютеров не существует Их придумали лишь для того чтобы гребсти ба, Аноним (37), 09:21 , 10-Янв-24, (37) +1 //

Напишите это на картонке, повесьте на шею и ходите так по улицам Найдете едином, Аноним (54), 15:09 , 10-Янв-24, (54) +1

Что мешает в таких случаях просто вставлять в каждый цикл случайную задержку , voiceofreason (?), 13:07 , 10-Янв-24, (48) +1 //

А потом получить узвимость из-за предсказания алгоритма случайных чисел которы, Аноним (-), 14:11 , 10-Янв-24, (53) //

А потом героически исправить эту уязвимость и получить за это премию , ИмяХ (ok), 19:48 , 10-Янв-24, (62)
почему уязвимость, скорее бекдор, Sw00p aka Jerom (?), 13:39 , 11-Янв-24, (74)

Тут мешает некомпетентность коментаторов опеннета - которые видимо не в курсе чт, Аноним (-), 19:53 , 10-Янв-24, (63)

rustpq pqcrypto pqcrypto-kyber 5 января исправление добавлено в libsignal, но в, Аноним (58), 19:07 , 10-Янв-24, (58)
Так не честно - алгоритм для квантового компьютера, а код выполнили на распи 2 , ааноним (?), 21:04 , 10-Янв-24, (67) +1 //

не для, а против , Sw00p aka Jerom (?), 13:36 , 11-Янв-24, (72)

Сообщения [Сортировка по времени | RSS]

18. "Уязвимость в реализациях постквантового алгоритма шифрования..." +/–

Сообщение от Аноним (18), 10-Янв-24, 02:10

Почему бы раз и навсегда не закрыть данную уязвимость путём обёртки уязвимого 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;
}

Ответить | Правка | Наверх | Cообщить модератору

21. "Уязвимость в реализациях постквантового алгоритма шифрования..." +/–

Сообщение от Вы забыли заполнить поле Name (?), 10-Янв-24, 02:25

> Проблема в том, что время операции деления не является константой и в различных окружениях число выполняемых для деления циклов CPU зависит от входных данных.

Ответить | Правка | Наверх | Cообщить модератору

22. "Уязвимость в реализациях постквантового алгоритма шифрования..." +/–

Сообщение от Аноним (22), 10-Янв-24, 02:34

Причём тут деление/modinverse? Я говорю об универсальной защите. Функция внутри - это серый ящик, для которого известен только его worst-case по времени. Анализ и отслеживания деталей реализации не нужен для такой защиты, можно хоть поломать constant-time свойство функции, такая защита всё равно должна работать.

Ответить | Правка | Наверх | Cообщить модератору

24. "Уязвимость в реализациях постквантового алгоритма шифрования..." +2 +/–

Сообщение от Аноним (10), 10-Янв-24, 03:04

Это всё прекрасно, но производители процессоров даже с криптографическими AES инструкциями умудрились облажаться в плане атак по таймингу. А вы говорите "серый ящик".

Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость в реализациях постквантового алгоритма шифрования..." +/–

Сообщение от Аноним (25), 10-Янв-24, 03:19

Какая блин разница, если можно простотвремя выполнения кода искусственно выравнивать?

Ответить | Правка | Наверх | Cообщить модератору

29. "Уязвимость в реализациях постквантового алгоритма шифрования..." +1 +/–

Сообщение от Sw00p aka Jerom (?), 10-Янв-24, 03:55

какого кода?, опять засрали свои мозги абстракциями высочайших языков программирования, корреляцию можно снимать с элементарной инструкции, а ваша функция "серый" ящик которая, это набор инструкций. И защититься можно лишь в том случае если нет этой кореляции, даже при установки бита в 0 или 1 уже есть кореляция по времени, зависит от гранулярности измерения.

Ответить | Правка | Наверх | Cообщить модератору

46. "Уязвимость в реализациях постквантового алгоритма шифрования..." +/–

Сообщение от Аноним (39), 10-Янв-24, 12:16

> Это всё прекрасно, но производители процессоров даже с
> криптографическими AES инструкциями умудрились облажаться
> в плане атак по таймингу. А вы говорите "серый ящик".
В AES на структурном уровне проблема: S-box это априори проблемная конструкция. Поэтому более современные алго типа Salsa/Chacha/... - состоят из чистой простой математики в "core", и это не зависит от доступа к памяти. Поэтому S-box based алго сейчас считают, в общем то, плохим устаревшим дизайном. На современных процах с кешами это уязвимо к атакам на тайминги. И кроме теоретических - были и вполне практичные демо как спереть из соседней виртуалки ключи. И зачем нам спрашивается виртуализация, если сосед ключи сворует?!

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

42. "Уязвимость в реализациях постквантового алгоритма шифрования..." +/–

Сообщение от sidewalker (?), 10-Янв-24, 11:39

Этот метод имеет две очевидные мне проблемы:
1) Надо задавать время, а время зависит от железа и нагрузки, и мы либо замедляем до неприличия, либо получаем случае вылета за этот кейс.
Да это осложняет вытягвание информации, но те самые уязвимости в процессоре раньше тоже считались неприминимыми...
2) Утечка по сторонним каналам.
Ну те этот код ограничивает время ответа на оригинальный запрос. Но есть еще нагрузка на проц, которую он никак не меняет и её утечка через другие запросы и прочие, так как сервер не один этот код выполняет.
Опять же, да вроде сложно, но вспоминаем дыры в процах или ров-хаммеры, там не сильно легче...

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

51. "Уязвимость в реализациях постквантового алгоритма шифрования..." +/–

Сообщение от Аноним (51), 10-Янв-24, 13:54

Я не программист, но у меня такое предложение, чтобы неплохо отгородиться от тайминг атак.
1) Сконпейлировать бинарь криптософта - этакий черный ящик, который после сборки под целевую архитектуру заданным компилятором в машкодах может оказаться чем угодно.
2) Откармливать его некоторыми входными данными. Этакий fuzzing, но задача не сломать, а нагенерировать много разного и похожего на реальность.
3) Набрать статистику, скажем на N млн. случаев.
4) Исходя из статистики, ориентироваться опять же, например, на 3 квартиля. Идея в том, чтобы 75% случаев выполнялись за одинаковое фиксированное время (по границе 3го квартиля). Те, кто выполняется быстрей, в конце получают бонус в качестве заданного количества nop'ов для выравнивания (или тут-то и проблема, чтобы точно посчитать это количество?). Те кто медленней (оставшиеся 25%) растворяется и тонет в усредненном море.

Ответить | Правка | Наверх | Cообщить модератору

61. "Уязвимость в реализациях постквантового алгоритма шифрования..." +/–

Сообщение от Аноним (-), 10-Янв-24, 19:47

> границе 3го квартиля). Те, кто выполняется быстрей, в конце получают бонус
> в качестве заданного количества nop'ов для выравнивания (или тут-то и проблема,
> чтобы точно посчитать это количество?). Те кто медленней (оставшиеся 25%) растворяется
> и тонет в усредненном море.
Осталось придумать как это все прикрутить в кодогенерацию компилерам...

Ответить | Правка | Наверх | Cообщить модератору

68. "Уязвимость в реализациях постквантового алгоритма шифрования..." +/–

Сообщение от Аноним (68), 10-Янв-24, 23:32

Во время выполнения? Типа собрать метрику (mycrypto --getbias), и в условный /etc/timebias сохранить значение времени под который подгонять время выполнения, чтобы добить нужным количеством nop?

Ответить | Правка | Наверх | Cообщить модератору

76. "Уязвимость в реализациях постквантового алгоритма шифрования..." +/–

Сообщение от Аноним (-), 11-Янв-24, 15:48

> Во время выполнения? Типа собрать метрику (mycrypto --getbias), и в условный /etc/timebias
> сохранить значение времени под который подгонять время выполнения, чтобы добить нужным
> количеством nop?
Просто это получится довольно сложная и интрузивная фигня типа profile guided optimization. На которую в силу гиморности ее использования (почти) все как раз и забивают.
Т.е. так в принципе можно - но это добавит прилично головняка и програмерам и авторам компилеров, и в силу первого на это все равно почти все забьют. Вон там Zig лучше придумал, но у него фича с багом оказалась. И совсем не факт что это единственный баг в такой фиче. На этом фоне аккуратно выписать критичный сегмент кода выглядит несколько более внушающим доверие мероприятием, как по мне.

Ответить | Правка | Наверх | Cообщить модератору

71. "Уязвимость в реализациях постквантового алгоритма шифрования..." +/–

Сообщение от Аноним (71), 11-Янв-24, 13:19

>время зависит от железа
Зависит, но мы сначала это время профилируем на локальной машине.
>нагрузки
Не зависит, если операция укладывается в промежуток между переключениями контекста и процессор не тротлится по температуре: во время кванта процессор полностью принадлежит потоку.
>замедляем до неприличия
А ты как хотел? Караван движется со скоростью самого медленного его участника. Допустим если оставим хоть 0.001% случаев, которые медленнее на порядок, чем медленнейший из 10% самых быстрых, то это всё равно будет утечка информации.
>другие сторонние каналы вроде энергопотребления
Out of scope. Требуют относительно локального доступа, то есть либо прогу на том же компе, либо спецоборудования на устройствах на силовой сети или ethernet-кабеле или матплате или usb-устройстве или звуковой карте.... Если такое происходит, то кража ключей шифрования является наименьшей из проблем, так как можно воровать сразу плэйнтексты.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

18. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
Сообщение от Аноним (18), 10-Янв-24, 02:10
Почему бы раз и навсегда не закрыть данную уязвимость путём обёртки уязвимого 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; }
Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 10-Янв-24, 02:25
	> Проблема в том, что время операции деления не является константой и в различных окружениях число выполняемых для деления циклов CPU зависит от входных данных.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (22), 10-Янв-24, 02:34
	Причём тут деление/modinverse? Я говорю об универсальной защите. Функция внутри - это серый ящик, для которого известен только его worst-case по времени. Анализ и отслеживания деталей реализации не нужен для такой защиты, можно хоть поломать constant-time свойство функции, такая защита всё равно должна работать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+2 +/–
	Сообщение от Аноним (10), 10-Янв-24, 03:04
	Это всё прекрасно, но производители процессоров даже с криптографическими AES инструкциями умудрились облажаться в плане атак по таймингу. А вы говорите "серый ящик".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (25), 10-Янв-24, 03:19
	Какая блин разница, если можно простотвремя выполнения кода искусственно выравнивать?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+1 +/–
	Сообщение от Sw00p aka Jerom (?), 10-Янв-24, 03:55
	какого кода?, опять засрали свои мозги абстракциями высочайших языков программирования, корреляцию можно снимать с элементарной инструкции, а ваша функция "серый" ящик которая, это набор инструкций. И защититься можно лишь в том случае если нет этой кореляции, даже при установки бита в 0 или 1 уже есть кореляция по времени, зависит от гранулярности измерения.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (39), 10-Янв-24, 12:16
	> Это всё прекрасно, но производители процессоров даже с > криптографическими AES инструкциями умудрились облажаться > в плане атак по таймингу. А вы говорите "серый ящик". В AES на структурном уровне проблема: S-box это априори проблемная конструкция. Поэтому более современные алго типа Salsa/Chacha/... - состоят из чистой простой математики в "core", и это не зависит от доступа к памяти. Поэтому S-box based алго сейчас считают, в общем то, плохим устаревшим дизайном. На современных процах с кешами это уязвимо к атакам на тайминги. И кроме теоретических - были и вполне практичные демо как спереть из соседней виртуалки ключи. И зачем нам спрашивается виртуализация, если сосед ключи сворует?!
	Ответить \| Правка \| К родителю #24 \| Наверх \| Cообщить модератору


	42. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от sidewalker (?), 10-Янв-24, 11:39
	Этот метод имеет две очевидные мне проблемы: 1) Надо задавать время, а время зависит от железа и нагрузки, и мы либо замедляем до неприличия, либо получаем случае вылета за этот кейс. Да это осложняет вытягвание информации, но те самые уязвимости в процессоре раньше тоже считались неприминимыми... 2) Утечка по сторонним каналам. Ну те этот код ограничивает время ответа на оригинальный запрос. Но есть еще нагрузка на проц, которую он никак не меняет и её утечка через другие запросы и прочие, так как сервер не один этот код выполняет. Опять же, да вроде сложно, но вспоминаем дыры в процах или ров-хаммеры, там не сильно легче...
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	51. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (51), 10-Янв-24, 13:54
	Я не программист, но у меня такое предложение, чтобы неплохо отгородиться от тайминг атак. 1) Сконпейлировать бинарь криптософта - этакий черный ящик, который после сборки под целевую архитектуру заданным компилятором в машкодах может оказаться чем угодно. 2) Откармливать его некоторыми входными данными. Этакий fuzzing, но задача не сломать, а нагенерировать много разного и похожего на реальность. 3) Набрать статистику, скажем на N млн. случаев. 4) Исходя из статистики, ориентироваться опять же, например, на 3 квартиля. Идея в том, чтобы 75% случаев выполнялись за одинаковое фиксированное время (по границе 3го квартиля). Те, кто выполняется быстрей, в конце получают бонус в качестве заданного количества nop'ов для выравнивания (или тут-то и проблема, чтобы точно посчитать это количество?). Те кто медленней (оставшиеся 25%) растворяется и тонет в усредненном море.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (-), 10-Янв-24, 19:47
	> границе 3го квартиля). Те, кто выполняется быстрей, в конце получают бонус > в качестве заданного количества nop'ов для выравнивания (или тут-то и проблема, > чтобы точно посчитать это количество?). Те кто медленней (оставшиеся 25%) растворяется > и тонет в усредненном море. Осталось придумать как это все прикрутить в кодогенерацию компилерам...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	68. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (68), 10-Янв-24, 23:32
	Во время выполнения? Типа собрать метрику (mycrypto --getbias), и в условный /etc/timebias сохранить значение времени под который подгонять время выполнения, чтобы добить нужным количеством nop?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	76. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (-), 11-Янв-24, 15:48
	> Во время выполнения? Типа собрать метрику (mycrypto --getbias), и в условный /etc/timebias > сохранить значение времени под который подгонять время выполнения, чтобы добить нужным > количеством nop? Просто это получится довольно сложная и интрузивная фигня типа profile guided optimization. На которую в силу гиморности ее использования (почти) все как раз и забивают. Т.е. так в принципе можно - но это добавит прилично головняка и програмерам и авторам компилеров, и в силу первого на это все равно почти все забьют. Вон там Zig лучше придумал, но у него фича с багом оказалась. И совсем не факт что это единственный баг в такой фиче. На этом фоне аккуратно выписать критичный сегмент кода выглядит несколько более внушающим доверие мероприятием, как по мне.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	71. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (71), 11-Янв-24, 13:19
	>время зависит от железа Зависит, но мы сначала это время профилируем на локальной машине. >нагрузки Не зависит, если операция укладывается в промежуток между переключениями контекста и процессор не тротлится по температуре: во время кванта процессор полностью принадлежит потоку. >замедляем до неприличия А ты как хотел? Караван движется со скоростью самого медленного его участника. Допустим если оставим хоть 0.001% случаев, которые медленнее на порядок, чем медленнейший из 10% самых быстрых, то это всё равно будет утечка информации. >другие сторонние каналы вроде энергопотребления Out of scope. Требуют относительно локального доступа, то есть либо прогу на том же компе, либо спецоборудования на устройствах на силовой сети или ethernet-кабеле или матплате или usb-устройстве или звуковой карте.... Если такое происходит, то кража ключей шифрования является наименьшей из проблем, так как можно воровать сразу плэйнтексты.
	Ответить \| Правка \| К родителю #42 \| Наверх \| Cообщить модератору