> А что вы всё только в OpenSSL тычите?

А то что SSL/TLS один из наиболее массовых вариантов шифрования. И самых грабельных.

> Я уже подчеркнул: OpenSSL это крайность,

Примеры НеКрайностей можно?

> однако частенько куда более вменяемая чем куча поделок типа CryptoCat.

TLS пожалуй даже хуже чем это. Ну то-есть чрезмерного доверия этот кус вебни не вызывает. С другой стороны, сложно сказать что он принципиально хуже большинства иного софта.

> Это ваше личное мнение, конечно же.

Оно основано на наблюдениях кто и что делает и как это потом работает.

> Против Бернштейна у меня ничего нет.
> Но я вижу как работают Шнайеры и Фергусоны: они тоже делают ошибки.

Тут вопрос в компетентности. Те кто компетентен в своей области - лажают редко. А те кто не компетентен - сажают глупые ошибки там и тут. Просто потому что не знают (или не задумываются) о том что это несет какие-то последствия. У криптографа должен быть определенный набор личных качеств. Умение думать и способность параноидально просчитывать разные ситуации. Иначе ничего хорошего не жди.

> Для меня они бОльшие авторитеты чем Бернштейн.

Каждый человек имеет выбор. А потом выбор имеет человека. Я считаю что увиденного мной было достаточно для дискредитации авторов OpenSSL в плане квалификации и TLS как протокола.

> В OpenSSL много гoвн,

Он целиком г-но. От переусложненного протокола до грабельной реализации и дурного апи с дефолтами выбранными левой пяткой и кучи легаси.

> но ещё больше в 99% остального софта которые пытается назваться крипто-что-то там.

Сдалать хуже чем ssl - надо крепко постараться. Пора уже это признать - АНБ успешно накормили мир г-ном.

> библиотек или реализаций -- превосходны. Вот только их считанные единицы.

Ну да, придется разбираться в сортах и кто за кого держит. И?

> на C накодить алгоритм, но не законченную реализацию софта который можно
> запускать в UNIX-like (например) системах.

Бернштейн тоже NaCl написал своеобразно. Но осознал ошибки и сделал TweetNaCl, мелкий и легко встраиваемый куда угодно.

> как-то единицы. Доверять паре человек и их реализациям -- я не стану,

Что-то не хочется доверять толпе обезьян с гранатами по типу openssl.

> потому-что маловато их будет, опять же не проверены достаточно временем.

Как сказано в китайской поговорке - насыщает не время проведенное в столовой, а количество съеденных беляшей. А про это вы ничего не сказали.

> разработчики Skein не шибко много делают реализаций (промышленных, а не неких эталонных).

А "промышленности" подсунули "секурный" крап типа ssl. Кушайте г-но в промышленных масштабах.

> Всё вы тычите в крайность в виде OpenSSL.

А во что бы тыкали вы?

> Крайне не согласен что криптография от реализации в софте конкретной не далеко друг от друга.

ИМХО зависит от.

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

Это яркий пример того что ваша толпа обезьян с гранатами мало что решают. Оно с нами давно, сорцы есть. А крЮтые плюхи находят через много лет после того как это появилось. И еще найдут. Много и злых.

> считал безопасным: пока я не доверяю в достаточной мере ECC и
> использовать lsh например в котором не ECC не будет --

А как по мне - так я лучше буду доверять Бернштейну и его ECC, чем RSA. У той же RSA было много неудачных или в лучшем случае заурядных алгоритмов на которые они не забывали давиться жабой. И dual ec с бэкдором они продавали.

> я не буду. Тем более что они туда собираются встраивать и AES.

Они - кто? Те перцы с мелким ssh серваком? Это было лишь как пример мышления в правильном направлении.

> поддержкой SRP.

Я опять же не особо понимаю чем этот SRP так хорош. Его как-то агрессивно сватают без внятных аргументов за. Мне это не нравится.

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

Мне кажется что я в состоянии прочитать матюки авторов Tor в ченжлоге на такую подставу в поведении openssl. Им пришлось ЯВНО ВОРКЭРАУНДИТЬ это западло.

> Думаю из-за своей старости и относительной простоты Blowfish излюбленный алгоритм для большинства
> кто собирается заниматься криптоанализом.

Одного взгляда на оный достаточно для того чтобы понять что cache timing и его скорее всего пробирают от души. А еще там слабые ключи нашлись. Хилые аргументы "за".

> Dual-EC-чего-то-там показали что вообще неприменимое.

Ну так это ж NIST. По этому поводу NISTовским кривым я доверять не буду. Мало ли как они их там выбирали. А вот DJB рассказал откуда взялся 25519.

