> Ну в общем особо отвечать я уже устал.Да и я, поэтому если и буду сюда заходить то в фоне и не быстро.
> К консенсусу мы не придём -- разное мировоззрение.
Возможно. Но мое мировоззрение - основано на анализе имеющихся фактов и простых соображениях - что шифрование должно быть простым в применении, при том - достаточно надежным и безграбельным. И оправдывать ожидания пользователей а не подкладывать свинью всем кто не ракетный инженер.
> обязан) использовать для обмена ключами/аутентификации и на это всё. Остальной протокол
> -- его родной и независимый от TLS.
С чего мало радости, поскольку в типовых случаях он как раз всем этим пользуется, ну и зависит от огроменной сложной либы (с кучей багов). И вообще, полноценно работать может только так. Без PKI вокруг TLS он, как я понимаю, вообще 1 на 1 только с 1 участником может коммуницировать. А чтоб более чем с 1 узлом линк держать - извольте TLS во все поля, PKI развернуть и по всем связанным с этими затеями граблями попрыгать.
> cредство повышения порога входа для этого.
Выкиньте из головы маркетинговый булшит. Сдернуть видео надо лишь 1 раз - квалифицированному перцу, недостатка в которых нет. А остальные качнут на торентах или где там еще. С порогом вхождения около ноля.
> Если деньги затраченные на DRM будут значительно меньше денег
> затраченных на преодоление порога входа дешифрования видео
Какие затраты? Релизеры снимут DRM'о чтобы померяться длиной с коллегами-конкурентами или just because they can, юзеры вообще нахаляву скачают. А те кто это фуфло клепал - как минимум тратили деньги на зарплаты дармоедам, занимающихся имитацией бурной деятельности. Оплатят этот балаган, разумеется, лохи честно покупающие DRMленый контент. Которых DRM и будет иметь. За их же счет.
> -- DRM выполнил свою роль успешно.
Все что он может успешно делать - обломать легитимного юзера лишний раз да зря тражирить системные ресурсы.
> Вы не понимаете суть для чего DRM нужен,
Я понимаю чего хотят м...ки которые его применяют и понимаю что они сами же и виноваты в результирующем расцвете пиратства. Неправильно это - гадить на голову пользователям за их же деньги. А потом эти фашисты еще и думают что путем пи..лей пиратам дескать что-то поменяется. DRMщики - кучка подлых фашистов, не более.
> мол это типа чтобы не дать пиратам вообще возможность копирования.
Не вижу никаких проблем от DRM у пиратов. Проблемы от DRM бывают только у лохов, которые честно заплатили за контент, чтобы их потом в благодарность - фэйсом об тэйбл.
> В Linux качественный пул энтропии?
Сделан более-менее разумно и люди которые его делают - более-менее разбираются в вопросе. В частности в два счета зарубив инициативы напрямую подать выход хардварного генератора апликухам, в отличие от OpenSSLщиков. Компетентность специалистов - она вот в таких вот мелочах проявляется.
> Честно говоря, вы меня насмешили. Видители TLS то ещё дерьмо, а /dev/random в Linux годный?
Не /dev/random а /dev/urandom, для начала.
> Особо дальше комментировать не буду уж эту тему.
Ну как бы ваше право.
> Касательно закрытых (проприетарных) систем -- это всё очевидно что там даже не будет PRNG.
Там может быть все что угодно.
> Чтобы сгенерировать KDF(password, salt) вам salt надо взять рандомную. Без рандома качественного никуда.
Salt как таковой там нужен лишь чтобы сорвать предвычисленные радужные таблицы. В этом месте имеет смысл очень медленный KDF, желательно memory hard. Ну типа scrypt с приличными параметрами. Юзерь пару секунд подождет, а вот атакующие скоростью типа 1 вариант в 2 секунды на тех же мощностях - будут очень недовольны. И даже радужные таблицы они задолбаются генерировать.
> А я хоть раз говорил вообще про совместимость понятий безопасности и закрытых систем?
Тогда я не понимаю какой смысл был меня лечить что в проприетарных системах вон то может работать плохо?
> Если у вас открытая система где всё от и до подчинаяется вам,
> то это идёт врозь вашей боязни AES.
Вы что, совсем глупый, или застряли на уровне использования компьютеров как в DOS? На какой-то моей системе, где ядро подчиняется мне, я однако ж могу например дать логин юзеру (непривилегированному), рулящему вон тем сервисом для его нужд. Вот только мне как-то не в кассу чтобы при этом была возможность тихой сапой умыкнуть ключи.
> разница какой алгоритм и вообще что вы будете делать, раз априори
> никакой безопасности не будет.
Опять же - уровень неподконтрольности бывает разный. И степень интрузивности атакующих. Пристраивание на тот же проц позволяет очень чистую, "косвенную" атаку, когда не остается никаких следов в атакуемой системе и нет возможности это внятно детектировать. При этом я даже не узнаю что у меня вообще сперли ключи - никаких аномалий нигде не будет. Это очень плохой класс атак на мой вкус.
> или у вас всё подконтрольное и открытое -- тогда не ясно что вы паритель о AES и прочем.
Даже если у меня все открытое - это не значит что я не могу например немного поделиться ресурсами. Но немного поделиться ресурсами - не синоним "сделать проходной двор". Где каждый будет брать под ковриком вообще все ключи, вместо ключа от своего номера.
> Касательно ГОСТ: в отличии от DES/AES и прочих, в нём разрешено применять
> собственные S-box-ы, а не заранее рассчитанные в которых могут быть лазейки.
Есть только 1 загвоздка: ничего не говорится о том как это влияет на криптостойкость и есть ли "плохие" или "хорошие" комбинации. Не говоря о том что схема со "своими" боксами не подвергалась криптоанализу вообще. Как там насчет количества беляшей? Ну или почему в госте такое донкихотство считается допустимым? Он чем-то такой особенный? Вы готовы дать математическое доказательство что любая комбинация S-box'ов будет одинаково стойкая? Или чего?
> Похоже вы не следите за новостями чтобы делать такие заявления.
Вы в вашем праве посрамить меня, приведя пруфлинки на известных криптографов которые заявят что кэши, мол, не проблема. Только чур в NIST не посылать, эти уже показали что они из себя представляют с их стандартизацией Dual EC.
> И как всегда преувеличиваете масштабы.
Только потому что в криптографии не бывает мелочей.
> Отказ одной команды в одном whitepaper это не отказ криптографов.
Это не одной команды и не в одном whitepaper. Это в целом тенденция такая. Большинство криптографов не тyпые и пробему с кэшом признали. И соответственно, таблицы не используют.
> А это уже явная клевета и враньё. Замечу что я член FSF, FSFE и EFF -- так что вы зря
> называете меня человеком который "заботится" о проприетарных системах
Тогда я не понимаю какой был смысл меня лечить о заботе о пользователях в этих системах. Я не вижу как им можно сильно помочь, при том что их может иметь все системное окружение.
> Вы вроде тот человек который сказал что не бывает мелочей в криптографии?
Именно. Поэтому если вы можете прикопаться к мелочам - это хороший признак. Если по делу.
> А я отчётливо вижу что вы сравниваете один из кирпичиков используемых
> в хэш-функции с симметричным блочным шифров.
Потому что по факту это тоже алгоритм шифрования. Хотя частично соглашусь - сравнивать напрямую несколько коряво. Но идея была показать эволюцию хода мысли криптографов, а не что-либо еще. Заметьте: алгоритмы шифрования на основе Skein будут основаны на этом core и там тоже не будет таблиц. DJB - тоже пришел к подобным выводам. А если посмотреть - то и ряд других криптографов тоже. Достаточно посмотреть на большинство новых алгоритмов.
> Опять же ваши догадки на пустом месте. Я почему-то RSA 4k вижу регулярно в контекстах PGP.
Регулярно - понятие растяжимое. Какой процент например SSL-enabled хостов в интернете рискнет здоровьем 4K RSA юзать? Ну или там SSH? Им пользуются полтора параноика в почте, где время шифрования пофиг. Ну да, для шифрования полутра сообщений в день, особо параноидальными личностями - сойдет. Только это маргинальные юзкейсы, живущие рядом с блокнотами. А если ssh могут дергать ремотные системы - он мигом становится колом, упираясь в проц. Догадайтесь с 3 раз где.
> Про nonce/replay в контексте cryptobox: я намекал что cryptobox мало чего решает лучше.
Он решает ровно столько сколько заявлено - список гарантий честно и доходчиво описан. Nonce изначально не есть защита от реплея. Хоть и может потенциально быть использован в этом качестве.
В целом я считаю это сочетание достаточно удачным по совокупности параметрам. Он не самый стойкий, но - good enough. Он не покрывает все мыслимые сценарии. Но в результате tweetnacl - лишь 18 кило сишного кода, которые реально прочитать за вечер. В отличие от openssl. Настолько компактные и шустрые, что какие-то перцы запустили это даже на AtMega (удачи туда впихнуть либу TLS). Или всякие там датчики и мелкие (полу)промышленные фиговины с микроконтроллерами в принципе недостойны нормального шифрования? (удачи там RSA 4096 посчитать). Апи - не предел мечтаний, но лучше того что у других, с внятными гарантиями и понятным описанием. Не надо никаких особых скиллов в ракетной инженерии, в отличие от.
> Можно синхронизировать часы и не писать nonce,
Синхронизировать часы с достаточной разрешающей способностью и точностью - сложная задача. Если на уровне зарубания до 1 пакета надо.
> когда вам не предъявляют требований по трафику.
У Tor вон народ содержит дофига серверов и им нормально вроде.
> А когда это превратится в большие деньги,
Большие деньги подразумевают bulk траффик и оверхед на уровне менее 4% скорее всего.
> После какой-то планки они поменяются местами и вы откажетесь от padding.
Я - не откажусь, это не про мои юзкейсы.
> опциями, так как это дешевле в плане разработки, поддержки и даже аудита.
Только потом там оказывается куча разных багов, через которые вообще всем и дофига раз, а какой-нибудь ssh вообше защищает сессию довольно номинально и позволяет нефиговую реконструкцию. Такая вот секурити получается. Наворочено много, а результат - не в пользу пользователя.
> дорого. Запоминать последнее значение счётчика и отбрасывать всё остальное: хорошее решение,
> но из-за которого может дропаться много пакетов из-за того что в разном порядке пришли.
О, а вы все-таки не такой деревянный как я подумал и заметили недостаток на который я намекал.
> Именно поэтому появляется много опций и не существует убер-решения.
Именно поэтому мне не нравятся убер-монстры типа TLS - получается 100500 опций на все случаи жизни. Настроить их правильно в результате не может почти никто, а либы получаются сложными, с кучей секурити проблем. И апи невменяемое, коим почти ни 1 апликушник пользоваться не умеет. Сколько программ проверяют не сменился ли фингерпринт сертификата ремоты? Я так 1 знаю - pidgin. А остальные - ну вы поняли. Половина вообще фингерпринт не показывают, так что я даже зная что искать - в пролете. Безопасные соединения, б...
> быть. 4% overhead если будет составлять стоимость 4% от переданного трафика
> за который могут платить большие деньги — хороший повод задуматься.
Если сравнить с стоимостью парка серверов для обсчета 4096-битных RSA для всех https сайтов - не так уж и плохо получится :P.
> Ну и смотря какой трафик конечно же. Если это частые, но мелкие пакеты -- overhead
> существенный. Можно буферизировать, но delay может быть недопустим.
Есть виды траффика которые откровенно проблемные. То что вы говорите - почти про VoIP. И что характерно, за счет таких рассуждений появились техники реконструкции VoIP сессий на основе размера пакетов. VBR кодеки в паре с конечным множеством звуков/фраз и характерной конструкцией предложений приводят к тому что атакующий даже не зная алгоритма шифрования но зная свойства речи может с хоршей достоверностью реконструировать содержимое основе параметров пакетов, используя размеры и времена. И единственное лечение которое я вижу - немного буфферизовать и паддить. Иначе будет вот так вот, и никакое шифрование не спасет. Ну и CBR кодек и никакого silence detection. Попытка сэкономить трафф ведет к расшифорвке спича. Такой вот tradeoff.
> сразу вижу что чистый cryptobox слишком медленный будет даже для моих домашних нужд.
А что насчет beforenm/afternm? Уж не знаю входят ли они в ваше понятие "чистого" криптобокса.
>>Это говорит человек, только что призывавший увеличивать количество раундов в старом крапе в 3 раза? Двойные стандарты такие двойные.
> И опять бесстыжая клевета.
Почему клевета? Для меня это выглядит так: древнему хламу мы скидку на медленную работу сделаем, неудобные моменты - поскипаем, а зато какому-нибудь DJB припомним по полной. ИМХО - предвзятость и необъективность.
> Я призывал увеличивать кол-во раундов в том что является на данный момент надёжным и проверенным
> и где процессорное время будет дёшево.
Если нечто надежное и проверенное - по логике вещей, там уже было достаточно раундов. Иначе какое ж оно надежное? Кроме того, наобум фигарить новые раунды не будучи криптографом - сомнительная идея. Как местный Pavlinux метко заметил, если два раза прогнать RC4, можно получить свой исходный плейнтекст. Насколько меняются свойства от добавочных раундов - а кто из криптографов это анализировал?! Где криптоанализы? Ах, нету?! Ну тогда бла-бла про повышению стойкости и тем более проверенность временем - ни о чем. На это просто не было криптоанализов и все выводы - на песке.
> В старый "крэп" это превратилось уже в будущем, но до сих пор этот старый "крэп" удовлетворяет
> те же банки, потому-что реализации в железе были дешёвы и быстры.
Что там банки удовлетворяет - вообще не аргумент. Их удовлетворяет магнитная полоса без шифрования и 4-значный пинкод.
> На заметку: в PGP никто не обязует делать подпись в обязательном порядке.
> Deniable encryption с ним не сделать, но оно и не всем надо.
ИМХО достаточно существенный недостаток в целом. Ведь задача шифрования в том чтобы атакующий получил минимум информации. Ну и вообще PGP как-то так явно заточен на применения типа шифрования почты. Ну еще подписывание файлов.
> Кому надо -- другой инструмент. А кому-то это только вовред.
Тем не менее, я считаю что шифрование должно быть неотличимо от рандомных данных и не должно позволять постороннему наблюдателю что-то обнаружить или доказать. Cryptobox в этом плане довольно близок к идеалу.
> Он решает самые простые задачи в которых уже давно никто не делает ошибок.
Кто этот "никто" и где он не делает ошибок? А то у вас то "CTR не могут реализовать", то "не делают ошибок". Вы уж определитесь? А то у вас истина вертится как флюгер на ветру.
> Он ничем не помогает значительно. PFS, replay -- вот и
> готов очередной SSHv2 или почти TLS.
Только кода будет сильно меньше. Ну и багов в нем. А TLS вообще PFS как бы умеет, но как бы и не по дефолту. Вот это я понимаю: "форменное западло в пользу NSA" (им то конечно удобно: отжал ключи и порядок).
> спокойно можно жить без TLS.
Только при этом большинство фич отваливается и поэтому режимом никто сроду не пользуется. А так все хорошо, прекрасная маркиза.
> Нет, вы не знаете про протоколы и не знакомы с реальностью чтобы предполагать и удивляться почему так
> много "legacy", "crap" и отсутствие единственного убер-решения.
Я в курсе про этот режим. И в курсе что на практике им никто не пользуется. Потому что без TLS и подъема PKI openvpn превращается в жалкий обрyбок, на уровне вашей приблуды наверное. Хочется более 1 конекта на экземпляр сервиса - уже подавай CA, сертификаты и прочее, со всеми вытекающими. При том всем этим почему-то еще и гордятся, считая фичой.
> Я уже говорил: если это VPN, то факт посылки пакета (пусть даже
> который не будет расшифрован) -- это уже утечка данных.
Не обязательно. Пакеты можно иногда и фэйковые слать. Даже не обязательно чтобы получатель мог их расшифровать. Для пущих лулзов - пусть NSA пыхтит с их расшифровкой. "Ух ты, а что, так можно было?!" :). Тут конечно баланс между оверхедом и приваси. Но в моем понимании это для юзера должно настраиваться тривиально. Ну там буквально 1 параметр: "overhead vs privacy" (в гуе - прямо слайдер, например).
> сливается информация о наличии пакетов (но которая да -- не будет дешифрована).
Информация о наличии пакетов - не синоним траффика. Для начала будет не понятно служебные ли это пакеты или траффик (светить в plaintext части это разумеется не надо). А при повышенных требованиях можно и фэйковые пакеты кидать и буферизовать/сглаживать траффик.
> в мире TLS, IPsec и SSH в которых очень очень многие
> нововведения (с 80-х годов) не внедряются, зато бесятся по поводу симмтеричных
> шифров но не переживают по поводу ZK.
Ну их все в 1 ряд ставить как-то не совсем правильно, пожалуй. В openssh люди поадекватнее. Но и у них грабли по историческим причинам накопились. И некоторые их решения компромиссны в местах где я бы такие компромиссы видеть не хотел. В частности - утечки о активности админа в сессии. И вместо того чтобы лечить вот это - они там какие-то качалки, блин, встраивают. Этот ваш Тео - он точно параноик? Куда он смотрит на этот крындец?
> Откройте хотя бы "Прикладную криптографию" Шнайера и убедитесь что есть куча алгоритмов
> которые криптографы могут предсказать, но ни один статистический тест нет.
Предсказание nonce в случае DJB никому ничего особо ценного не дает.
> Вы совершенно не знаете теорию если думаете что тесты ловят качество PRNG.
Вы тормозите, если думаете что в случае nonce у DJB есть каие-то требования к качеству.
> Подчеркну: совершенно, раз умудрились такое сказать.
А что вам не нравится то? В случае nonce есть единственное требование - чтобы вывод не повторился за обозримое время. Это и проверить тестами не сильно сложно и будет быстро запалено криптографами для сколь-нибудь применяемых примитивов, даже какого-нибудь виндового криптоапи.
> паритесь о каких-то S-box-ах, но при этом доверяете /dev/urandom Linux-а, который
> куда проще отравить чем возится с атаками на кэш. Не верите?
Да как сказать. Я припоминаю что в свежих версиях ядра Linux это дело чинили и если энтропии недостаточно, чтец может быть даже поставлен на паузу вплоть до момента когда энтропии наберется больше. Но да, вы правы в том что наглые чтецы могут понизить качество энтропии и это в целом некая проблема.
> из источников. Но Fortuna реально никак не смог побороть. Linux /urandom
> -- шутка из серии Dual EC.
Скорее, проблема в чрезмерно оптимистичном допущении - что энтропию злонамеренно никто не истощает. Ну примерно как у вас с допущением что на тот же проц никто не пристроит процессы.
> в здравом уме и будет делать куда более простые вещи (как
> тоже отравление пула энтропии).
Валидный пойнт. Но в озвученном мной варианте убер-сильный рандом надо в основном в "мастер" ключах (которые можно сгенерить в более-менее подконтрольном окружении). И активного чтеца из /dev/urandom проще заметить чем шпиона сбрасывающего кэш. Как посмотреть кто какие файловые операции делает - я еще понимаю. А как посмотреть кто процессору сбросил кэш и насколько нагло он это делает?
> Надейтесь, а я приму меры (для PGP это например entropy gathering daemon)
> чтобы не надеятся а знать что отравить энтропию будет крайне сложно.
В целом валидный пойнт. И насколько я знаю, на виртуалках и некоторых вариантах эмбедовки с энтропией все не очень хорошо даже без наглых чтецов, потому что юзер никаких действий не производит и источников случайностей как таковых - минимум. Сколько там энтропии реально окажется доступно - очень отдельный вопрос. Поэтому, если даже наглых чтецов нет - с качкой энтропии борзеть и самому не надо. Если из urandom'а напрямую качать энтропию в каждый пакет - так пожалуй на высоком PPS сам себя без энтропии оставишь.
> Linux кстати был замечен что как-раз читает аппаратные DRBG с Intel-платформ
> прям напрямую, потом быстро поправили,
Насколько я помню, Теодор Тсо зарубил подобные инициативы еще на подлете. Хоть он и не криптограф, но перспективность таких подходов понятна и ему. Он там еще едко шутил про флаги с названиями типа YES_I_TRUST_INTEL_AND_NSA.
Если вы в этом преуспели и вам не обломно - прогоните ваши эксперименты с угадыванием вывода /dev/urandom для свежих ядер типа 3.18? Ну или методику в студию - сам прогоню.
> но какие-нибудь Тео Де Раадты первые кто послал с этим народ. Linux вообще по мне (чисто по
> мне, моё IMHO) -- настолько унылая, некачественная помойка кода,
Ну а у Тео, например, его НеПомойка получилась такой, что этим мало кто хочет пользоваться, хоть оно трижды качественное. Понятие о качестве штука интегральная. И если система половину моего железа не цепляет - какое там качество? Старый паровоз на запасных путях - в крушение конечно врядли попадет, да и поломок новых не будет самих по себе. Ну вот правда и транспортным средством его назвать сложно. И сравнивать надежность с магистральным электровозом как-то криво.
> в которой сделать что-то безопасно куда сложнее чем отревьювить TLS реализацию какую-нибудь.
Да вот я смотрю, OpenSSL который там год, а его все ревьюят и ревьюят. CVE все прут и прут. И думаю что и дальше это продолжится в том же духе. Но ок, я соглашусь с вами в том что в плане секурити линукс не предел мечтаний. Но и получше многих иных вариантов. А вон Тео в курсе IOMMU например? Или его DMA-based атаки не пугают? А то секурити - штука многогранная. Современная периферия - куча сервисных сопроцессоров, потенциально способных к DMA. Ну так, если уж паранойю прокачивать на совесть. Как там, Тео по этому поводу не икается в опенбзде?
> Поэтому Linux не использую -- не доверяю и считаю полнейшим crap-ом.
Это наименьшее зло которое может полноценно подхватить мои задачи. Проприетарные системы - не вариант вообще. Бзды - недоразвитые задохлики. Остальные вообще от горшка два вершка.
> Есть там хорошие разработчики, но Линус уж чего только не принимает в основное дерево.
Вообще - да, есть такое дело. Но фрибсдшникам про это возмущаться странно - они делают то же самое. В том числе передирая из линя.
> Мда… а у меня видимо маразм какой-то и я даже под своей
> FreeBSD всё-равно использую свой entropy gathering daemon?
Хм, вообще это валидный пойнт. Но если уж мы про фрибзду - а у вас что там с IOMMU? И почему даже нубская убунта может сетевым сервисам затянуть всякие там флаги стэк-протекторов и рандомизации адресного пространства на многие годы раньше чем эти ваши фрибсдшники? У которых для начала даже практика подписывания обновлений (именно подписями, а не просто хэшами, которые атакующие могут поменять) - только начинает применяться. И вот эти люди говорят что в линксе - бардак? И уж конечно сдернуть целый ZFS у саней под кривой лицензией - не пихание в систему чего попало. А от себя - я еще и GPL violation нашел. В фрибзде. Приветы вашим копипастерам.
> В общем советую почитать "Прикладную криптографию" Шнайера. Хотя бы про mutual ZK
> authentication узнаете.
Да я читал, но правда достаточно давно. И чего мне узнавать? Я и так в курсе.
> в вашей компетентности относительно того где и как будут применятся какие вектора атак.
Я бы предъявил себе излишний оптимизм с тем что не будет наглых чтецов из пула энтропии.
> Переживаете из-за S-box-ов, когда под носом у вас urandom
> который можно, реально можно, отравить.
Валидный пойнт.
> В следующем релизе FreeBSD кстати будет применятся Fortuna --
Отлично. Только это лишь 1 из аспектов. И да, вы знаете, у этого вашего Персиваля в scrypt нашли невкусный недостаток: ваши крутые профи тоже не в курсе кэшей. Так что если scrypt использовать для проверки паролей - тайминг атаки опять же. По этому поводу появились всякие catena, sponge и еще некоторые. Которые стараются быть memory hard но при этом чтобы обращения к памяти не зависели от пароля.
> (дешёвые на тот момент DES-чипы аппаратные были реально офигенным решением для
> 3DES -- очень дёшево и очень безопасно (местами до сих пор)),
Предпочту быстрые софтварные алгоритмы. Ну его нафиг - доверять каким-то чипам, которые проверить невозможно. Впихнут туда какой-нибудь флэш-памяти и сохранят все ваши ключи, например. А что помешает то?
