forum.opennet.ru - "Уязвимость в реализациях постквантового алгоритма шифрования Kyber" (85)

"Уязвимость в реализациях постквантового алгоритма шифрования Kyber"

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

"Уязвимость в реализациях постквантового алгоритма шифрования Kyber"	+/–
Сообщение от opennews (??), 09-Янв-24, 20:54
В реализации алгоритма шифрования Kyber, победившего на конкурсе криптоалгоритмов, стойких к подбору на квантовом компьютере, выявлена уязвимость, допускающая проведение атак по сторонним каналам для воссоздания секретных ключей на основе измерения времени операций во время расшифровки предоставленного атакующим шифротекста. Проблема затрагивает как эталонную реализацию механизма инкапсуляции ключей CRYSTALS-Kyber KEM, так и многие сторонние библиотеки шифрования с поддержкой Kyber, в том числе библиотеку pqcrypto применяемую в мессенджере Signal... Подробнее: https://www.opennet.me/opennews/art.shtml?num=60405
Ответить \| Правка \| Cообщить модератору

Оглавление

Ну это в реализации, это не считово , Аноним (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]

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

Сообщение от Аноним (1), 09-Янв-24, 20:54

Ну это в реализации, это не считово.

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

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

Сообщение от InuYasha (??), 09-Янв-24, 21:03

Криптография - это такая область где скорость процессоров порой только мешает )

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

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

Сообщение от Карлос Сношайтилис (ok), 09-Янв-24, 22:30

При чем здесь скорость процессора?
Проблема в разном наборе операций в конкретном блоке кода из за оптимизаций компилятора. Возможность провести атаку будет и на медленном и на быстром проце.

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

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

Сообщение от qetuo (?), 11-Янв-24, 01:38

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

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

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

Сообщение от Аноним (81), 12-Янв-24, 08:03

как раз таки именно компилятор и имеет.
Авторы Kyber прекрасно знали, что деление уязвимо к атакам по таймингу. Но у них в оригинальном коде выполняется деление на константу, известную во время компиляции. Поэтому при компиляции с оптимизациями (а у них в Makefile безусловно задано -O3) никакой уязвимости не будет - компилятор заменит это деление нужными умножениями, сдвигами и т.п.
Проблема в том, что Бернштейн скомпилировал свой пример с -Os, там компилятор уже не стал оптимизировать это место, и получилась атака по таймингу. Ну а всякие сказочные криптоэксперты из cloudflare, aws и т.п. просто скопировали оригинальный код, не потрудившись разобраться в нем.

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

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

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

> Криптография - это такая область где скорость процессоров порой только мешает )
Вон то совершенно не зависит от скорости проца. Только от факапов с зависимостью времени счета от входных данных.
Как нормальный прогер делает допустим сравнение чего-то типа пароля?!
...

for (i = 0; i < 100; i++) {
  if input1[i] != input2[i] return FAIL;
}
Это к тому же эффективно - вместо обсчета от и до оно срубается на первом же несовпадении. Но вот в случае крипто и ко это превращается в проблему. Хаксор может побайтово менять ввод, и вот уже вместо 256^100 попыток на полный перебор - можно по одному байту угадывать, анализируя время выполнения. И длинный 100 байтовый пароль в хучшем случае - всего 256 * 100 == 25600 попыток на вынос офигенного стосимвольного пароля.
К скорости проца это отношения не имеет - в этом алго с точки зрения крипто фэйл - с любой скоростью проца. Выполнение этой конструкции на МК с 1 МГц тактовой частоты не делает этот код безопаснее. Он точно так же течет времянки и если атакующий может их мерять - упс!

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

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

Сообщение от Карлос Сношайтилис (ok), 10-Янв-24, 01:27

В данной уязвимости нет логического ветвления

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

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

Сообщение от penetrator (?), 10-Янв-24, 03:28

там есть деление с приватной частью ключа, которая выполняется с разной скоростью
какая разница есть там ветвление или нет
нужна только корреляция между обрабытывемымти секретными данными и временем обработки - ВСЁ

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

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

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

> В данной уязвимости нет логического ветвления
А какая разница какие там ветвления? В формулировке этого класса вулнов не присутствует требование ветвлений или чего-то еще. Все что для эксплуатации надо - чтобы время счета не было постоянным. И тогда если удалось измерять разницу в времянках и использовать это знание - вместо брутфорса (очень печального для длинных ключей/паролей) можно заняться более интересным побайтовым угадыванием неизвестной величины.
А вон то - иллюстративный пример как прострелить себе пятку. Его проблема не в ветвлении а в том что он вырубается на первом же несовпадении. Так что чем больше ключа мы угадали - тем дольше оно работает. Атака делается итеративно: подбирается input[0] -> работает чуть дольше -> подбирается input[1], еще немнго дольше, ... и так довольно быстро все 100 байтов :). Типа как в мувиках кольца на кодовом замке подгоняют с стетоскопом или камерой, только тут вместо них "секундомер".

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

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

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

а флагои ZF и CF в 0 или 1 разве за константное время?

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

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

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

>вместо обсчета от и до
а где пример трушного кода? ( nooby негодует)

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

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

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

На правах первой идеи пришедшей в голову...

...
flag = 0;
for (i = 0; i < 100; i++) {
  flag += (input1[i] ^ input2[i]); // input1[i] XOR input2[i] == 0 on match.
}
if (flag != 0) { FAIL! }
Заметьте:
1) в core loop нет условных бранчей, на процах с бранчпредиктором это важно
2) нет зависимости поведения от входных данных, всегда жует 100 байтов хоть что.
3) вердикт выносится после проверки всей чушки "от и до" а математика по всей площади одинаковая.
После этого момента времянки уже не важны - цель срубить итеративный анализ поведения побайтово. В этом смысле идея в том что core loop всегда должен работать одно и то же время. В нем по задумке только (регистровая) математика.
Disclaimer:
1) я не считаю себя профессиональным криптографом.
2) это иллюстративный псевдокод на тему.

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

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

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

Как вариант улучшить тело цикла:

...
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;
...

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

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

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

> flag = flag | (input1[i] != input2[i]);
Эм... != в принципе может быть рассмотрен как условный оператор, кто б его там знает что тот или иной компилер VS проц сделает, и насколько оно константное по времени на всех платформах. Я бы не стал закладываться на то что условный счет гарантировано постоянный по времени. Выглядит как потенциальный conditional.
Вон то - pure math, попытка откосплеить сравнение в стиле как это DJB любит в крипто примерно. Там нет никаких условных вещей в core loop. Только вычисления. Это на более-менее всех процах которые я знаю таки constant time штука. Времянки простых регистровых операций как правило одинаковые для любых данных, а доступ к памяти линейный и не зависит от входных данных, успеха или неуспеха. Core всегда делает одно и то же, а решение с conditional сегментом принимается уже потом - когда по частям угадывать уже не судьба.

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

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

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

Но |= всё равно логично использовать вместо +=, чтобы переполнение в ноль было принципиально невозможно.

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

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

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