> что в Salsa/Chacha ещё не найдут чего-то реально критичного сводящего
> на нет всю его безопасность,

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

> как и в 25519 и то что из-за него весь PFS идёт нафиг и смогут дешифровать ранее
> сохранённый трафик.

Возможно, но с другой стороны это же теоретически может случиться и для RSA. С другой стороны RSA тормозной и у него огромные ключи (при желании хоть какой-то надежности). А криптография - о том чтобы заменить большой секрет маленьким. RSA на больших ключах так тормозит, что для получения приемлимой скорости часто жертвуют стойкостью. Прозрачные намеки DJB на то что у "спецов по безопасности" - ключ RSA всего 1024 бита. Больше видите ли тормозит. А у DJB стойкость на уровне RSA 2048, при скорости многократно выше RSA 1024.

> Однозначно его будут и яро анализируют, но лично для меня должно пройти ещё время.

Он появился не вчера и прямо под носом толпы криптографов. При том относительно независимых, а не прикормленных, как NIST.

> А это годы, ведь и AES не сразу оказался поломанным (до какой-то степени конечно).

С точки зрения криптографической стойкости самой по себе - к AES до сих пор нет больших претензий. Но вот сама схема с таблицами как минимум проблемна в современных реалиях с многозадачными многопользовательскими системами и тем более контейнерами/виртуалками. Более того, репорт от NIST утверждающий что эти операции завершаются за постоянное время или некомпетентен или специально врет. Оба варианта NIST не украшают.

> Мнение кодеров меня тоже не волнует, а вот мнение 10 криптографов -- маловато.

Криптография штука сложная и компетентных криптографов не так уж и много. Так что 10 человек которые предприняли реально хороший криптоанализ - достаточно прилично. И некие результаты будут. Бернштейн опубликовал таковые. Там нашлись атаки на ослабленный вариант, но ничего практически значимого.

> На полном серьёзе. AES анализировали многие годы явно больше 10
> и не находили сильных подвохов

Кроме его табличной сущности и возможности в результате умыкнуть ключ на половине конфиг. И вранья от NIST про это.

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

Древность алгоритма не влияет на наличие или отсутствие в нем ошибок. А на поиск ошибок влияет количество компетентных криптографов сунувших туда нос. Бернштейн достаточно известен в кругу криптографов - на его художества посмотрит толпа народа. Более того - все эти алгоритмы взяли в ssh. И вы уж извините, но если авторам ssh нормально, а какому-то чудаку с опеннета нет - я как-нибудь им и DJB больше верю.

>> если нет WPS и сложный пароль - мне не известно.
> Лучше не рисковать :-)

С этим не поспоришь - ценные данные лучше по проводу или с добавочным шифрованием.

> делали его люди с участием корпораций и госструктур, что априори вводит в недоверие.

Ну да. С другой стороны фундаментальных проблем пока вроде не нашли. И нахрапистый внедреж бэкдорообразного WPS и инженерных паролей наводит на мысль что случайно вышло слишком стойко для произвольного вламывания в сеть за обозримое время.

> В том что Blowfish смотрели тьма профессиональных криптографов у меня сомнений нет.

Ну так они и нашли там слабые ключи, http://www.iacr.org/archive/fse2007/45930168/45930168.pdf Ну и опять нечто с s-box. На это забил даже автор - см threefish.

> Кодеры не интересуют само собой. Компетенция глаз -- выше всего. Опять
> же для алгоритма.

Так возможность за разумное время прочитать алгоритм и все что вокруг и позволяет проверить что все честно. А навали кучу хлама как в openssl или ssh, с кучей костылей, легаси и прочее - да там чтобы въехать надо месяц убить. Желающих это читать будет мало. Особенно среди криптографов.

> Тут могут пригодится и быдлoкодеры.

Они ничего не смыслят в применении криптографии и даже просто безопасности. Толку с них?

> Либо "профиксить" SSH-протокол (добавить опцию?) чтобы он сам делал нужный padding.

Может быть. Но ssh уже обвешан костылями и легаси как собака блохами. Когда фича опциональна - плохо. Админ не в курсе на что он может рассчитывать если видит "вот это соединение".

> кстати по мне так "шуметь" в канал. Надёжнее не бывает

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

> GNUnet всё ж выбирает безопасность/анонимность превыше всего и поэтому шум есть всегда и везде.

У них есть немало интересных изобретений/наработок, не отнять.

> Очень уважаю их. Но реализация не простая, даже поднять не просто бывает.

Реализация у них получилась странная. Но ряд идей у них очень интересные.

> Либо вменяемый человек, либо тот который даже fingerprint не будет проверять

