Ну в общем особо отвечать я уже устал. К консенсусу мы не придём -- разное мировоззрение.Замечу что OpenVPN не основан на TLS. Он его может (но не обязан) использовать для обмена ключами/аутентификации и на это всё. Остальной протокол -- его родной и независимый от TLS.
Шифровать видео, иметь DRM это не средство исключения того что видео нельзя будет достать. Это средство повышения порога входа для этого. Если деньги затраченные на DRM будут значительно меньше денег затраченных на преодоление порога входа дешифрования видео -- DRM выполнил свою роль успешно. Вы не понимаете суть для чего DRM нужен, воспринимая только маркетинговые слоганы что мол это типа чтобы не дать пиратам вообще возможность копирования.
В Linux качественный пул энтропии? Честно говоря, вы меня насмешили. Видители TLS то ещё дерьмо, а /dev/random в Linux годный? Особо дальше комментировать не буду уж эту тему.
Касательно закрытых (проприетарных) систем -- это всё очевидно что там даже не будет PRNG.
Чтобы сгенерировать KDF(password, salt) вам salt надо взять рандомную. Без рандома качественного никуда.
>Это не у меня. У меня открытая система, которая подчиняется мне. А в проприетарных системах рассуждизмы про шифрование - windows xp with firewall.jpg (cпросить у гугля).
А я хоть раз говорил вообще про совместимость понятий безопасности и закрытых систем? Если у вас открытая система где всё от и до подчинаяется вам, то это идёт врозь вашей боязни AES. А если где-то на другом конце у вас неподконтрольная вам система: то какая разница какой алгоритм и вообще что вы будете делать, раз априори никакой безопасности не будет. Сам же себе противоречите. Или у вас где-то есть закрытое ПО -- тогда вообще пофиг что использовать ибо априори пагубно, или у вас всё подконтрольное и открытое -- тогда не ясно что вы паритель о AES и прочем. В последнем случае парится можно разве что о производительности.
Касательно ГОСТ: в отличии от DES/AES и прочих, в нём разрешено применять собственные S-box-ы, а не заранее рассчитанные в которых могут быть лазейки.
>Криптографы ушли от этого в новых схемах.
>Результирующие дизайны также будут основаны на этом core, оно не использует таблиц. То-есть, про отказ криптографов от таблиц я нигде не наврал.
Похоже вы не следите за новостями чтобы делать такие заявления. И как всегда преувеличиваете масштабы. Отказ одной команды в одном whitepaper это не отказ криптографов.
>Это говорит мне человек, заботящийся о проприетарных системах, где ядро заведомо работает на чужих дяденек? Хм.
А это уже явная клевета и враньё. Замечу что я член FSF, FSFE и EFF -- так что вы зря называете меня человеком который "заботится" о проприетарных системах и небось ещё у вас даже мысль могла промелькнуть что я их где-то использую или что-то под них пишу? Хорошо что не написали об этом.
Это формальные придирки. У меня не было цели пиарить threefish. Была цель проиллюстрировать эволюцию мышления криптографов под воздействием обнаруженных проблем.
Вы вроде тот человек который сказал что не бывает мелочей в криптографии? А я отчётливо вижу что вы сравниваете один из кирпичиков используемых в хэш-функции с симметричным блочным шифров.
>По этому поводу RSA 4096 используют лишь чуть чаще блокнотов.
Опять же ваши догадки на пустом месте. Я почему-то RSA 4k вижу регулярно в контекстах PGP.
Про nonce/replay в контексте cryptobox: я намекал что cryptobox мало чего решает и что даже вокруг nonce можно много и долго думать как лучше. Можно синхронизировать часы и не писать nonce, можно юзать PRNG, можно делать счётчик, итд, итд. Много чего можно сделать и везде есть свои плюсы и минусы. Вы не боитесь увеличения трафика? На 24 байта -- ok. А ещё и padding хотите? Очень здорово когда вам не предъявляют требований по трафику. А когда это превратится в большие деньги, то вы начнёте сравнивать стоимость трудозатрат на получение какой-либо полезной информации выуженной из анализа статистического поведения трафика и стоимости трафика. После какой-то планки они поменяются местами и вы откажетесь от padding. Везде разные требования, условия -- именно поэтому не делают 200 разных реализаций SSH: в одной будет padding, в другой не будет padding, в одной нужно синхронизировать время, в другой не нужно. Именно поэтому люди вынуждены делать один SSH с 200 разными опциями, так как это дешевле в плане разработки, поддержки и даже аудита.
При этом вот у вас защита от replay может быть даже и никакая. Хотя у меня это строжайший must-have, так как дубляж ровно одного UDP пакета который заставляет где-то срабатывать триггер может стоит очень дорого. Запоминать последнее значение счётчика и отбрасывать всё остальное: хорошее решение, но из-за которого может дропаться много пакетов из-за того что в разном порядке пришли. Где-то лучше так, а где-то производительность стоит дороже и допустимо оставить небольшое окно для атаки. Да, оно будет -- но на практике не применимое. В GoVPN я кстати сделал это как настраиваемую опцию: чтобы кому как надо, тот так и сделал. Именно поэтому появляется много опций и не существует убер-решения.
Согласен что трата ресурсов может быть и разумной. А может и не быть. 4% overhead если будет составлять стоимость 4% от переданного трафика за который могут платить большие деньги — хороший повод задуматься. Ну и смотря какой трафик конечно же. Если это частые, но мелкие пакеты -- overhead существенный. Можно буферизировать, но delay может быть недопустим. Итд. Может быть, а может не быть. Лично для себя я сразу вижу что чистый cryptobox слишком медленный будет даже для моих домашних нужд.
>Это говорит человек, только что призывавший увеличивать количество раундов в старом крапе в 3 раза? Двойные стандарты такие двойные.
И опять бесстыжая клевета. Я призывал увеличивать кол-во раундов в том что является на данный момент надёжным и проверенным и где процессорное время будет дёшево. В старый "крэп" это превратилось уже в будущем, но до сих пор этот старый "крэп" удовлетворяет те же банки, потому-что реализации в железе были дешёвы и быстры. Это наиболее дешёвое и надёжное средство было.
На заметку: в PGP никто не обязует делать подпись в обязательном порядке. Deniable encryption с ним не сделать, но оно и не всем надо. Кому надо -- другой инструмент. А кому-то это только вовред.
>DJB в криптобоксе берет на себя массу сложных проблем
Он решает самые простые задачи в которых уже давно никто не делает ошибок. Он ничем не помогает значительно. PFS, replay -- вот и готов очередной SSHv2 или почти TLS.
>Я думал что вы пальцуете. Рассказывать мне про протоколы - затея неблагодарная.
>OpenVPN протокол - основан на уберсложном TLS
Неблагородное говорите? Ну вы же снова показываете незнание простого OpenVPN в котором спокойно можно жить без TLS. Нет, вы не знаете про протоколы и не знакомы с реальностью чтобы предполагать и удивляться почему так много "legacy", "crap" и отсутствие единственного убер-решения.
>Не вижу никаких особо фундаментальных проблем на этом уровне. А у гнунета все упирается в общую невнятность и местами странные решения.
Я не удивлён уже.
>Все пакеты с неправильных (неизвестных) ключей и просто рандомный мусор будут невалидны. Just as planned. Это чем-то плохо?
Я уже говорил: если это VPN, то факт посылки пакета (пусть даже который не будет расшифрован) -- это уже утечка данных. Вы регулярно везде не видите у себя под носом то о чём так любите говорить. То вам padding нужен, а то не боитесь что сливается информация о наличии пакетов (но которая да -- не будет дешифрована). Ещё в 80-х годах криптографы и начали много думать о zero knowledge и именно mutual authentication чтобы не сливать даже эти данные. В крипто нет мелочей -- ваши же слова. Вы витаете в мире TLS, IPsec и SSH в которых очень очень многие нововведения (с 80-х годов) не внедряются, зато бесятся по поводу симмтеричных шифров но не переживают по поводу ZK.
>Если PRNG повторяется за обозримое время - это дрянь а не PRNG и ловится самыми базовыми тестами криптографии.
Откройте хотя бы "Прикладную криптографию" Шнайера и убедитесь что есть куча алгоритмов которые криптографы могут предсказать, но ни один статистический тест нет. Вы совершенно не знаете теорию если думаете что тесты ловят качество PRNG. Подчеркну: совершенно, раз умудрились такое сказать.
>Наиболее очевидный вариант - прочесть 32 байта из /dev/urandom. На линухе я посмею засчитать это за нормальный приватный ключ.
Кстати снова рассмеялся. Вы явно не читали статей по поводу того как атакуют именно Linux-овый PRNG. Уже не раз говорил и повторю: вы паритесь о каких-то S-box-ах, но при этом доверяете /dev/urandom Linux-а, который куда проще отравить чем возится с атаками на кэш. Не верите? А я собственными руками его отравлял из user-space так что его выхлопы в другом процессе стали в какой-то мере предсказуемы (требовалось 2**32 переборов чтобы подобрать ключ). Это был Debian 7.0 amd64 из коробки. Кстати решилось довольно просто применением Fortuna в которой /dev/urandom был одним из источников. Но Fortuna реально никак не смог побороть. Linux /urandom -- шутка из серии Dual EC.
Кстати тот же самый DJB делал в прошлом году презентацию о том что люди часто парятся о кирпичиках который никто-никто-никто ломать не будет в здравом уме и будет делать куда более простые вещи (как тоже отравление пула энтропии).
>DJB делает свою либу для *никсов и в открытых системах на более-менее честный рандом можно надеяться.
Надейтесь, а я приму меры (для PGP это например entropy gathering daemon) чтобы не надеятся а знать что отравить энтропию будет крайне сложно. Linux кстати был замечен что как-раз читает аппаратные DRBG с Intel-платформ прям напрямую, потом быстро поправили, но какие-нибудь Тео Де Раадты первые кто послал с этим народ. Linux вообще по мне (чисто по мне, моё IMHO) -- настолько унылая, некачественная помойка кода, в которой сделать что-то безопасно куда сложнее чем отревьювить TLS реализацию какую-нибудь. Поэтому Linux не использую -- не доверяю и считаю полнейшим crap-ом. Есть там хорошие разработчики, но Линус уж чего только не принимает в основное дерево.
>В Linux я пишу валидный и безопасный прототип за пару минут
Мда… а у меня видимо маразм какой-то и я даже под своей FreeBSD всё-равно использую свой entropy gathering daemon?
В общем советую почитать "Прикладную криптографию" Шнайера. Хотя бы про mutual ZK authentication узнаете. Вы слишком много упомянули такого что полностью заставляет усомниться в вашей компетентности относительно того где и как будут применятся какие вектора атак. Переживаете из-за S-box-ов, когда под носом у вас urandom который можно, реально можно, отравить. В следующем релизе FreeBSD кстати будет применятся Fortuna -- что тут уже конечно очень круто повысит безопасность из коробки. И вы регулярно всё максимизируете отправляя что-то в crap (дешёвые на тот момент DES-чипы аппаратные были реально офигенным решением для 3DES -- очень дёшево и очень безопасно (местами до сих пор)), не задумываясь о стоимости атак и стоимости затрат, и padding трафика для вас это must-have, а DRM типа вообще бесполезен. Не говоря уже о клевете.
