The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

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

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


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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру