А что вы всё только в OpenSSL тычите? Я уже подчеркнул: OpenSSL это крайность, однако частенько куда более вменяемая чем куча поделок типа CryptoCat.

> Я думаю что один Бернштейн легко заменяет сотню макак пишущих openssl. Так,
> глядя на плюхи которые они вешают. Я вообще не понимаю чего
> ради эти люди криптографическую либу писать полезли.

Это ваше личное мнение, конечно же. Против Бернштейна у меня ничего нет. Но я вижу как работают Шнайеры и Фергусоны: они тоже делают ошибки. Для меня они бОльшие авторитеты чем Бернштейн. В OpenSSL много говн, но ещё больше в 99% остального софта которые пытается назваться крипто-что-то там. NaCl -- превосходен. Считаное количество (по пальцам посчитать) других библиотек или реализаций -- превосходны. Вот только их считанные единицы. Тьма других аналогично безграмотна. В вашем представлении, насколько погляжу, весь свет сходится на Бернштейне, ибо криптографы не пишут софт, по факту. Шнайер способен на C накодить алгоритм, но не законченную реализацию софта который можно запускать в UNIX-like (например) системах. Криптографы конечно знают про устройство ЭВМ, кэшей и прочего, но опять же людей вменяемо что-то могущих писать и понимать в криптографии как например тот же Тео Де Радт как-то единицы. Доверять паре человек и их реализациям -- я не стану, потому-что маловато их будет, опять же не проверены достаточно временем.

>> Для меня хороший вопрос что важнее и лучше.
> Я выбираю осмысленность действий индивидов. Нормальные криптографы это могут. А вот авторы
> openssl показали что у них не богато с довольно базовыми вещами...

И где эти криптографы? Бернштейн есть. С ходу я никого больше не могу назвать. Zooko ещё (автора (одно из) BLAKE2). А вот больше как-то с ходу и не могу и знаю что те же разработчики Skein не шибко много делают реализаций (промышленных, а не неких эталонных).

> В случае криптографии одно не сильно далеко от другого. Более того -
> когда реализаторы лезут донавесить 100500 сервисных функций, как опенссл - можно
> налететь на тот факт что эти плюшки были с цианидом, тудыть
> их растудыть.

Всё вы тычите в крайность в виде OpenSSL. Крайне не согласен что криптография от реализации в софте конкретной не далеко друг от друга. Далеко и ещё как. Поэтому в мире единицы пишущих код криптографов и тьма программистов не смыслящих в криптографии. Дальше уже не буду комментировать то что вы постоянно тычите в OpenSSL. Я не говорил что эта библиотека яркий пример того что ревью будет делаться и тому подобное и качественно. Но это и не означает что оно не будет делаться. ssl это крайность, как и ipsec, когда никто не захочет делать, а власти с законами требуют использовать хоть что-то. У меня свои требования и видение на то что я бы считал безопасным: пока я не доверяю в достаточной мере ECC и использовать lsh например в котором не ECC не будет -- я не буду. Тем более что они туда собираются встраивать и AES. Да и в любом случае по мне так это провальный проект который опять же тянет за собой совместимость с SSH-протоколом, отнюдь не простым и не очень. В SSH ни в какую нет наработок по аутентифицированным обмена ключей, одновременной двусторонней zero-knowledge аутентификацией: а ведь это всё идёт ещё с 80-х годов. Как-раз создаётся впечатление что это пишут люди как-раз не очень глубоко знающие криптографию и почему-то просто не затрагивающие превосходные хорошо исследованные наработки, кстати использующие всё же же известные примитивы. Разве что только lsh выделяется поддержкой SRP.

> Про это знают все нормальные криптографы. А вот то что про это
> в курсе какие-нибудь деятели типа авторов openssl - я бы за
> это зуб не дал.

Мне кажется вы совершенно не знакомы с его кодом. Это там много где учитывается.

> MD5 тоже проверенный временем. Проверка показала: он г-но. Ну и sha1 туда
> же куда-то отправляется. Хотя про blowfish никакого особенно крутого криминала мне
> не известно так сходу. Но тут еще вопрос в том -
> а сколько человек проблемы искало?

Думаю из-за своей старости и относительной простоты Blowfish излюбленный алгоритм для большинства кто собирается заниматься криптоанализом. MD5, SHA1, итд -- показали что говно. Dual-EC-чего-то-там показали что вообще неприменимое. А вот для меня совершенно не факт что в Salsa/Chacha ещё не найдут чего-то реально критичного сводящего на нет всю его безопасность, как и в 25519 и то что из-за него весь PFS идёт нафиг и смогут дешифровать ранее сохранённый трафик. Однозначно его будут и яро анализируют, но лично для меня должно пройти ещё время. А это годы, ведь и AES не сразу оказался поломанным (до какой-то степени конечно).

> См. выше. Логику построения salsa/chacha я более-менее понимаю и вижу криптоанализ. При
> том - с пониманием дела и даже "частично успешный". Это значит
> что алгоритм проверяли не какое-то сферическое время в вакууме а вполне
> себе криптографы, разбирающиеся в предмете и даже нащупавшие некие упрощения. А
> мнение 10 профессиональных криптографов - ценнее чем мнение 10 000 кодеров,
> не имеющих понятия о криптографии.

Мнение кодеров меня тоже не волнует, а вот мнение 10 криптографов -- маловато. На полном серьёзе. AES анализировали многие годы явно больше 10 и не находили сильных подвохов.

> Если уж на то пошло, 25519 и прочие появились далеко не вчера.
> Вчера на них лишь обратили внимание из-за кризиса доверия к NIST
> и прочая.

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

> Ну да. Если защита траффика нужна. Хотя честно говоря, прецедентов вскрытия WPA2
> если нет WPS и сложный пароль - мне не известно.

Лучше не рисковать :-)

> Я считаю что доверяемая прошивка на роутере без явных ляпов мне все-таки
> друг и товарищ и потому предпочиаю openwrt, где все это реализовано
> не сильно архаичным линем и дровами из его комплекта.

Я не доверяю конкретно самому алгоритму: он куда сложнее чем NaCl с cryptobox-ами его, плюс делали его люди с участием корпораций и госструктур, что априори вводит в недоверие.

> Тут еще вопрос в количестве изучавших и их квалификации. От того что
> миллион быдлoкодеров посмотрит в код - криптография лучше не станет. Потому
> что они в этом ни бум-бум. А вот если криптографы потратят
> время на серьезные попытки атак - совсем иное дело. Открытость кода
> необходима для аудита разными криптографами. Но вот то что качество этого
> аудита стопроцентно коррелирует со временем или числом глаз - не факт.
> Я склонен придавать вес еще и компетенции тех кто смотрел, этот
> параметр сам по себе не коррелирует с временем или количеством глаз.

В том что Blowfish смотрели тьма профессиональных криптографов у меня сомнений нет. Кодеры не интересуют само собой. Компетенция глаз -- выше всего. Опять же для алгоритма. Но код криптографы смотреть не будут. Тут могут пригодится и быдлокодеры.

> И это одна из вещей которые мне в ssh не нравятся. Ксати
> если уж мы о птичках - идея завернуть ssh в hidden
> сервис тор имеет место быть и как минимум он здорово нагнет
> подобные инициативы, минимизировав полезность сведений за счет фиксированного размера
> cells.

Либо "профиксить" SSH-протокол (добавить опцию?) чтобы он сам делал нужный padding. Хотя бы! Само собой просто минимальный размер или константный у всех пакетов это не панацея. Но в real-time штуках всегда так. В идеале кстати по мне так "шуметь" в канал. Надёжнее не бывает (ну кроме когда совсем связи нет), хотя и накладно. GNUnet всё ж выбирает безопасность/анонимность превыше всего и поэтому шум есть всегда и везде.

> У них фиксированный размер cells, насколько я помню. Он один на все.
> Шлете 1 байт? В провод полетит cell фиксированного размера. Как и
> на 20 байтов. Или на 100. Это достаточно неплохо нагибает подобный
> анализ. Хотя будучи low latency оно неизбежно утекает времянки.

Ага, и я про это же.

> А там довольно компетентные авторы с неплохими идеями. Но вот реализация какая-то
> странная.

GNUnet по мне так собрал вообще все наработки и всю теорию что с 90-х по середину 2000-х придумало человечество чтобы сделать убер-правильную сеть. Очень уважаю их. Но реализация не простая, даже поднять не просто бывает.

> Я не счтиаю что использование криптогрфии должно требовать квалификации ракетного инженера
> от эксплуатационщика. Такой подход обречен на провал.

Либо вменяемый человек, либо тот который даже fingerprint не будет проверять и в качестве парольной фразы будет использовать 12345. По моему опыту как бы только "ракетные инженеры" способны выполнить хотя бы сверку fingerprint-а. Это конечно крайности, так быть не должно, но по факту либо это человек-ракетчик, либо тот кто тыкает ok на всё подряд.

> Булшит. Дяденька Бернштейн в его либах показал что хорошая безопасность - не
> синоним адового гемора. Вот этим либа сделанная криптографом понимающим проблематику отличается
> от либы которую писали какие-то лабухи не имевшие к криптографии никакого
> отношения.

Ага. Именно поэтому Шнайер перестал в своих книгах советовать ну всем вот лучший CTR режим вместо CBC и теперь советует CBC, потому-что люди даже не в состоянии передавать ему nonce-ы которые бы не повторялись или чтобы люди не использовали ключи для потоковых шифров дважды. Чего может быть проще, почему люди не замечают на каждой странице крупным шрифтом что для потоковых шифров нельзя повторять ключ. В 90-х он рекомендовал CTR. Потом перестал ибо люди не могут сделать даже этого. Вот просто применить в правильном режиме шифр в котором два входа и один выхлоп (как любой AES, Blowfish, Twofish, whatever) это может быть сложно? cryptobox NaCl-овский как-то помогает. Но если брать его алгоритмы по отдельности, то я скажу что, нет... я гарантирую что Бернштейновские алгоритмы будут использоваться неправильно из-за большей сложности. В HMAC передают ключ и данные. В его Poly1305 ещё и nonce и прочее. В Salsa/ChaCha аналогично бОльшее количество входов. Они сложнее к пониманию. А люди даже обычный блочный шифр не в состоянии заюзать. Неправильно заюзанные потоковый шифр -- куда опаснее чем блочный. Ошибка имеет куда большую цену. И то что сейчас тьма людей-программистов начитавшись о прелестях Salsa/Chacha побегут её всюду реализовывать приведёт я уверен к большей катастрофичности из-за того что фигово будут это делать, из-за сложности алгоритмов. Бернштейн всё явно описал в своих довольно простых бумагах: как, что и почему, даёт советы. Но, повторюсь, просто Blowfish не могут использовать. И я солидарен с Шнайером что блин лучше пусть чего проще порекомендовать если это ориентируется быть чем-то широким к применению. Например VCAS шифрование для HLS тупое CBC с тупым padding-ом: нельзя распараллелить (хотя для декодирования довольно приличного видеопотока было бы полезно ещё как), но зато это можно реализовать всем быдлокодерам. Salsa сложнее и это пусть создаст код с меньшим количеством чисто программных багов (из-за его размеров), зато с большим количеством, так сказать, архитектурных (когда ключ resuse-атся будет). cryptobox вот простой, но не эффективный если его фигачить на каждый отправляемый TCP-пакет например. Надёжно, но сомневаюсь что старый Blowfish с старым HMAC-RIPEMD160 будет медленнее, а надёжность у них для меня выше.

>> Если кто-то хочет чтобы легко и просто -- будет не безопасно :-).
> Нет никаких законов природы которые бы делали неизбежным такой tradeoff.

Нет, но факт остаётся фактом что даже CTR криво делают или CBC в SSH-е где утекает plaintext.

> А нормальный вариант - доверять самому себе.

Согласен. Но люди не хотят ответственности. Хотят просто, легко и чтобы не париться.

>[оверквотинг удален]
> openssl - там просто на порядки меньше мест где можно дать
> маху. Для "просто кодеров" сделаны вызовы которые dead simple и не
> оставляют места для лажи. Если кто понимает что он хочет -
> может и на кусочки относительно высокоуровневый вызов разобрать. А тем кто
> не понимает что это и зачем - пара вызовов в которых
> просто негде облажаться. А вот openssl - эталонный пример того как
> библиотеку криптографии делать не надо. В смысле, хрен с два кто
> этот крап из апликушников поюзает секурно, а аудитить за всеми макаками
> код я могу и задолбаться. Особенно учитывая его количество потребное для
> секурного использования openssl.

OpenSSL -- повторюсь, согласен, делать не надо такое. NaCl будут юзать коряво, с криптогрфической точки зрения.

> В реализации например использующей nacl - облажаться довольно сложно: API сделан так
> чтобы им мог пользоваться даже не криптограф. В отличие от openssl
> где если вы не гуру от криптографии - то вас ждет
> два зиллиона грабель активных по дефолту.

Не согласен. Уже выше написал. Примитивов меньше, а сами по себе они сложнее. Даже если и не сложнее, то всё-равно их так же не правильно будут юзать как и не в состоянии сделать Blowfish-CTR допустим. NaCl не предоставляет протоколов как-таковых. Ошибки и засады делают почти всегда не в алгоритмах шифрования, а том что касается банальной рутины типа обработки сообщений. NaCl тут не поможет. Разве что кроме того что сам сделает проверку MAC-а, ибо написано это будет Бернштейном. Интересно: один Бернштейн получается способен просто нормально отвалидировать MAC? Очевидно что нет. NaCl это низкоуровневые примитивы которых грамотно реализованых в том же libgcrypt полно. По поводу протоколов он не поможет, а ломают в первую очередь их.

