Если использовать обозначение (t, n) для пороговой подписи, то это в 99% статей означает, что кворум - t + 1 участников, а не t. А ещё Feldman VSS в чистом виде - уязвимый алгоритм, который лучше не использовать. Мне, если честно, не очень понятна цель статьи. Она не дает никакой конкретики. Как будто студент-двоечник в ночь перед сдачей доклада по-быстрому перевел статью, но вот формулы прочитать не успел, а доклад сдавать надо.
Но абсолютной защиты безусловно не существует, а значит, любой алгоритм или ключ можно взломать.
Загуглите "абсолютно стойкий шифр".
при получении достаточно готового к практическому применению квантового компьютера все пароли, которые существуют, можно будет просто подобрать за вполне вменяемое время
При хранении паролей используются алгоритмы симметричной криптографии, для которой квантовый компьютеры дают только квадратичное ускорение, делая проблему легче но не решаемой в общем случае.
Вообще очень грустно. Как у этого потока сознания с ошибками, с такими утверждениями, как что легковесная криптография становится эффективной, когда она написана на легковесных скриптовых языках, с написанным нейросетью анекдотом, вот со всем этим - 24 голоса за? Это ещё и лучшее за неделю в хабе Криптология.
"Легковесный стримовый шифр" - нет стримовых шифров. Есть поточные. В зависимости от конфигурации в AES используются не только 128-битные ключи. И что Вы понимаете под уровнем безопасности? Что это за шкала?
В Linkedin как-то мелькал пост с перепиской с их HR, когда у сосискателя спрашивали, по-прежнему ли у него на теле тату. Видимо, думали, что сведет ради них.
Да, необработанные исключения - это оракул багов, который есть в каждой программе. Проблема в том, что он очень слабый. Например, есть такая уязвимость off-by-one. Когда программа промахивается и записывает на один байт больше, чем надо. Например, неправильно посчитали, куда на ставить ноль в строке в C. Поскольку у кучи есть определенная гранулярность, то в большинстве случаев такая перезапись не затронет какие-либо метаданные. Только неиспользуемый кусок выделенного чанка. Оракулы багов нужны, чтобы сразу обнаруживать такие проблемы, потому что и они иногда приводят к эксплуатации. В Windows для этого включают специальную кучу.
В случае бинарного фаззинга всё немного сложнее, взять инструмент, чтобы он сразу заработал, в большинстве случаев не получится. Под Windows можно использовать WinAFL, TinyAFL, Jackalope, есть и другие варианты. Но придется реверсить. Да и MS Office тяжелый таргет. Ну и в случае исполняемых файлов не получается сделать такие же хорошие оракулы багов. Например, слежение за кучей начинает использовать намного больше памяти, а детектировать неправильное чтение буфера на стеке очень сложно, ведь нет информации о границах переменных.
Они нужны, чтобы разработчики и компании могли понимать риски использования фреймворка/продукта и конкретной его версии. Или Вы что-то другое имели в виду?
Да, так можно. Но если всё равно надо оповещать вендора, то, мне кажется, лучше всё-таки в начале обратиться к нему. И вот 2 дня — это, видимо, стандартный вариант, но в моем случае они просто не отвечали. Мб мой почтовый адрес в спам-фильтр попал каким-то образом.
Всего было 10 команд и ответили только пара из них. Точно эксплуатировали RSA для доса и плохие параметры. Причем одна команда ломала другие команды, которые выставили количество вершин в 50, потому что граф был достаточно связный.
Да, стандартные пользовательские гипервизоры себя не скрывают. Но их переделывают специально, чтобы избежать детекта. И в них надо детектировать свойства ОС, оборудования, иногда специальные MSR. А метод в статье почти не привязан к ПО
Ну там и не будет такая большая разница, а после cpuid можно включать. Не очень получается так обнаружить, иначе бы все малварщики его использовали, чтобы уйти от песочниц. Ещё особенность, что из 3 уровня привилегий нельзя точно узнать, какая должна быть разница у rdtsc. Возможно система дает вашему процессу очень мало вычислительной мощности, почти не переключает на него исоплнение. В итоге обнаружение превращается в гонку гипервизора против детектора.
Такое ощущение, что переводили промптом. Snyk оказался охранной компанией, а Klarna - криптостартапом.
Если использовать обозначение (t, n) для пороговой подписи, то это в 99% статей означает, что кворум - t + 1 участников, а не t. А ещё Feldman VSS в чистом виде - уязвимый алгоритм, который лучше не использовать.
Мне, если честно, не очень понятна цель статьи. Она не дает никакой конкретики. Как будто студент-двоечник в ночь перед сдачей доклада по-быстрому перевел статью, но вот формулы прочитать не успел, а доклад сдавать надо.
Загуглите "абсолютно стойкий шифр".
При хранении паролей используются алгоритмы симметричной криптографии, для которой квантовый компьютеры дают только квадратичное ускорение, делая проблему легче но не решаемой в общем случае.
Автор просто пиарит свой продукт https://blog.passwork.pro/author/garakh/
Автор просто свою компанию пиарит https://blog.passwork.pro/author/garakh/
Вообще очень грустно. Как у этого потока сознания с ошибками, с такими утверждениями, как что легковесная криптография становится эффективной, когда она написана на легковесных скриптовых языках, с написанным нейросетью анекдотом, вот со всем этим - 24 голоса за? Это ещё и лучшее за неделю в хабе Криптология.
Да тут вся статья один сплошной анекдот.
"Легковесный стримовый шифр" - нет стримовых шифров. Есть поточные.
В зависимости от конфигурации в AES используются не только 128-битные ключи.
И что Вы понимаете под уровнем безопасности? Что это за шкала?
В Linkedin как-то мелькал пост с перепиской с их HR, когда у сосискателя спрашивали, по-прежнему ли у него на теле тату. Видимо, думали, что сведет ради них.
Да, необработанные исключения - это оракул багов, который есть в каждой программе. Проблема в том, что он очень слабый. Например, есть такая уязвимость off-by-one. Когда программа промахивается и записывает на один байт больше, чем надо. Например, неправильно посчитали, куда на ставить ноль в строке в C. Поскольку у кучи есть определенная гранулярность, то в большинстве случаев такая перезапись не затронет какие-либо метаданные. Только неиспользуемый кусок выделенного чанка. Оракулы багов нужны, чтобы сразу обнаруживать такие проблемы, потому что и они иногда приводят к эксплуатации. В Windows для этого включают специальную кучу.
Если хотите попробовать пофаззить какой-то исполняемый файл на Windows, попробуйте https://github.com/linhlhq/TinyAFL или https://github.com/googleprojectzero/Jackalope . Но лучше начать с чего-то попроще Word.
В случае бинарного фаззинга всё немного сложнее, взять инструмент, чтобы он сразу заработал, в большинстве случаев не получится. Под Windows можно использовать WinAFL, TinyAFL, Jackalope, есть и другие варианты. Но придется реверсить. Да и MS Office тяжелый таргет. Ну и в случае исполняемых файлов не получается сделать такие же хорошие оракулы багов. Например, слежение за кучей начинает использовать намного больше памяти, а детектировать неправильное чтение буфера на стеке очень сложно, ведь нет информации о границах переменных.