И ведь найти эту ошибку самому практически невозможно: в режиме отладки вызов memset работает нормально.
Обычно те, кто пишет код криптографических алгоритмов уже знают об этом и вызывают эту функцию через volatile указатель :) А как вы определяете, что массив это действительно sensitive data, а не обычный массив? По названию переменной?
Вообще от подобного могли бы помочь Certificate Transparency и аналог CAA. CT давала бы возможность увидеть все сертификаты всех УЦ, а в аналоге CAA я бы запретил выдавать мне подпись всеми УЦ, кроме 1-2, которым я доверяю.
Жаль, что регулятор не в курсе технологий, которые уже давно придуманы
Было бы здорово, если бы в статье разобрали пример эксплуатации именно первого листинга (с "==="). Я пробовал как-то проэксплуатировать "==" в простом сервисе на Flask, запущенном локально. Мне, четно говоря, не удалось отследить разницу во времени.
AVX просто заточен под floating-point. В Intel Intrinsics Guide можно посмотреть все инструкции из этого набора. Про SSE4.1 vs SSSE3 — да, там почти нет разницы (небольшая разница в реализации Blake2B) и возможно я удалю верcию для SSE4.1.
Доступ к глобальной памяти (которой является RAM) для всех дорогой — и для CPU тоже.
Все верно, но в серверных CPU есть большой L3 кэш, который позволяет все ускорить.
Есть такая штука, как локальная память, разделяемая внутри кластера потоковых процессоров на GPU. Время доступа — несколько тактов. И кэши данных у GPU тоже есть, просто они распределены и меньшего объёма.
А где-то утверждается, что кешей или локальной памяти в GPU нет?
Пример с использованием чтений/записей по случайным адресам взят из bcrypt, который использует всего 4кб.
Бенчмарки bcrypt CPU vs GPU убедительно доказывают, что чтения/записи 4 байт по случайным адресам в регионе 4кб сильно снижают эффективность GPU.
Наверняка сами знаете, что в некоторых моделях GPU даже 4кб быстрой памяти на поток это роскошь.
SIMD вычисления — это то, ради чего GPU были сделаны.
Просто неудачная фраза, смысл в том, что алгоритмы оптимизированы под x64 с учетом наборов инструкций типа SSE2…
Но это надо собирать бинарь внутри контейнера, тащить в продакшн компилятор и т.д., при этом ждать, пока все соберется при запуске контейнера (будет большая задержка на старте).
Несколько бинарей или dlopen будут работать, но это же тот же runtime CPU dispatching, только чуть по-другому.
Вопрос OpenMP vs pthread это скорее холивар вроде «ручное управление потоками» vs «что-то, что управляет потоками за тебя». В данном конкретном случае мне просто было удобнее использовать OpenMP.
«Дерайвить» в каком-то смысле и есть хеширование :) Я догадываюсь к чему вы клоните, но в вашей схеме все равно присутствует master password и алгоритм хеширования паролей scrypt.
Тут я хочу сослаться на разработчиков алгоритмов и материалы PHC. Эта конструкция используется в Yescrypt (pwxform transformation, слайды 1, 2), Argon2 (спецификация, страница 15 второй абзац снизу), Lyra2. Честно признаться, сам я с FPGA и ASIC каждый день не работаю :)
Чуть быстрее, но скорее за счет того, что в референсной реализации нет оптимизаций для Blake2B. К сожалению, конкретных цифр нет под рукой.
Разбираться с процессором на этапе деплоя можно, но это не всегда удобно (например, при деплое Docker-контейнеров). Тут многое зависит от вашей системы деплоя. Для нас просто runtime CPU dispatching это самое удобное, что можно сделать.
Обычно те, кто пишет код криптографических алгоритмов уже знают об этом и вызывают эту функцию через volatile указатель :) А как вы определяете, что массив это действительно sensitive data, а не обычный массив? По названию переменной?
Вообще от подобного могли бы помочь Certificate Transparency и аналог CAA. CT давала бы возможность увидеть все сертификаты всех УЦ, а в аналоге CAA я бы запретил выдавать мне подпись всеми УЦ, кроме 1-2, которым я доверяю.
Жаль, что регулятор не в курсе технологий, которые уже давно придуманы
Все верно, но в серверных CPU есть большой L3 кэш, который позволяет все ускорить.
А где-то утверждается, что кешей или локальной памяти в GPU нет?
Пример с использованием чтений/записей по случайным адресам взят из bcrypt, который использует всего 4кб.
Бенчмарки bcrypt CPU vs GPU убедительно доказывают, что чтения/записи 4 байт по случайным адресам в регионе 4кб сильно снижают эффективность GPU.
Наверняка сами знаете, что в некоторых моделях GPU даже 4кб быстрой памяти на поток это роскошь.
Просто неудачная фраза, смысл в том, что алгоритмы оптимизированы под x64 с учетом наборов инструкций типа SSE2…
Негативный фидбек тоже важен для нас
Несколько бинарей или dlopen будут работать, но это же тот же runtime CPU dispatching, только чуть по-другому.
Подписывать целиком HTTP запрос?
Разбираться с процессором на этапе деплоя можно, но это не всегда удобно (например, при деплое Docker-контейнеров). Тут многое зависит от вашей системы деплоя. Для нас просто runtime CPU dispatching это самое удобное, что можно сделать.