Любого неглупого человека можно попросить проверить fingerprint. Хотя в 25519 это излишне - размер ключа позволяет прямое указание ключа вместо fingerprint.

> По моему опыту как бы только "ракетные инженеры" способны выполнить хотя бы сверку fingerprint-а.

Имеется опыт объяснения этой операции чайниковатым юзерям.

> человек-ракетчик, либо тот кто тыкает ok на всё подряд.

Этот мир не черно-белый. Между полюсами немало градаций.

> даже не в состоянии передавать ему nonce-ы которые бы не повторялись

У DJB размер nonce таков что можно даже просто random. И, заметим, про nonce все предельно четко и подробно расписано.

> или чтобы люди не использовали ключи для потоковых шифров дважды.

Практически существующие схемы обычно это учитывают.

> быть сложно? cryptobox NaCl-овский как-то помогает.

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

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

Составные части - для тех кто понимает что и зачем он делает.

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

Поэтому для таких людей есть cryptobox.

> И то что сейчас тьма людей-программистов начитавшись о прелестях Salsa/Chacha побегут
> её всюду реализовывать приведёт я уверен к большей катастрофичности

Любую криптографию можно профакапить некомпетентностью.

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

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

> Но, повторюсь, просто Blowfish не могут использовать.

Blowfish морально устарел и никакого смысла в нем имхо нет.

> приличного видеопотока было бы полезно ещё как), но зато это можно
> реализовать всем быдлoкодерам.

Бернштейн имхо в этом правее: таким людям *нечего* делать в низкоуровневых деталях алгоритмов. Таким надо апи по типу криптобокса. Это он очень правильно заметил.

> Salsa сложнее и это пусть создаст код с меньшим количеством чисто программных багов (из-за его размеров),

У DJB есть либа. У нее есть вызовы, которые если дергать как описано - все будет ок. А вручную заморачиваться с salsa есть смысл только для тех кто знает что это, зачем и как это правильно применять. А обычные апликушники должны дергать криптобокс, а вовсе не.

> например. Надёжно, но сомневаюсь что старый Blowfish с старым HMAC-RIPEMD160 будет
> медленнее, а надёжность у них для меня выше.

Вот вы ими и пользуйтесь. А мне как-то неохота греть мозг вопросом "а что еще может работать на том же процессоре".

> в SSH-е где утекает plaintext.

И дофига информации о характере траффика. Если некто смог угадать что там передавали по параметрам траффика - толку то с шифрования?

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

Для таких и сделано апи в духе криптобокса.

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

Для тех кто не Шнайер - есть криптобокс. И там если следовать нехитрым правилам из коротенькой инструкции - все будет ок. Если кто не может даже это - пусть идет выращивать овощи. Кому надо симметричное шифрование - там и для него есть похожий вызов. А если кто полез в детали и лоханулся - так обезьян с гранатой лучше обойти сторонкой.

> Не согласен. Уже выше написал. Примитивов меньше, а сами по себе они сложнее.

Еще раз: апликушники должны дергать cryptobox и не должны париться какие там алгоритмы. Возможность дергать составные части - для тех кто в курсе что это и как этим пользоваться.

> не правильно будут юзать как и не в состоянии сделать Blowfish-CTR допустим.

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

> NaCl не предоставляет протоколов как-таковых.

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

> NaCl это низкоуровневые примитивы которых грамотно реализованых в том же libgcrypt
> полно. По поводу протоколов он не поможет, а ломают в первую очередь их.

NaCl - это базовый кирпичик для передачи данных в шифрованном виде с использованием публичных или симметричных ключей. С апи которое обычные апликушники могут использовать не наломав дров. Продвинутости - не для них.

> IMHO это основной критерий.

Тогда шифр Цезаря FTW.

> выпускает свой убер-алгоритм, за пару недель его ревьювят с десяток Шнайеров
> с Фергуссонами и круто его можно использовать.

Упомянутые алгоритмы существуют как минимум несколько лет. И да, вы знаете, по ходу пьесы всплывают разные нюансы, типа возможности реконструкции ключей по состоянию кэша. И это приходится дорабатывать на ходу. А в вашем настое это ТАК И ОСТАНЕТСЯ. И даже те кто оригинал blowfish делал - признали ошибки, "наследник" threefish - без s-box. Но куда там Шнайеру и его работе над ошибками до ваших догм про настой.

Вот лично я предпочитаю видеть осмысленное и поддающееся логическому пониманию конструирование алгоритмов. А догмы высосанные из пальца - не ко мне.

> Вроде бы история с MD5, SHA1, AES показала что нужны многие годы