> Но |= всё равно логично использовать вместо +=, чтобы переполнение в ноль
> было принципиально невозможно.
По своему прикольный ход мыслей, спасибо. Впрочем, переполнение можно рубануть и с другого бока. Скажем если максимум 100 символов как в примере - взять flag не менее u16, он никогда не переполнится "by design". Гарантировано математикой. Максимальная сумма 100 байтов - не более 25500. Это точно лезет в u16 или более крупное.
Более того - при написании программ что-то делающих с внешними данными этот момент нехило учитывать везде. Иначе однажды хаксор введет/пришлет не то что вы задумали. И тут окажется что логика отъезжает... и 50/50 что это - вулн, если это дает атакующему что-то полезное.

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

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

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

> Более того - при написании программ что-то делающих с внешними данными этот
> момент нехило учитывать везде. Иначе однажды хаксор введет/пришлет не то что
> вы задумали. И тут окажется что логика отъезжает... и 50/50 что
> это - вулн, если это дает атакующему что-то полезное.
p.s. кстати бонусом - кажется ЭТО еще и к rowhammer относительно устойчиво. Чтобы проехало - надо все биты в 0, а вот это для rowhammer'а уже неудобно, в общем фигу атакующим а не доступ :)

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

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

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

> 2) нет зависимости поведения от входных данных, всегда жует 100 байтов хоть
> что.
а зачем это, зачем делать константой количество циклов, в вашем примере главное не останавливаться при первом же несоответствии, а это вы решили путем прохода по всем битам и применения битовых операций. Остается только доказать, что эти битовые операции не коррелируют, то есть:
(0^0), (0^1), (1^0), (1^1) - константны по времени исполнения. Они могут быть константны по времени, а по всяким там энергетическим параметрам они будут такими же? Разве переходной процес из 0 -> 1 и 1 -> 0 константен?

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

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

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

> а зачем это, зачем делать константой количество циклов,
Чтобы не утекать никакой полезной информации атакующему. А вы что подумали?
> в вашем примере главное не останавливаться при первом же несоответствии,
В том примере главное - не утекать никакой полезной информации атакуюшему через тайминги операций. Чтобы атакующий занимался угадайкой на множестве порядка 256^100.
Этот маневр придумал не я, crypto_memcmp и проч примерно так делают.
> а это вы решили путем прохода по всем битам и применения битовых операций.
> Остается только доказать, что эти битовые операции не коррелируют, то есть:
> (0^0), (0^1), (1^0), (1^1) - константны по времени исполнения.
Проца у которого скорость XOR зависела бы от операндов в регистрах я еще не встречал. А доступ к памяти у этой штуки всегда одинаковый и никакой особой новой информации атакующему не утекает.
Судя по современному крипто - регистровая математика наиболее безопасная по части постоянных времянок штука в целом. Ну я и откосплеил известный мне маневр в стиле тех граждан.
> Они могут быть константны по времени, а по всяким там энергетическим параметрам
> они будут такими же?
Это уже другой аспект. Energy-aware coding != timing attack. От атакующего который может измерять потребление защититься куда сложнее, но это подразумевает другой уровень интрузива и доступа к системе, против него уже мало что удержится.
А времянки можно иной раз померять даже по сетевым или RF протоколам, ремотно. Или там сидючи на соседней VM с нужной. Поэтому фикс timing attacks намного приоритетнее, подставляет юзерей в довольно большом количестве сценариев на самом деле.
> Разве переходной процес из 0 -> 1 и 1 -> 0 константен?
Нет, однако прецизионный замер потребления проца - это уже довольно интрузивная и нишевая атака.
Я даже знаю кто это делает на коммерческой основе. Но они это делают в тепличных условиях, с специфичным недешевым шмотом, по специфичным поводам. Их полторы фирмы на всю планету с недешевыми расценками, и так вскрывают только очень некоторые вещи в довольно узком диапазоне допущений. А вон тот сервак к ним в лабу утащить на скоростной анализатор? Ну, это как минимум довольно неудобное требование для атакуюшего. Иногда - таки это опция. Но - именно иногда. Там где это реально важно, например, смарткарты, вообще-то этому уделяют внимание на уровне дизайна чипа. И то - с переменным успехом.

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

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

Сообщение от Sw00p aka Jerom (?), 11-Янв-24, 16:53

> Чтобы не утекать никакой полезной информации атакующему. А вы что подумали?
1) значение константное, уже утекло знание, что input или равен меньше этой константы
2) это значит, необходимо "расширять" как input1, так и input2, чтобы не было всяких "выходов за границы"
3) параллельно надо "думать", чем же заполнять расширенное "пространство", тоже константными значениями?
> В том примере главное - не утекать никакой полезной информации атакуюшему через
> тайминги операций. Чтобы атакующий занимался угадайкой на множестве порядка 256^100.
if (flag != 0) { FAIL! }
такая конструкция порождает новый вид bypass атак, когда можно всякими манипуляциями воздействовать на ячейку памяти и изменить ее значение, подобно этой:
https://www.opennet.me/opennews/art.shtml?num=60334
а вот пример про константность и "добавки":
https://www.opennet.me/opennews/art.shtml?num=59848

> Этот маневр придумал не я, crypto_memcmp и проч примерно так делают.
ок, ну так давайте разберем все плюсы и минусы данных решений.
> Проца у которого скорость XOR зависела бы от операндов в регистрах я
> еще не встречал.
частичто соглашусь, если он собран из универсального гейта, но где гарантии, что оба "инпута" на элемент приходят "одновременно", опять таки тут всё зависит от гранулярности, разница есть всегда, и кореляция (не только по времени) будет всегда, ибо процесс 0 -> 1 и 1 -> 0 "разный".

> Судя по современному крипто - регистровая математика наиболее безопасная по части постоянных
> времянок штука в целом. Ну я и откосплеил известный мне маневр
> в стиле тех граждан.
в случае с тайминг атаками опасность предоставляют переходы, тем самым делая тайминг атаки логическими атаками.
> Energy-aware coding != timing attack.
принцип один, найти кореляцию между "входом и выходом"
> Нет, однако прецизионный замер потребления проца - это уже довольно интрузивная и
> нишевая атака.
по миганию светодиода восстанавливали
https://www.opennet.me/opennews/art.shtml?num=59291
> Там где это реально важно, например, смарткарты, вообще-то этому уделяют внимание на уровне дизайна чипа. И то - с переменным успехом.
там вообще беда, в софтверных реализациях можно как-то закрывать вектора атак.

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

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

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

> 1) значение константное, уже утекло знание, что input или равен меньше этой константы
Атакующий чаще всего знает лимиты. И даже если это новое знание, круто, знаете что надо угадать из 256^100. Сильно помогло?
> 2) это значит, необходимо "расширять" как input1, так и input2, чтобы не
> было всяких "выходов за границы"
Можно просто зарубать ввод длиннее оговоренного максимума. А если это ключи какие, они могут быть фиксированой длины by design. Иллюстрация не о том.
> 3) параллельно надо "думать", чем же заполнять расширенное "пространство",
Нужность этого зависит от того что это было, к затыканию таймингов не относится.
> if (flag != 0) { FAIL! } такая конструкция порождает новый вид bypass атак,
> когда можно всякими манипуляциями воздействовать на ячейку памяти и изменить
> ее значение, подобно этой:
1) ЭТОТ код относительно устойчив к rowhammer, до кучи. Лучше чем if (flag != 0) {AUTH OK!} у тех позорников, где любой бит сбить и в дамках. А тут удачи подогнать flag в именно ноль, любое иное == FAIL.
2) Это локальная временная "горячая" переменная, скорее всего в регистре. Его rowhammer-ом, как бы это... а в сях так то можно и "register" захинтить.
3) Если кто гасит систему rowhammer, он много чего еще сможет.
4) На допустим MCU вообще DRAM нет :P
> ок, ну так давайте разберем все плюсы и минусы данных решений.
Очевидный трабл - менее эффективно, но за ту оптимизацию - воздается вулном.
> частичто соглашусь, если он собран из универсального гейта,
У ALU логика обычно шириной с регистр и ему похрен что за биты.
> но где гарантии, что оба "инпута" на элемент приходят "одновременно",
Это от структуры системы очень зависит. Даже если cache hit vs cache miss сделает джиттер - это вроде бы не привязано к содержимому input1 или input2, т.е. нового инфо о их содержимом атакующий с этого не получает.
Ключевой вопрос: "что это дает атакуюшему?".
> будет всегда, ибо процесс 0 -> 1 и 1 -> 0 > "разный".
Регистровые операции как правило за 1 такт современными процами молотятся и там пофиг какие биты куда. На электрическом уровне, конечно, разницу бывает видно но это уже иной класс атак.
> в случае с тайминг атаками опасность предоставляют переходы,
Не только. В примере который я привел трабл в том что алго срубается за разное время в зависимости от (не)совпадений (==зависимость от содержимого). Это не столько про переходы сколько про неудачную логическую структуру алго. Он будет уязвим даже на проце где бранчи за постоянное время и не были проблемой. Логично что я для илллюстрации проблемы взял злой пример, уязвимый везде, плюс-минус :).
> тем самым делая тайминг атаки логическими атаками.
Тайминг атаки - это атаки накопления информации о пароле/ключе по сторонним каналам. Переходы и связанные утечки и проблемы - частный случай. Subset.
> принцип один, найти кореляцию между "входом и выходом"
В чем-то да, НО детали и применимость здорово отличаются. Электрические измерения требуют очень плотный физический доступ к атакуемой системе. Надолго. А тайминг атаки можно зачастую эксплуатировать ремотно по сети/RF или с соседней виртуалки. Куда более слабое требование.
> по миганию светодиода восстанавливали
Это тоже требует физический доступ, надолго и атака глючная.
> там вообще беда, в софтверных реализациях можно как-то закрывать вектора атак.
Вон то - одна из ипостасей. Я иллюстрировал ее, а не что-нибудь иное. Разумеется это не гарантирует решения всех проблем человечества и информационной безопасности.

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

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

Сообщение от Аноним (79), 11-Янв-24, 20:22

> Это от структуры системы очень зависит. Даже если cache hit vs cache miss сделает
> джиттер - это вроде бы не привязано к содержимому input1 или input2, т.е.
> нового инфо о их содержимом атакующий с этого не получает.
Кстати говоря вспомнил что DJB в своих алго любит такое для относительно мелких блоков в криптоалго конопатить более радикально: он копирует input в локальные переменные, работает с ними там, а потом - копирует обратно в output. В случае крипто преобразований вместо вердикта - output еще есть, чуть иной случай но идею показывает.

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

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

Сообщение от Sw00p aka Jerom (?), 12-Янв-24, 23:34

> конопатить более радикально
конопатить лучше на асм, что там наконопатит компилятор языка Х - "тайна", а проверять то что наконопатил компилятор и пыхтеть над тем, чтобы он сконопатил то, что нужно - неблагодарное дело, как по мне, лучше сразу конопатить на асм.

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

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

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

> конопатить лучше на асм,
Убивает портабельность и читаемость кода -> something to avoid в общем случае.
И я лично использую x86-64, Cortex-M, Cortex-A, MIPS и RISCV(32 и 64). Мне что, 6 версий алго выписывать? Нафиг надо, скажем прямо. А если взять еще AVR какой и чего поэкзотичнее, мм... сколько там кода то на майнтенанс уже? Оно мне надо? Поэтому подбирают конструкции где и на си компилеру сложно сделать что-то не то.
> что там наконопатит компилятор языка Х - "тайна",
Он сделает то же что и человек, только кроссплатформенно. То действо ведет к локальной переменной с всегда одинаковой предысторией "мы ее только что заполнили" и сбивает неопределенность от кеша соответственно.
> а проверять то что наконопатил компилятор и пыхтеть над тем, чтобы
> он сконопатил то, что нужно - неблагодарное дело, как по мне,
> лучше сразу конопатить на асм.
Вот вы этим и занимайтесь, а мне 6-7 а то и больше вариантов кода вместо 1 майнтайнить... ну вы поняли.

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

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

Сообщение от Sw00p aka Jerom (?), 14-Янв-24, 16:57

> Оно мне надо?
ну вот, собственно ясно.

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

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

Сообщение от Аноним (-), 14-Янв-24, 23:26

>> Оно мне надо?
> ну вот, собственно ясно.
Ну дык. Мне асмовый выхлоп прочекать там где оно реально важно, 1 раз на версию компилера - проще чем пачку ассемблерных простынок колупать. А основной повод юзать си - портабельность кода, внезапно.
И возможность отладить код на мощном компе под крутой инструментацией типа asan/ubsan и перенести 1 в 1 на мк знаюя что код переживает fuzzing рандомным входом и проч. На МК с этим значительно душнее например. ASAN туда вообще не лезет, а UBSAN только на минималочках. Ну а кус ассемблерного кода - инвалидирует все результаты проверок.
Так что если вы считаете что вон то отличный курс действий - вот и показывайте личным примером HOW TO для начала. Если вы выложите пару годных криптолиб под свободной лицензией, взяв вон то на себя - окей, я подумаю о использовании либы. А если вопрос в том чтобы я выписывал с дюжи ну разных сегментов кода делающих ОДНО И ТО ЖЕ, при том 95% вероятности что бинарь в итоге этой камасутры будет чуть ли не бит в бит - ненене, Девид Блейн.

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

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

Сообщение от Sw00p aka Jerom (?), 14-Янв-24, 23:41

> Ну дык.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
что за "нечитабельность"? можете пояснить зачем это изменение приняли?

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

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

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

