Зонды АНБ в Линукс

Уязвимости могут базироваться не только на коде, но и на математической модели алгоритма.

это и есть код.

Ох, жеж, лол. (с)

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

Против словаря да, против RT нет.

К слову, не столько соль, сколько количество итераций.

Криптопанкам на заметку:

cryptsetup --iter-time=100000

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

Ну да, древние римляне тоже так считали.

и что? правильно считали, Империя закатилась не из-за того, что римляне плохими технологами были, а как раз наоборот.

Против словаря да, против RT нет.

и как ты собрался солёные хеши обращать?

К слову, не столько соль, сколько количество итераций.

wtf?

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

ага. Например WEP.

и как ты собрался солёные хеши обращать?

man rainbow table и чем они отличаются от сырых данных типа словарей + соль.

wtf?

Уходи.

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

Где эта разница? Джон Смит из АНБ может это сделать скрыв самостоятельно или под крышей АНБ, а Абу ибн-Хаттаб не может скрыв под крышей министерства просвещения Ирана, или Иван Петров просто скрыв в надежде написать вирусню и рулить миром из однокомнатной квартиры в чертаново?

У Ивана Петрова скорее всего нет достаточных ресурсов для этого. Как умственных, так и вычислительных. И он не может выдвинуть соответствующую технологию в качестве стандарта.

The original intent of salting was primarily to defeat pre-computed rainbow table attacks

У Ивана Петрова скорее всего нет достаточных ресурсов для этого.

Для чего? Забыть сказать что там есть дырка? Такие же самые как и у АНБ.

И он не может выдвинуть соответствующую технологию в качестве стандарта.

Advanced Encryption Standard - based on the Rijndael cipher[4] developed by two Belgian cryptographers, Joan Daemen and Vincent Rijmen. AES has been adopted by the U.S. government and is now used worldwide.

Два бельгийца держат АНБ за яйца.

Serpent - designed by Ross Anderson, Eli Biham, and Lars Knudsen. Трое гиков из США, Израиля и Германии. В АНБ не работают.

...

Да куча всего разработанная международными командами или конкретными гиками или отличными от АНБ конторами. Без разницы.

И он не может выдвинуть соответствующую технологию в качестве стандарта.

http://en.wikipedia.org/wiki/Advanced_Encryption_Standard_process

если дыра есть, то она будет обнаружена не только врагом, но и тем, кто её опубликует.

А откуда возьмётся тот, кто её опубликует? Он по либастралу получит сообщение об атаке только потому, что это опенсорс?

Дело всё в том, что дыра, это всегда баг, и большинство пользователей OpenSource заинтересованно в исправлении этого бага, и не заинтересованны в его эксплуатации.

Ну конечно, ведь в опенсорсе баги появляются в багтрекере мгновенно и мгновенно же закрываются.

На локалхостах достаточно простых прав

Зависит от данных на этом локалхосте.

salting was primarily to defeat pre-computed rainbow table attacks

А если соль тоже известна?

wpa/wpa2 используют в качестве соли ESSID, и все соли давно посчитаны для всяких стандартных 'dlink', 'D-LINK', 'TP-LINK', 'home'.

Это, я имел в виду в первую очередь.

Так же софт, в котором в алгоритмах установлено нечто вроде брать соль из логина/имени/whatever else :) в итоге получается не такой уж и большой словарь этой соли.

и как ты собрался солёные хеши обращать?

man rainbow table и чем они отличаются от сырых данных типа словарей + соль.

т.е. у тебя нет ответа на поставленный вопрос?

если дыра есть, то она будет обнаружена не только врагом, но и тем, кто её опубликует.

А откуда возьмётся тот, кто её опубликует? Он по либастралу получит сообщение об атаке только потому, что это опенсорс?

ну говорю-же: дыра это баг. Баг может быть обнаружен и сам по себе. Обычно так и бывает.

Ну конечно, ведь в опенсорсе баги появляются в багтрекере мгновенно и мгновенно же закрываются.

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

На локалхостах достаточно простых прав

Зависит от данных на этом локалхосте.

не зависит. Если данные ценные, то нужно использовать шифрование, а не права SELinux. Я надеюсь ты догадаешься почему.

у тебя нет ответа на поставленный вопрос?

Распиши-ка вопрос подробнее.

Уязвимости могут базироваться не только на коде, но и на математической модели алгоритма.

это и есть код.

Ну ты морозишь :)

Хватит уже паранойи. У АНБ есть масса других, более удобных «отверстий» для зонда, чем SELinux. Или вы тут все думаете, что они кроме бэкдоров ничем не занимаются?

Баг может быть обнаружен и сам по себе. Обычно так и бывает.

Поэтому статические анализаторы находят *сотни* багов в крупных опенсорс-проектах.

Ибо ничто им не мешает там появляться и закрываться.

Тебе показать баги с возрастом больше трёх лет?

Если данные ценные, то нужно использовать шифрование, а не права SELinux. Я надеюсь ты догадаешься почему.

Шифрование не имеет отношения к SELinux. SELinux позволяет ограничить ущерб от каждого бага, попутно ломая большинство попыток воспользоваться local root. Он помогает при remote-уязвимостях в первую очередь. Шифрование нужно совершенно для других целей, если кто-то успешно использовал remote-уязвимость, то у него доступ к уже расшифрованным (тобой) данным.

https://lists.mindrot.org/pipermail/openssh-unix-dev/2003-December/020011.html

tl;dr: защита от time side channel attacks

вино и женщин

пфф, «вино и сыр» (с) же. В самый раз для инспекции на пару лет.

пфф, «вино и сыр» (с) же.

Вино и сыр ведёт к забану на лоре. А как же без женщин и без лора?

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

т.е. у тебя нет ответа на поставленный вопрос?

При помощи радужных таблиц по идее можно восстановить пароли, зашифрованные с солью, и если на выходе мы получим строку соль + пароль, то из неё вероятно можно восстановить и пароль (ну например если результат будет «x%9fQ&Rnikto ne uznaet», то пароль скорее всего узнают...). Однако соль всё-таки помогает против радужных таблиц: увеличивается количество возможных символов и длина зашифрованных данных, что требует больших ресурсов для создания радужных таблиц, они получаются большего размера и (или) требуют большего времени для восстановления пароля с их использованием. Если соль очень длинная, то создание соответствующих радужных таблиц может оказаться просто нереальной задачей. Кроме того, по идее восстановленные по хэшу данные могут не совпадать с оригиналом, а какая польза взломщику от того, что у него есть строка, хэш которой совпадает с хэшем пароля с солью? Он не сможет использовать её для авторизации. Он получит другой пароль для другого значения соли... Вот если бы соли не было, он бы мог воспользоваться восстановленным паролем вместо оригинального, и сервер разницы бы не заметил (хэш ведь одинаковый...).

Не знаю, может уже ответили... Не мой текст:

fake.pw_passwd используется как фиктивная запись для несуществующих в /etc/passwd пользователей. Нужно это для нормализации времени вычислений, чтобы избежать timing-атак, которые могут определить существование логинов на основе оценки времени реакции сервера. Для недоверяющих документации можно легко проследить логику использования fake.pw_passwd в коде.