Про MD5 уже через пару лет после его выхода была критика и предлагали списать в утиль. Но вылезли удоды вякавшие про скорость и стандарты и заглохди лишь когда массово поперли коллизии. Да и с AES предъявы к таблицам были давно по части кэшей. Но всякие "умники" зачем-то втюхивают алгоритмы с неочевидными проблемами, накладывающими много ограничений на область применения. Всего ничего: возможность для соседнего процесса/вм/контейнра упереть ключ.

> самый криптограф который надёт жщпу.

В md5 ее нашли быстро. Но любителей "стандартов" это не остановило. Им понятен только pwnage.

> Вы считаете что тот же Blowfish или RIPEMD видимо просто мало криптоанализировали:

Я уточнил. Blowfish криптоанализировали. И нашли проблемы. Да что там, даже я их вижу - пачка s-box это отрыв от современных реалий и пофигизм на проблемы эксплуатационщиков.

> это просто ваше заблуждение.

А может ваше? Я существо рациональное. Мне нормальные аргументы подавай и внятную логическую цепочку. А этого я не вижу. В частности ваши сведения про AES и MD5 имхо неверны. И грабли в blowfish видят все. Даже его автор. Который (совместно с еще рядом людей) сделал работу над ошибками. Threefish называется.

> Сколько долгих лет понадобилось чтобы найти фатальные недостатки?

Мало. Про md5 предупреждения о его фиговых свойствах появились довольно быстро. То что до некоторых как до жирафов доходило и понадобилось чтобы конкретно бомбануло - второй вопрос. И грабли с утечкой через кэш - штука не новая. Но NIST их почему-то проигнорировал. Еще и соврали про постоянное время. Подозрительная некомпетентность.

> через несколько часов после их выхода, какие-то годами.

С основателями RSA все довольно интересно. Как-то так оказалось что большинство их алгоритмов - гэ. И вообще, RSA - контора которая единственная обнаглела и подсунула клиентам пробэкдоренный Dual EC :).

> очевидно и история показала неоднократно.

Похоже на слепое следование ничем не обоснованной догме, если не подтасовку фактов.

> Те же методы анализа для DES через сколько десятилетий появлялись

Многие криптографы сказали еще на момент принятия DES что его сломают. Просто потому что ключ короткий. Время лишь показало что они были правы. Но предупреждения о том что ключ 56 битов мало были буквально на момент принятия. То что до некоторых долго доходит, а железо стало практичным для этого не сразу - не вина криптографов.

> Но Blowfish не просто так внедряется в кучу софта,

MD5 или даже Dual EC тоже внедряется, а openssl вообще везде. И?

> хотя Шнайер давно уже советует использовать Twofish,

...и принял участие в создании threefish. Который работа над ошибками. В частности - никаких s-box! И чего бы это вдруг? Ах, он тоже догадался что утекать состояние через кэш - хреновая идея :). Но вы цепляйтесь, изгибайтесь буквой зю, ставьте 100500 условий где это нельзя пользовать. Ведь грабли хороши именно тогда, когда про них забыли и они все-таки е...ли по лбу.

> того же iacr.org. Известнейшие криптографы (Бихамы и Шамиры регулярно видел) и
> криптоаналитики просто регулярно штампуют исследования и подходы даже к старью.

Там у них как раз вон дока с описанием слабых ключей blowfish. А Шнайер пошел переделывать алгоритм, чтобы не утекал данные через кэш. Для него это аргумент, в отличие от вас. Но если хочется упереться рогом - можно использовать и устаревший алгоритм и греть себе мозг отсевом слабых ключей и вопросами что еще запущено на том же CPU. Дело хозяйское. А мне так не нравится.

> Вот у меня уже впечатление что просто прочитали какой у Бернштейна всё
> быстрое и ещё не сломанное и внедрили первым, плюс код простой.

Скорее, почитал и подивился что довольно разумно сделано, либа удачно подогнана, алгоритмы скомпонованы с умом и попытками избежать типичные грабли предшественников при хороших свойствах (качественная диффузия не в ущерб скорости). Но все юзают какой-то проблемый кривой шит или как минимум алгоритмы вызывающие вопросы. На мое персональное мнение DJB здорово недооценен по целому ряду пунктов (еще он мнение про IPv6 высказывал). Что характерно, хуже от этого будет в основном не ему.

> А дальше раскрыли свою суть что в целом пофиг на безопасность и NIST.

NIST себя делом дискредитировал. Dual EC DRBG с бэкдором кто стандартизировал? А RSA всучили его клиентам. Ну вы как бы пользуйтесь софтом от RSA, по стандартам NIST - идеальный шторм! :).