> что за "нечитабельность"? можете пояснить зачем это изменение приняли?
Ответил в другом топике где вы спросили то же самое.
Struct в си - они как бы почти то что надо, но специфицированы комитетом придурков из рук вон плохо, особенно в части align и проч. Это тот редкий случай когда C может перестать быть тонким shim над железом и отумничает. Без стандартных средств контроля за этим, только нестандартными extensions.
При желании сделать апи и данные реально структурированными и читаемыми - иногда, таки, за это может воздаться, не совсем очевидным образом. Но не ассемблерщикам про это вещать - там такого вообще нет. Поэтому код на асме это эталоннейшее спагетти.

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

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

Сообщение от Sw00p aka Jerom (?), 15-Янв-24, 02:46

> Но не ассемблерщикам про это вещать - там такого вообще нет. Поэтому код
> на асме это эталоннейшее спагетти.
лол, кек - выходит это "ассемблерщикам" надо понимать и помнить, что есть память, регистры, кеши всякие, бранч-предикшены какие-то? разве не "могучий" наш великий избавитель от всякой ереси - "эталоннейшее спагетти"?

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

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

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

Ваш код содержит синтаксические ошибки. Кроме того - вот оно! Если массивы были выделены динамически (скорее всего, это так), будет вероятная утечка памяти. И причем тут C?

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

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

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

> Ваш код содержит синтаксические ошибки.
man "псевдокод", он не обязан совпадать с существующимм ЯП, только иллюстрировать топик.
> Кроме того - вот оно! Если массивы были выделены динамически (скорее всего, это так),
> будет вероятная утечка памяти. И причем тут C?
FYI, даже если бы это был C,
1) Динамическая аллокация конструкции на 100 байтов это вообще очень спорная затея. Это зазря тормозит все, и создает риск прострела пяток.
2) (Де)аллокация массивов прямо в функции проверки пароля - ооочень странная идея, мягко говоря. Извините, а caller этой функции вообще в курсе, что вы 0 умная клава, и уже деаллоцировали ему пароль? Или он тогда use after free сделает?
В общему этого гражданина к крипто вообще и си в частности не подпускать на пушечный выстрел, он даже пароль прочекать не могет :)

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

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

Сообщение от Коммуникатор (?), 12-Янв-24, 09:12

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

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

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

Сообщение от Аноним (34), 12-Янв-24, 09:09

> Криптография - это такая область где скорость процессоров порой только мешает )
Криптография - это такая область, где скорость процессоров компенсирует неудачные реализации алгоритмов )

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

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

Сообщение от Аноним (-), 09-Янв-24, 21:40

Я сталкивался с тем, что в геометрии деления - ноно, всё что угодно только не деления, но выясняется, что в криптографии тоже. :)

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

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

Сообщение от anonymous (??), 10-Янв-24, 00:50

причем тут геометрия - устройство деления всегда дольше отрабатывает чем например умножения, ибо надо как бы предсказывать результат от старших разрядов, то есть гораздо больше логических операций.

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

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

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

В геометрии с делением проблема не со скоростью, а с тем, что деление не является равномерно-непрерывной функцией на своей области определения. Это было бы не важно, если бы компьютер считал в вещественных числах, но он считает во float.

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

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

Сообщение от Аноним_2го_Рода (?), 10-Янв-24, 20:14

Наркоман. Действительные числа никак не помогают справляться с точками разрыва

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

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

Сообщение от Витюшка (?), 09-Янв-24, 21:51

Уже исправлена в 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
}
Вот это уровень! Это очень круто, если будет реализовано. Вот что я считаю безопасным языком программирования.

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

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

Сообщение от Аноним (8), 09-Янв-24, 23:11

Ради интереса, кроме шифрования это где-нибудь полезно?

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

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

Сообщение от Аноним (9), 09-Янв-24, 23:23

при майнинге битка. гарантированно будешь обнаруживать блок каждую секунду

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

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

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

Отвечу за анонима выше, возможно real-time что-нибудь?

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

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

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

а чем алгоритм, с асимптотой O(n) допустим, отличается в реалтайие и не реалтайие?

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

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

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

В реалтайме нас может волновать точные предсказуемые времянки. И иногда отработать быстрее чем ожидалось не меньший фэйл чем не успеть к дедлайну.
Только представь что тебе открывали дверь приводом на 30 секунд, например, в лифте, ты привык к этому, спокойно заходишь - и тут тебя вдруг хренакс дверями по бокам! Кодер заоптимизировал - теперь за 5 секунд таймаут отрабатывает! Вот и втискивайся за 5 секунд теперь, или вот те дверью по бочине, на выбор! :)

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

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

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

А где оно есть, если ишью еще открыта?

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

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

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

> Уже исправлена в Zig. Интересно как безопасные языки решают эту проблему :))
> В zig например есть такая issue https://github.com/ziglang/zig/issues/1776  для гарантированных константных операций в блоке кода.
Только в zig ее поправили как и в остальных реализациях, изменив выполняемые операции.

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

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

Сообщение от penetrator (?), 10-Янв-24, 03:48

так как и в сях, заменив деление умножением явно

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

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

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

А как это поможет, если в делении ветвлений нет, а скорость выполнения разная?
Будет иллюзия безопасности, типа посмотрите у нас все в timeconst блоке, а по факту - нет.

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

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

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

>Интересно как безопасные языки решают эту проблему
если ты про раст, то очень просто: допускают CVE, получают репорт, исправляют, над исправленным местом пишут комментарий "// SAFETY: this is safe". Не то что в этих ваших устаревших сишках с плюсами, понимать надо.

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

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

Сообщение от Ivan_83 (ok), 09-Янв-24, 23:27

DJB всё не даёт покоя что кто то пользуется алгоритмами которые не он создал.
Вот пусть по сетке продемонстрирует, в стандартных юзкейсах типа вебсервера с TLS, а то на стенде можно много всего насочинять.

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

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

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

> DJB всё не даёт покоя что кто то пользуется алгоритмами которые не он создал.
Покажи ему уязвимости в его алго в ответ, хренли.
> Вот пусть по сетке продемонстрирует, в стандартных юзкейсах типа вебсервера с TLS,
>  а то на стенде можно много всего насочинять.
С RC4 такие господа уже довыступались - им показали так что WEP теперь секунд за 30 выносится. Вот тоже господа с увереной рожей рассказывали что мол небольшой bias конечно фи, но как бы продемонстрируйте... блин, а вот продемонстрировали! И правы оказались - параноики, считавшие что это фи.
"Безопасность бывает 2 уровней - high и нехай".

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

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

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