> ИМХО это тyпой критерий. Софт не вино чтобы настаиваться.

IMHO это основной критерий. По мне так нет ничего глупее чем криптограф выпускает свой убер-алгоритм, за пару недель его ревьювят с десяток Шнайеров с Фергуссонами и круто его можно использовать. Вроде бы история с MD5, SHA1, AES показала что нужны многие годы чтобы нашёлся тот самый криптограф который надёт жопу. Вы считаете что тот же Blowfish или RIPEMD видимо просто мало криптоанализировали: это просто ваше заблуждение. Уж что MD5 с AES-ом криптоанализировали постоянно я думаю сомнений быть не должно. Сколько долгих лет понадобилось чтобы найти фатальные недостатки? Тот же Адм Шамир и Эли Бихам вроде бы только и делают что занимаются криптоанализами постоянными самого разного: какие-то алгоритмы взламывают через несколько часов после их выхода, какие-то годами. Этот критерий не вижу смысла обсуждать или доказывать, так как по мне тут всё очевидно и история показала неоднократно. Те же методы анализа для DES через сколько десятилетий появлялись которые то так, то эдак его позволяли ломать? Само собой например Serpent или возможно CAST на порядки меньше трогали криптографы, и это можно отнести к 20 лет тому кто никто не трогал. Но Blowfish не просто так внедряется в кучу софта, хотя Шнайер давно уже советует использовать Twofish, которые тоже свободен к приминению. (CAST конечно по политике). Ну и мне кажется вы как-то мало хотя бы просто публикаций смотрите (хотя бы заголовки) с того же iacr.org. Известнейшие криптографы (Бихамы и Шамиры регулярно видел) и криптоаналитики просто регулярно штампуют исследования и подходы даже к старью.

> Ну да. Зачем это - я не понял. Они не криптографы и
> делают странное. Но изначальное направление мысли - в правильную сторону имхо.

Вот у меня уже впечатление что просто прочитали какой у Бернштейна всё быстрое и ещё не сломанное и внедрили первым, плюс код простой. А дальше раскрыли свою суть что в целом пофиг на безопасность и NIST. Всё как я и "предсказал" параграфами выше: толпы пойдут реализовывать потоковые шифры Бернштейна, которые использовать сложнее.

> Лично мне RSA как раз не нравится. Чтобы он был безопасным -
> надо огромные ключи которые считать упухнуть можно. И костыли с фингерпринтами
> потому что сами ключи - немеряные.

Медленно ещё как, трафика ещё как. Но если на другой чаше весов ещё фигово проверенные в бою ECC -- мой выбор за RSA, старый недобрый но надёжный. Если есть под рукой доверяемая реализация.

> В конечном итоге оба сводятся к математическим проблемам которые неплохо изучены. А
> у RSA есть ряд дурных проблем за которые я с ним
> лишний раз вообще связываться не желаю и на фоне 25519 на
> свой страх и риск считаю динозавром.

Всё относительно. По мне так ECC ещё не доказано что полностью сводится к проблемам нахождения точек на кривых. Возможно докажут и можно разжать булки. Возможно не докажут, но и обратного утверждения нет. А возможно уже всякие NIST и ФСБ знают чего-то, до чего Шнайеры с Бернштейнами не дошли. Ведь Dual-ECDRBG не сразу "раскрылся". Сколько его использовали и сколько PRNG фактически не работали в мире? ECC пока для меня (опять же для меня) тёмная лошадка: что надо конкретно обезопасить я делаю с RSA, а всякие сессии до серверов где работа или домашняя утварь: ради уж производительности на 25519.

> Тем не менее, я склонен считать что дядюшка Бернштейн сделал один из
> наиболее симпатичных мне вариантов Диффи Хеллмана которые я когда либо видел.

Это вне всяких сомнений. Среди ECC и потоковых шифров: реально неоспоримо.

> И да, его либой можно например один сетевой пакет зашифровать. ОДИН,
> БЛИН. А слабо так с остальными? Без многоэтажных костыльных схем с
> посылкой дюжин пакетов? :)

Ой вот сомневаюсь что долго будет жить сам по себе софт в котором нет никакого протокола :-). Я вот даже для себя писал VPN с 25519/salsa20/poly1305 и без всяких cryptobox-ов весь код уходит на протокол. А все ошибки будут только и только в нём, а не в примитивах низкоуровневых. https://github.com/stargrave/govpn

> Ну вон md5 тоже временем проверили. И sha1. Вот только результат проверки
> - не очень, а пользуются. "Потому что стандарт".

25519 ещё и не проверили так же дотошно, а пользуются даже несмотря на то что стандарт :-)