> Всё как я и "предсказал" параграфами выше: толпы пойдут
> реализовывать потоковые шифры Бернштейна, которые использовать сложнее.

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

> ещё фигово проверенные в бою ECC -- мой выбор за RSA, старый недобрый но надёжный.

Вообще-то из за тормозливости надежность часто приносят в жертву. В том числе в DNSSEC. Который судя по всему еще одна бесполезная декорация по типу SSL будет.

> Если есть под рукой доверяемая реализация.

Никакая реализация не меняет общие свойства алгоритма. RSA слоупочное нечто, которому для надежности нужны немеряного размера ключи. Которые сложно передавать и поэтому надо костыли с фингерпринтами. Ибо 2048-битный ключ фиг надиктуешь по телефону, в отличие от 256-битного.

> Всё относительно. По мне так ECC ещё не доказано что полностью сводится
> к проблемам нахождения точек на кривых.

А к чему еще оно может сводиться? Ну кроме случаев явного бэкдоринга.

> уже всякие NIST и ФСБ знают чего-то,

Так они это могут знать про AES или RSA. Впрочем про них и так все знают что AES течет ключи через кэш а RSA при нормальном уровне безопасности тормознут до некомфортных величин. Что нагибает ряд применений, как с DNSSEC, где по причинам производительности выбран короткий ключ.

> до чего Шнайеры с Бернштейнами не дошли.

У Шнайера и Берштейна есть жирный плюс: они не были замечены в западлостроительной активности. В отличие от RSA и NIST, например.

> Ведь Dual-ECDRBG не сразу "раскрылся". Сколько его использовали
> и сколько PRNG фактически не работали в мире?

Ну да, NIST успел стандартизировать а RSA - втюхнуть клиентам. Такие вот стандартизаторы и криптоаналитики.

> что надо конкретно обезопасить я делаю с RSA, а всякие сессии до серверов где работа
> или домашняя утварь: ради уж производительности на 25519.

ИМХО, тезис о том что RSA безопаснее чем нечто еще - вилами по воде писан.

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

Вообще worldwide. Так можно послать ОДИН ПАКЕТ. Без хэндшейков и прочего. Сетевое шифрование должно было быть каким-то таким с самого начала.

> Ой вот сомневаюсь что долго будет жить сам по себе софт в
> котором нет никакого протокола :-).

Смотря что от него надо. Cryptobox обеспечивает защиту и неподделываемость пакета. Если ремота может его расшифровать - это пакет который сформировал отправитель. С другой стороны, поскольку это по факту DH, из половинки приватного и публичного ключа, но разные половинки с разных сторон линка - получатель знает shared секрет и может произвольно подделывать содержимое. И не может доказать что ему это прислали а не он сам это сгенерил.

В чем круть? В том что зная 32 байта можно пульнуть сообщение которые расшифрует только обладатель парного им привкея и у него будут гарантии что это сформировал обладатель вон того пубкея. Все это дает ряд интересных возможностей о которых вы, вероятно, никогда не задумывались. Например, обмен ЕДИНИЧНЫМИ ПАКЕТАМИ. DH без хэндшейка? Почему бы и нет?

Универсальная верификация и шифрование 32 байтами - публичным ключом, влобовую. Из очевидных вещей - надо защиту от реплея. Если надо. Ну там timestamp или sequence number. Ну и PFS прикрутить. Несложно сделать путем перекидывания сообщениями с новыми ключами в обе стороны линка. А аутентичность сторон гарантирована на уровне устройства сryptobox.

Т.е. почти нахаляву можно отбабахивать P2P-style протоколы где peer однозначно идентифицирован 32 байтами. Да еще по сути без handshake.

> протокол. А все ошибки будут только и только в нём, а
> не в примитивах низкоуровневых. https://github.com/stargrave/govpn

Не очень понятен смысл в PSK при том что с каждой из сторон линка можно было бы просто добавлять долговременый публичный ключ противоположной стороны как "доверяемый" (в конфиг, etc). Он и ключ шифрования (как минимум для начала сессии) и замена fingerprint. Для повышенной анонимности передавать публичные ключи сторон опционально: можно их неявно подразумевать на основе например прописаных в конфиге, etс (можно и более интересные варианты придумать). Ну и PFS разумеется - сделать пару временных ключей с каждой стороны и перекинуть в начале сессии в первых сообщениях новые публичные ключи. Судя по всему получается похоже по смыслу на то что у вас, только с другого бока и можно готовый cryptobox юзануть. Такой вариант чем-то плох?

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

А какой 25519 стандарт? Его кто-то успел стандартизировать?