Что оригинальный код, что патч (https://github.com/pq-crystals/kyber/commit/dda29cc63af72198...) выглядят ужасными хаками. Лучше держаться подальше от такого кода.

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

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

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

Почему это хак?

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

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

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

Потому что сишный код имеет очень далёкое отношение к тому, что реально будет выполнено на железе. Сейчас не семидесятые. Все эти хитрые ужимки и прыжки с магией битовых операций нивелируются любым обновлением компилятора или архитектуры, каждый из который перекроит код как захочет.

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

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

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

Нужно на ассемблере писать? А нет, там не пойдет, там же спекулятивные вычисления и всякие Meltdown/Spectre. Надо отдельную плату паять на транзисторах и лампах? Нет, там ЭМ излучение и жужжание дросселей. А-а-а, все фигня переходим на http://

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

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

Сообщение от Аноним (45), 10-Янв-24, 09:53

А memory-mapped IO как до сих пор работает? В сях есть возможность сказать компилятору: "если я приказал делать бессмысленные вещи шаг за шагом, как написано, то бери и делай" - как раз, чтобы MMIO можно было реализовать.
https://godbolt.org/z/f73GrThK3

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

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

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

И какое отношение имеет дизассемблерный псевдокод к тому что исполнится на железе? Кстати хороший пример, процессор просто посмотрит на состояние кеша и регистров и оптимизирует это. На x86 даже все эти регистры типа eax уже виртуальные, ибо внутри там что-то RISC-подобное крутится с переименованием реальных регистров. Это всё фейк, призрак древних времён.

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

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

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

Этот код имеет прямое отношение к:
> нивелируются любым обновлением компилятора
.
> посмотрит на состояние кеша
Ну да, для MMIO на умном процессоре этого маловато, хотя на x86 всё-таки есть дремучие способы отключить кэширование для региона памяти и есть S/L/MFENCE.
Но чего мы хотим и что ты в комменте, начинающем ветку, предлагаешь в качестве альтернативы?

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

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

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

> Потому что сишный код имеет очень далёкое отношение к тому,
Булшит. Как правило си это довольно тонкий shim над железом. И аккуратно сделанная математика - таки, вот, прокатывает.
> что реально будет выполнено на железе. Сейчас не семидесятые.
> Все эти хитрые ужимки и прыжки с магией битовых операций нивелируются
> любым обновлением компилятора или архитектуры, каждый из который
> перекроит код как захочет.
В общем случае не перекроит. Хотя для сильно специфичных случаев есть например volatile.

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

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

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

> Как правило си это довольно тонкий shim над железом.
Вот это точно булшит. Сам придумал, или вдохновился классической книжкой Кернига и Ричи 1978 года выпуска?

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

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

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

>> Как правило си это довольно тонкий shim над железом.
> Вот это точно булшит. Сам придумал, или вдохновился классической книжкой Кернига и
> Ричи 1978 года выпуска?
Вдохновился... програмингом фирмварей МК например. Я одним си Cortex M с ноля поднял, даже "startup" сделав сями сам себе. Представляете - zero ASM в системе?! А таки работает (потом конечно пару команд все ж захочется, иначе IRQ быстро разрешать-запрещать душно, и еще пару аспектов).
Но вы конечно можете мне рассказать за си как оно :) x86 конечно хтонь ужасная и там все заметно сложнее - в том числе и за счет кеширования. Но даже там "device mem" таки без кеширования засетаплена. И если что - mem-mapped HW сделан так... специально для того чтобы им было удобно управлять из си, представляете?! В сях регистры железа просто объявляют volatile - и оптимизации компилера идут нафих. Там все довольно честно получается и это работает.
Кстати минимум который я использую это C99.

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

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

Сообщение от Аноним (81), 12-Янв-24, 08:46

это строго доказанные математические формулы, не беспокойся

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

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ообщить модератору

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

Сообщение от Бывалый смузихлёб (?), 10-Янв-24, 08:53

> криптоалгоритмов, стойких к подбору на квантовом компьютере
Окей, устойчивый к квантовым штукам
> Таким образом, на основании изменения времени операций
> можно получить представление о характере используемых
> при делении данных
Они мерили время выполнения на квантовом компе или на обычном ?
На обычном - никто ничего не обещал
> Для успешного проведения атаки необходимо,
[ завоняло израильскими учоными-грантоедами ]
> чтобы задаваемый атакующим шифротекст обрабатывался
> с использованием одной и той же пары ключей
> и чтобы можно было точно измерить время выполнения операции
> чтобы можно было точно измерить время выполнения операции
Подумаешь, мелочь. Ерунда. Для многоядерного проца то, у которого потоков больше чем ядер, со спекулятивным выполнением и обвесом из со-процессоров.
Всего лишь точно регулярно измерять время выполнения операций и чтобы ничего другого не менялось. Ну точь-в-точь израильские уч.ные.
Они что, в гугол переехали или это очередная их операция "под другим флагом". Всех кто поприличней решили тоже обмазать )

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

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

Сообщение от Аноним (37), 10-Янв-24, 09:21

Квантовых компьютеров не существует! Их придумали лишь для того чтобы гребсти бабло и получать гранты. А постквантовые алгоритмы делают вместо уже надёжных проверенных классических вот для таких "уязвимостей"! (шутка)

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

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

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

Напишите это на картонке, повесьте на шею и ходите так по улицам. Найдете единомышлеников, обещаю.

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

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

Сообщение от voiceofreason (?), 10-Янв-24, 13:07

Что мешает в таких случаях просто вставлять в каждый цикл случайную задержку?

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

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

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

А потом получить узвимость из-за предсказания "алгоритма случайных чисел" который эту задержку генерирует)

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

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

Сообщение от ИмяХ (ok), 10-Янв-24, 19:48

А потом героически исправить эту уязвимость и получить за это премию.

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

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

Сообщение от Sw00p aka Jerom (?), 11-Янв-24, 13:39

почему уязвимость, скорее бекдор

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

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

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

> Что мешает в таких случаях просто вставлять в каждый цикл случайную задержку?
Тут мешает некомпетентность коментаторов опеннета - которые видимо не в курсе что качественная генерация случайных чисел весьма отдельный топик.
А некачественная... благодаря ей большинство вафельниц у хомячков типа вас крякается очень сильно быстрее чем вы там себе это представляли. Нет, ваш дофигасимвольный уникальный пароль вам не поможет. И хреновый рандом играет определенную роль в этом шоу.

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

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

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

> Уязвимость остаётся неисправленной в библиотеках:
rustpq/pqcrypto/pqcrypto-kyber (5 января исправление добавлено в libsignal, но в самом pqcrypto-kyber уязвимость пока не исправлена).
rust, фу таким быть! а ещё его безопасным называют! rust будь как zig !

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

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

Сообщение от ааноним (?), 10-Янв-24, 21:04

Так не честно - алгоритм для квантового компьютера, а код выполнили на распи 2.

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

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

Сообщение от Sw00p aka Jerom (?), 11-Янв-24, 13:36

не для, а против :)

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

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

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

Партнёры:

Хостинг:

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

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

1. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+8 +/–
Сообщение от Аноним (1), 09-Янв-24, 20:54
Ну это в реализации, это не считово.
Ответить \| Правка \| Наверх \| Cообщить модератору

