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

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

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

если забыть про солнечный свет, вино и женщин на пару лет, то можно проинспектировать.

Уж лучше зонд в задницелинуксе.

Good, good, let the paranoia flow through you.

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

0-day базируется на коде, код открыт.

нужно обладать сравнимыми интеллектуальными ресурсами

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

А ещё вот или вот, вообще такого много.

ну сделай свой селинукс. На локалхостах достаточно простых прав, а если у тебя Over9000 админов, то что ты ноешь-то? АНБ всё правильно сделали — зпилили свою уютную систему безопасности, и выложили её публично. Лучше, если её публично поломают, и сразу починят, чем как в венде, где на одной и той же дыре можно наживаться годами, если не наглеть, и вести себя тихо. С open source вероятность такого сценария ниже, а время жизни дыры меньше, ибо если дыра есть, то она будет обнаружена не только врагом, но и тем, кто её опубликует.

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

Потому баги в открытом софте исправляются ещё ДО того, как кто-то догадается, как его использовать как уязвимость — достаточно потенциальной угрозы.

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

За это время накоммитят новых дыр.

0-day базируется на коде, код открыт.

Уязвимости могут базироваться не только на коде, но и на математической модели алгоритма. Атаки по словарю, дифференциальный криптоанализ и др. не требуют уязвимостей в коде, тем не менее, позволяют ломать некоторые шифры. Если ты имеешь эффективные методы для нескольких популярных современных систем шифрования, ты контролируешь весь мир.

Ты мне доказываешь преимущество OpenSource? LOL. Зачем я читаю твой комментарий? Зачем ты писал его? Я вам о принципиальной уязвимости алгоритма, вы мне про код. С кодом всё может быть отлично, но сам метод защиты данных может быть уязвим. Вы можете иметь отличную реализацию шифра Цезаря, без единого бага.

A он всегда так. Общается как бот, лишь бы последнее слово было за ним. Делает вид что что-то отвечает, но часто его комментарий никак не относится к тому, на который он отвечал.

Сейчас в тред должна ворваться переписка на crypto.me по поводу интеловского блоба в RdRand;

но и на математической модели алгоритма

На pgpru давно ходит мысль что Шнайер хочет захватить мир :)

Сейчас в тред должна ворваться переписка на crypto.me по поводу интеловского блоба в RdRand;

Эта?

Эта?

Она самая.

точный комментарий, хорошо сформулировал
плюсую

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

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

Атаки по словарю, дифференциальный криптоанализ и др. не требуют уязвимостей в коде

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

Если быдлокодер это не предусмотрел — его вина.

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

Дак вот, если есть закрытые методы криптоанализа

вряд-ли. Просто всё уже придумано, и вряд-ли есть какие-то принципиально новые методы.

всё уже придумано

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

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

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

Короче пока код открыт - можешь не дергаться. Большего достигнуть нельзя.

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

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

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

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

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

вино и женщин

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

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

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

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

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

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