3. "Уязвимость в реализациях постквантового алгоритма шифрования..."	–4 +/–
Сообщение от InuYasha (??), 09-Янв-24, 21:03
Криптография - это такая область где скорость процессоров порой только мешает )
Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Уязвимость в реализациях постквантового алгоритма шифрования..."	–2 +/–
	Сообщение от Карлос Сношайтилис (ok), 09-Янв-24, 22:30
	При чем здесь скорость процессора? Проблема в разном наборе операций в конкретном блоке кода из за оптимизаций компилятора. Возможность провести атаку будет и на медленном и на быстром проце.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	81. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+1 +/–
	Сообщение от Аноним (81), 12-Янв-24, 08:03
	как раз таки именно компилятор и имеет. Авторы Kyber прекрасно знали, что деление уязвимо к атакам по таймингу. Но у них в оригинальном коде выполняется деление на константу, известную во время компиляции. Поэтому при компиляции с оптимизациями (а у них в Makefile безусловно задано -O3) никакой уязвимости не будет - компилятор заменит это деление нужными умножениями, сдвигами и т.п. Проблема в том, что Бернштейн скомпилировал свой пример с -Os, там компилятор уже не стал оптимизировать это место, и получилась атака по таймингу. Ну а всякие сказочные криптоэксперты из cloudflare, aws и т.п. просто скопировали оригинальный код, не потрудившись разобраться в нем.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+5 +/–
	Сообщение от Аноним (-), 10-Янв-24, 00:12
	> Криптография - это такая область где скорость процессоров порой только мешает ) Вон то совершенно не зависит от скорости проца. Только от факапов с зависимостью времени счета от входных данных. Как нормальный прогер делает допустим сравнение чего-то типа пароля?! ... for (i = 0; i < 100; i++) { if input1[i] != input2[i] return FAIL; } Это к тому же эффективно - вместо обсчета от и до оно срубается на первом же несовпадении. Но вот в случае крипто и ко это превращается в проблему. Хаксор может побайтово менять ввод, и вот уже вместо 256^100 попыток на полный перебор - можно по одному байту угадывать, анализируя время выполнения. И длинный 100 байтовый пароль в хучшем случае - всего 256 * 100 == 25600 попыток на вынос офигенного стосимвольного пароля. К скорости проца это отношения не имеет - в этом алго с точки зрения крипто фэйл - с любой скоростью проца. Выполнение этой конструкции на МК с 1 МГц тактовой частоты не делает этот код безопаснее. Он точно так же течет времянки и если атакующий может их мерять - упс!
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	17. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+1 +/–
	Сообщение от Карлос Сношайтилис (ok), 10-Янв-24, 01:27
	В данной уязвимости нет логического ветвления
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	39. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (39), 10-Янв-24, 10:18
	> В данной уязвимости нет логического ветвления А какая разница какие там ветвления? В формулировке этого класса вулнов не присутствует требование ветвлений или чего-то еще. Все что для эксплуатации надо - чтобы время счета не было постоянным. И тогда если удалось измерять разницу в времянках и использовать это знание - вместо брутфорса (очень печального для длинных ключей/паролей) можно заняться более интересным побайтовым угадыванием неизвестной величины. А вон то - иллюстративный пример как прострелить себе пятку. Его проблема не в ветвлении а в том что он вырубается на первом же несовпадении. Так что чем больше ключа мы угадали - тем дольше оно работает. Атака делается итеративно: подбирается input[0] -> работает чуть дольше -> подбирается input[1], еще немнго дольше, ... и так довольно быстро все 100 байтов :). Типа как в мувиках кольца на кодовом замке подгоняют с стетоскопом или камерой, только тут вместо них "секундомер".
	Ответить \| Правка \| К родителю #17 \| Наверх \| Cообщить модератору


	27. "Уязвимость в реализациях постквантового алгоритма шифрования..."	–1 +/–
	Сообщение от Sw00p aka Jerom (?), 10-Янв-24, 03:39
	а флагои ZF и CF в 0 или 1 разве за константное время?
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	30. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Sw00p aka Jerom (?), 10-Янв-24, 04:01
	>вместо обсчета от и до а где пример трушного кода? ( nooby негодует)
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	41. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (39), 10-Янв-24, 11:24
	На правах первой идеи пришедшей в голову... ... flag = 0; for (i = 0; i < 100; i++) { flag += (input1[i] ^ input2[i]); // input1[i] XOR input2[i] == 0 on match. } if (flag != 0) { FAIL! } Заметьте: 1) в core loop нет условных бранчей, на процах с бранчпредиктором это важно 2) нет зависимости поведения от входных данных, всегда жует 100 байтов хоть что. 3) вердикт выносится после проверки всей чушки "от и до" а математика по всей площади одинаковая. После этого момента времянки уже не важны - цель срубить итеративный анализ поведения побайтово. В этом смысле идея в том что core loop всегда должен работать одно и то же время. В нем по задумке только (регистровая) математика. Disclaimer: 1) я не считаю себя профессиональным криптографом. 2) это иллюстративный псевдокод на тему.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	47. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (39), 10-Янв-24, 13:05
	> flag = flag \| (input1[i] != input2[i]); Эм... != в принципе может быть рассмотрен как условный оператор, кто б его там знает что тот или иной компилер VS проц сделает, и насколько оно константное по времени на всех платформах. Я бы не стал закладываться на то что условный счет гарантировано постоянный по времени. Выглядит как потенциальный conditional. Вон то - pure math, попытка откосплеить сравнение в стиле как это DJB любит в крипто примерно. Там нет никаких условных вещей в core loop. Только вычисления. Это на более-менее всех процах которые я знаю таки constant time штука. Времянки простых регистровых операций как правило одинаковые для любых данных, а доступ к памяти линейный и не зависит от входных данных, успеха или неуспеха. Core всегда делает одно и то же, а решение с conditional сегментом принимается уже потом - когда по частям угадывать уже не судьба.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	59. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (-), 10-Янв-24, 19:31
	> Но \|= всё равно логично использовать вместо +=, чтобы переполнение в ноль > было принципиально невозможно. По своему прикольный ход мыслей, спасибо. Впрочем, переполнение можно рубануть и с другого бока. Скажем если максимум 100 символов как в примере - взять flag не менее u16, он никогда не переполнится "by design". Гарантировано математикой. Максимальная сумма 100 байтов - не более 25500. Это точно лезет в u16 или более крупное. Более того - при написании программ что-то делающих с внешними данными этот момент нехило учитывать везде. Иначе однажды хаксор введет/пришлет не то что вы задумали. И тут окажется что логика отъезжает... и 50/50 что это - вулн, если это дает атакующему что-то полезное.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	77. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (-), 11-Янв-24, 16:08
	> Более того - при написании программ что-то делающих с внешними данными этот > момент нехило учитывать везде. Иначе однажды хаксор введет/пришлет не то что > вы задумали. И тут окажется что логика отъезжает... и 50/50 что > это - вулн, если это дает атакующему что-то полезное. p.s. кстати бонусом - кажется ЭТО еще и к rowhammer относительно устойчиво. Чтобы проехало - надо все биты в 0, а вот это для rowhammer'а уже неудобно, в общем фигу атакующим а не доступ :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Sw00p aka Jerom (?), 10-Янв-24, 20:54
	> 2) нет зависимости поведения от входных данных, всегда жует 100 байтов хоть > что. а зачем это, зачем делать константой количество циклов, в вашем примере главное не останавливаться при первом же несоответствии, а это вы решили путем прохода по всем битам и применения битовых операций. Остается только доказать, что эти битовые операции не коррелируют, то есть: (0^0), (0^1), (1^0), (1^1) - константны по времени исполнения. Они могут быть константны по времени, а по всяким там энергетическим параметрам они будут такими же? Разве переходной процес из 0 -> 1 и 1 -> 0 константен?
	Ответить \| Правка \| К родителю #41 \| Наверх \| Cообщить модератору


	75. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (-), 11-Янв-24, 15:37
	> а зачем это, зачем делать константой количество циклов, Чтобы не утекать никакой полезной информации атакующему. А вы что подумали? > в вашем примере главное не останавливаться при первом же несоответствии, В том примере главное - не утекать никакой полезной информации атакуюшему через тайминги операций. Чтобы атакующий занимался угадайкой на множестве порядка 256^100. Этот маневр придумал не я, crypto_memcmp и проч примерно так делают. > а это вы решили путем прохода по всем битам и применения битовых операций. > Остается только доказать, что эти битовые операции не коррелируют, то есть: > (0^0), (0^1), (1^0), (1^1) - константны по времени исполнения. Проца у которого скорость XOR зависела бы от операндов в регистрах я еще не встречал. А доступ к памяти у этой штуки всегда одинаковый и никакой особой новой информации атакующему не утекает. Судя по современному крипто - регистровая математика наиболее безопасная по части постоянных времянок штука в целом. Ну я и откосплеил известный мне маневр в стиле тех граждан. > Они могут быть константны по времени, а по всяким там энергетическим параметрам > они будут такими же? Это уже другой аспект. Energy-aware coding != timing attack. От атакующего который может измерять потребление защититься куда сложнее, но это подразумевает другой уровень интрузива и доступа к системе, против него уже мало что удержится. А времянки можно иной раз померять даже по сетевым или RF протоколам, ремотно. Или там сидючи на соседней VM с нужной. Поэтому фикс timing attacks намного приоритетнее, подставляет юзерей в довольно большом количестве сценариев на самом деле. > Разве переходной процес из 0 -> 1 и 1 -> 0 константен? Нет, однако прецизионный замер потребления проца - это уже довольно интрузивная и нишевая атака. Я даже знаю кто это делает на коммерческой основе. Но они это делают в тепличных условиях, с специфичным недешевым шмотом, по специфичным поводам. Их полторы фирмы на всю планету с недешевыми расценками, и так вскрывают только очень некоторые вещи в довольно узком диапазоне допущений. А вон тот сервак к ним в лабу утащить на скоростной анализатор? Ну, это как минимум довольно неудобное требование для атакуюшего. Иногда - таки это опция. Но - именно иногда. Там где это реально важно, например, смарткарты, вообще-то этому уделяют внимание на уровне дизайна чипа. И то - с переменным успехом.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	78. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Sw00p aka Jerom (?), 11-Янв-24, 16:53
	> Чтобы не утекать никакой полезной информации атакующему. А вы что подумали? 1) значение константное, уже утекло знание, что input или равен меньше этой константы 2) это значит, необходимо "расширять" как input1, так и input2, чтобы не было всяких "выходов за границы" 3) параллельно надо "думать", чем же заполнять расширенное "пространство", тоже константными значениями? > В том примере главное - не утекать никакой полезной информации атакуюшему через > тайминги операций. Чтобы атакующий занимался угадайкой на множестве порядка 256^100. if (flag != 0) { FAIL! } такая конструкция порождает новый вид bypass атак, когда можно всякими манипуляциями воздействовать на ячейку памяти и изменить ее значение, подобно этой: https://www.opennet.me/opennews/art.shtml?num=60334 а вот пример про константность и "добавки": https://www.opennet.me/opennews/art.shtml?num=59848 > Этот маневр придумал не я, crypto_memcmp и проч примерно так делают. ок, ну так давайте разберем все плюсы и минусы данных решений. > Проца у которого скорость XOR зависела бы от операндов в регистрах я > еще не встречал. частичто соглашусь, если он собран из универсального гейта, но где гарантии, что оба "инпута" на элемент приходят "одновременно", опять таки тут всё зависит от гранулярности, разница есть всегда, и кореляция (не только по времени) будет всегда, ибо процесс 0 -> 1 и 1 -> 0 "разный". > Судя по современному крипто - регистровая математика наиболее безопасная по части постоянных > времянок штука в целом. Ну я и откосплеил известный мне маневр > в стиле тех граждан. в случае с тайминг атаками опасность предоставляют переходы, тем самым делая тайминг атаки логическими атаками. > Energy-aware coding != timing attack. принцип один, найти кореляцию между "входом и выходом" > Нет, однако прецизионный замер потребления проца - это уже довольно интрузивная и > нишевая атака. по миганию светодиода восстанавливали https://www.opennet.me/opennews/art.shtml?num=59291 > Там где это реально важно, например, смарткарты, вообще-то этому уделяют внимание на уровне дизайна чипа. И то - с переменным успехом. там вообще беда, в софтверных реализациях можно как-то закрывать вектора атак.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	79. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (79), 11-Янв-24, 19:56
	> 1) значение константное, уже утекло знание, что input или равен меньше этой константы Атакующий чаще всего знает лимиты. И даже если это новое знание, круто, знаете что надо угадать из 256^100. Сильно помогло? > 2) это значит, необходимо "расширять" как input1, так и input2, чтобы не > было всяких "выходов за границы" Можно просто зарубать ввод длиннее оговоренного максимума. А если это ключи какие, они могут быть фиксированой длины by design. Иллюстрация не о том. > 3) параллельно надо "думать", чем же заполнять расширенное "пространство", Нужность этого зависит от того что это было, к затыканию таймингов не относится. > if (flag != 0) { FAIL! } такая конструкция порождает новый вид bypass атак, > когда можно всякими манипуляциями воздействовать на ячейку памяти и изменить > ее значение, подобно этой: 1) ЭТОТ код относительно устойчив к rowhammer, до кучи. Лучше чем if (flag != 0) {AUTH OK!} у тех позорников, где любой бит сбить и в дамках. А тут удачи подогнать flag в именно ноль, любое иное == FAIL. 2) Это локальная временная "горячая" переменная, скорее всего в регистре. Его rowhammer-ом, как бы это... а в сях так то можно и "register" захинтить. 3) Если кто гасит систему rowhammer, он много чего еще сможет. 4) На допустим MCU вообще DRAM нет :P > ок, ну так давайте разберем все плюсы и минусы данных решений. Очевидный трабл - менее эффективно, но за ту оптимизацию - воздается вулном. > частичто соглашусь, если он собран из универсального гейта, У ALU логика обычно шириной с регистр и ему похрен что за биты. > но где гарантии, что оба "инпута" на элемент приходят "одновременно", Это от структуры системы очень зависит. Даже если cache hit vs cache miss сделает джиттер - это вроде бы не привязано к содержимому input1 или input2, т.е. нового инфо о их содержимом атакующий с этого не получает. Ключевой вопрос: "что это дает атакуюшему?". > будет всегда, ибо процесс 0 -> 1 и 1 -> 0 > "разный". Регистровые операции как правило за 1 такт современными процами молотятся и там пофиг какие биты куда. На электрическом уровне, конечно, разницу бывает видно но это уже иной класс атак. > в случае с тайминг атаками опасность предоставляют переходы, Не только. В примере который я привел трабл в том что алго срубается за разное время в зависимости от (не)совпадений (==зависимость от содержимого). Это не столько про переходы сколько про неудачную логическую структуру алго. Он будет уязвим даже на проце где бранчи за постоянное время и не были проблемой. Логично что я для илллюстрации проблемы взял злой пример, уязвимый везде, плюс-минус :). > тем самым делая тайминг атаки логическими атаками. Тайминг атаки - это атаки накопления информации о пароле/ключе по сторонним каналам. Переходы и связанные утечки и проблемы - частный случай. Subset. > принцип один, найти кореляцию между "входом и выходом" В чем-то да, НО детали и применимость здорово отличаются. Электрические измерения требуют очень плотный физический доступ к атакуемой системе. Надолго. А тайминг атаки можно зачастую эксплуатировать ремотно по сети/RF или с соседней виртуалки. Куда более слабое требование. > по миганию светодиода восстанавливали Это тоже требует физический доступ, надолго и атака глючная. > там вообще беда, в софтверных реализациях можно как-то закрывать вектора атак. Вон то - одна из ипостасей. Я иллюстрировал ее, а не что-нибудь иное. Разумеется это не гарантирует решения всех проблем человечества и информационной безопасности.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (79), 11-Янв-24, 20:22
	> Это от структуры системы очень зависит. Даже если cache hit vs cache miss сделает > джиттер - это вроде бы не привязано к содержимому input1 или input2, т.е. > нового инфо о их содержимом атакующий с этого не получает. Кстати говоря вспомнил что DJB в своих алго любит такое для относительно мелких блоков в криптоалго конопатить более радикально: он копирует input в локальные переменные, работает с ними там, а потом - копирует обратно в output. В случае крипто преобразований вместо вердикта - output еще есть, чуть иной случай но идею показывает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	86. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Sw00p aka Jerom (?), 12-Янв-24, 23:34
	> конопатить более радикально конопатить лучше на асм, что там наконопатит компилятор языка Х - "тайна", а проверять то что наконопатил компилятор и пыхтеть над тем, чтобы он сконопатил то, что нужно - неблагодарное дело, как по мне, лучше сразу конопатить на асм.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	88. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (-), 14-Янв-24, 15:29
	> конопатить лучше на асм, Убивает портабельность и читаемость кода -> something to avoid в общем случае. И я лично использую x86-64, Cortex-M, Cortex-A, MIPS и RISCV(32 и 64). Мне что, 6 версий алго выписывать? Нафиг надо, скажем прямо. А если взять еще AVR какой и чего поэкзотичнее, мм... сколько там кода то на майнтенанс уже? Оно мне надо? Поэтому подбирают конструкции где и на си компилеру сложно сделать что-то не то. > что там наконопатит компилятор языка Х - "тайна", Он сделает то же что и человек, только кроссплатформенно. То действо ведет к локальной переменной с всегда одинаковой предысторией "мы ее только что заполнили" и сбивает неопределенность от кеша соответственно. > а проверять то что наконопатил компилятор и пыхтеть над тем, чтобы > он сконопатил то, что нужно - неблагодарное дело, как по мне, > лучше сразу конопатить на асм. Вот вы этим и занимайтесь, а мне 6-7 а то и больше вариантов кода вместо 1 майнтайнить... ну вы поняли.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	89. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Sw00p aka Jerom (?), 14-Янв-24, 16:57
	> Оно мне надо? ну вот, собственно ясно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	90. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (-), 14-Янв-24, 23:26
	>> Оно мне надо? > ну вот, собственно ясно. Ну дык. Мне асмовый выхлоп прочекать там где оно реально важно, 1 раз на версию компилера - проще чем пачку ассемблерных простынок колупать. А основной повод юзать си - портабельность кода, внезапно. И возможность отладить код на мощном компе под крутой инструментацией типа asan/ubsan и перенести 1 в 1 на мк знаюя что код переживает fuzzing рандомным входом и проч. На МК с этим значительно душнее например. ASAN туда вообще не лезет, а UBSAN только на минималочках. Ну а кус ассемблерного кода - инвалидирует все результаты проверок. Так что если вы считаете что вон то отличный курс действий - вот и показывайте личным примером HOW TO для начала. Если вы выложите пару годных криптолиб под свободной лицензией, взяв вон то на себя - окей, я подумаю о использовании либы. А если вопрос в том чтобы я выписывал с дюжи ну разных сегментов кода делающих ОДНО И ТО ЖЕ, при том 95% вероятности что бинарь в итоге этой камасутры будет чуть ли не бит в бит - ненене, Девид Блейн.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	91. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Sw00p aka Jerom (?), 14-Янв-24, 23:41
	> Ну дык. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... что за "нечитабельность"? можете пояснить зачем это изменение приняли?
	Ответить \| Правка \| К родителю #90 \| Наверх \| Cообщить модератору


	92. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (-), 15-Янв-24, 01:45
	> что за "нечитабельность"? можете пояснить зачем это изменение приняли? Ответил в другом топике где вы спросили то же самое. Struct в си - они как бы почти то что надо, но специфицированы комитетом придурков из рук вон плохо, особенно в части align и проч. Это тот редкий случай когда C может перестать быть тонким shim над железом и отумничает. Без стандартных средств контроля за этим, только нестандартными extensions. При желании сделать апи и данные реально структурированными и читаемыми - иногда, таки, за это может воздаться, не совсем очевидным образом. Но не ассемблерщикам про это вещать - там такого вообще нет. Поэтому код на асме это эталоннейшее спагетти.
	Ответить \| Правка \| К родителю #91 \| Наверх \| Cообщить модератору


	93. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Sw00p aka Jerom (?), 15-Янв-24, 02:46
	> Но не ассемблерщикам про это вещать - там такого вообще нет. Поэтому код > на асме это эталоннейшее спагетти. лол, кек - выходит это "ассемблерщикам" надо понимать и помнить, что есть память, регистры, кеши всякие, бранч-предикшены какие-то? разве не "могучий" наш великий избавитель от всякой ереси - "эталоннейшее спагетти"?
	Ответить \| Правка \| К родителю #92 \| Наверх \| Cообщить модератору


	34. "Уязвимость в реализациях постквантового алгоритма шифрования..."	+/–
	Сообщение от Аноним (34), 10-Янв-24, 06:59
	Ваш код содержит синтаксические ошибки. Кроме того - вот оно! Если массивы были выделены динамически (скорее всего, это так), будет вероятная утечка памяти. И причем тут C?
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору