> Некрайностей в смысле того что это в состоянии люди посмотреть в плане ревью? GnuTLS.

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

> Ну… понятно: у вас хуже TLS как протокола и реализации в виде OpenSSL нет.

Я как-то видел загадочную атаку. Поимели группу серверов. Тогда никто не понял как хакеры смогли унести кучу логинов/паролей на ровном месте, не наследив в системах, да еще с обещанием "мониторить всегда". При том что все SSL было обвешано. А вот heartbleed хорошо объясняет такие особенности. Кренделя видимо уперли через .. протокол защиты траффика. Сдампили память, нашли кренделя. Хорошая защита траффика :).

> Понятно. CryptoCat для меня на данный момент ярчайший пример

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

> тогда были времена в которые не столь хорошо всё ещё изучили.

В криптографии надо думать головой и если уж лезть в низкоуровневые дела самому - надо думать как атакующий. В контексте "а какую информацию можно извлечь?" и "а что если креативно кормить протокол нестандартными данными?". При достаточном уровне паранои удастся отсеять явно провальные решения в пользу решений где очевидных ляпов нет. Если повезет то может так получиться и остальные не смогут найти продолбов.

> С точки зрения реализации конкретно TLS я знаком с OpenSSL и
> GnuTLS: второй однозначно мой выбор, но увиденное в первом оставляет куда
> лучшее впечатление от cryptocat-ов.

Как ни реализуй огроменный переусложненный протокол, с кучей левых опций, с грузом легаси и "совместимости" - лажи будет много. Придется писать кучу кода. В куче кода - куча багов. DJB про это недвусмысленно сказал.

> TLS сложный, как и всё что делается коммитетами. Но у меня нареканий
> как к протоколу (кроме сложности) не много.

Зато их было у меня. И за некоторое время до пуделя я предположил что атакующие могут даунгрейдить протокол, раз уж там куча легаси. И тут на тебе - пудель. Как раз основанный на даунгрейде до старой верии. EPIC!!!

> А дальше реализации во всём виноваты.

Спецификации виноваты в переусложненности и таскании кучи опций и легаси. Это приводит к тому что написать без ляпов малореально, а выбрать безопасные параметры - рокетсайнс. А какие там где дефолты и насколько безопасны - разобраться в этом при такой сложности протокола тоже рокетсайнс. Апликушники хотели защиту траффа от точки A до точки B. И ни в зуб ногой в этих опциях, требующих для въезда в них квалификацию на уровне "Брюс Всемогущий". Невозможно к каждому автору мелкой софтинки приставить по Шнайеру или Бернштейну. TLS - пример как НЕ НАДО делать такие протоколы. А то что реализаторы лажаются - им сильно помогли. Накидав банановых шкурок под ноги в спеках. Так странно что реализаторы поскальзываются!

> Сложнее чем TLS могу показать: IPsec.

Еще один пример гуано, единственным достоинством которого является "зато стандарт". И уже не сильно новый.

> SSHv2 без -etm, cryptocat.

Они смогли фатально облажаться на уровне heartbleed, так чтобы через это хакеры разнесли целые энтерпрайзы?

> В моём мире подразумевается что в столовой не сидят без дела, а едят беляши :-).

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

> Всякие Blowfish и прочие до сих пор берутся для "тренировок".

Ну вот видите, я ему могу кое-что предъявить даже при том что я в общем то не криптограф. В том плане что я понимаю что моей квалификации недостаточно для конструирования "кульного алгоритма шифрования".

> и как протокол на бумаге ужасен, но для меня нет.

А для меня - да. Потому что переусложненный крап, с кучей лишних опций и легаси. При том все это цепляние за легаси и "совместимость" - как правило приводит к предсказуемым классам атак "MITM может задаунгрейдить протокол". А потом отпинать старенький не особо секурный вариант, сильно скостив трудоемкость задачи. Так заканчиваются блеяния про совместимось и стандарты. Ах да, приветы от пуделя - он как раз об этом. Заметьте, скелетов из шкафов начали немного вынимать только после этого. Но оно такое там ВЕЗДЕ. Так что тот факт что в openssl находят пару CVE той или иной степени серьезности в месяц - перестал удивлять. Да и остальным достанется. Ну может polarssl чуть поменьше, а другим чуть побольше. А то что этот ворох костылей можно реализовать без багов - крайне сомнительно.

> само крипто можно посмотреть. Простое и грамотное. Ревью проводилось.

А тут на опеннетике некий неизвестный сказал что openvpn в дефолтной конфигурации просто небезопасен. И я кажется понимаю что он имел в виду.

Всего ничего. По дефолту там IIRC нет проверки идентити ремотного сервера. Это надо явно возжелать и прописать. Или вот например perfect forward secrecy. Про него надо явно узнать и захотеть. А если вы не спец в криптографии - вас ждет немало подстав, которые вы забудете разминировать (или просто не узнаете что надо). Нет, я думаю что криптография не должна работать в режиме "ха-ха, лох, забыл дома миноискатель? А мы вот удачно положили тебе мину! На!". Спасибо, мне не хочется пользоваться софтом который кишит малоочевидным западлом. И весь SSL/TLS по этому поводу достоен списания в утиль - состоит из западла и капканов чуть более чем полностью. С аргументами что все это для нашей же безопасности или накрайняк совместимости и стандартов.

> Под RSA я подразумевал только конкретно RSA алгоритм, а не компанию.

А с чего вдруг авторам алгоритма такое безоговорочное доверие при сомнительных делишках основанной ими компании? Тут надо детально трассировать в какой момент им стало хотеться денег и они переключились в режим "деньги не пахнут". Мне это обломно, поэтому я им доверять не буду. Хотя на сам RSA из предъяв разве что то что он тормозной и у него огромные ключи. При том для сколь-нибудь серьезной надежности ключи надо реально громадные, а работа с ними происходит крайне медленно. Так что схемы шифрования по этому поводу жестоко костылят. А все-равно какой-нибудь выводок ботов сильно грузит ssh с RSA, если мер не принимать.

> Хотя… там работают очень и очень крутые криптографы.

...озадаченные задачей "как бы втихаря нагадить и не спалиться", например. Так что они может и крутые, а вот их задачи и мотивация может быть и "деньги не пахнут".

> Кстати нет гарантий что Бернштейн давно куплен и недаром даже Google
> проталкивает (или уже даже в Chrome реализовала) chacha/poly в TLS.

Он какой-то скромный академик, сделавший 25519, salsa, chacha и прочее довольно давно, не пиарившись и не создавая корпорации на тот момент. И не продавливаемый в стандарты. А то что после ряда кризисов SSL/TLS, краха доверия к NIST из-за стандартизации бэкдореного ГПСЧ и прочая на него и его алгоритмы обратили больше внимания - это предсказуемо. Ибо некая альтернатива стандартному ГOBHУ востребована. И к тому же от человека не рвущегося с пеной у рта МОНЕТИЗИРОВАТЬ!!111 как корпорасы по типу RSA и не запалившиеся на подлянах как стандартизаторы из NIST - это очень кстати. Тем более что на все это смотрит толпа криптографов и их всех покупать задолбаешься. А еще DJB не врет внаглую как NIST, втирающий очки про то что лукап таблиц занимает постоянное время. То что он говорит - согласуется с мнением других криптографов. В отличие от пурги из NIST, которую все независимые криптографы дружно обоcpaли и сделали НеСтандартные алгоритмы, лишенные проблем Стандарта(тм). Ну и ему и его алгоритмам доверяют даже опенбсдшники.

> С одной стороны Google может это делать чтобы казаться хорошей,

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

> Хотя вроде Бернштейну стоит больше доверять чем Шнайеру, ведь тот же тоже
> вроде как засветился работой на оборонку.

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

> В корне не согласен что у них правильное направление.

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

> показалось что они "правильные". Вообще не признаю я их уже.

Мне тоже не понравились их потуги впихивать новые алгоритмы без особой аргументации "за" и судя по всему без особого понимания что и зачем они делают. Но даже обезьяна с гранатой иногда может метнуть гранату в правильную сторону, хоть это и случайность :)

> посоветовал просто посмотреть на страничку его родную: http://srp.stanford.edu/.

[...]
Посмотрел, именно там (заявы про SSL/TLS меня чуть не спугнули правла).
И имею заметить:
1) Он сам по себе шлет идентити юзера влобешник. Отлично, гудбай приваси. Всему миру видно что на сервак в хренадцать часов логинился именно Вася.
1.1) Конечно там что-то про TLS, но что я думаю о этом выводке протоколов и куда ему пойти - вы в курсе, да?
2) Оно почему-то переклинено на клиентсерверной модели и потому однобокое. Вообще-то, по идее хотелось бы верификацию *обоих* участников линка друг другом, НО чтобы остальным не было видно какие идентити представили друг другу эти участники. Иначе какая ж это секурити с учетом современных реалий, когда NSA и даже ФСБ даже не скрывают что хотят знать какие учетки, куда и когда. Субъективно - такое можно сделать хоть из DJBшного криптобокса. Перекидывая минимум пакетов и храня минимум информации. И симметрично. Хотя при желании можно и даунгрейднуть до однобокого. Хоть я и не понимаю почему на проблемы клиента должно быть пофигу и почему надо вообще жестко делить на клиента и сервера.
2.1) Общая идея напомнила мне какую-то странную и несколько однобокую реализацию диффи-хеллмана, чтоли.

> Вот например в языке Go соорудили собственную TLS библиотеку с нуля.

Я их с этим поздравляю. Языку для хипстеров и секурити под стать. Пусть пользуются им наздоровье, верят в безопасность TLS и прочая, а я пешком постою. Мне этот ваш Go - ни в п..., ни в красну армию. А что я думаю про TLS - вы уже видели. Ну и их кульные библиотеки на go с TLS понятно куда могут идти, имхо. И гугле я в целом не особо доверяю - они по жизни барыжат приваси пользователей. Крупным оптом.

> ноют и не могут выбрать другую (кроме GnuTLS и ещё есть)
> или взять и написать свою, свою обёртку?

Они просто написали небольшую заметку в ченжлог, показывающую насколько крындец в openssl с пониманием криптографии и как это должно работать.

> них ущербный TLS это как-то не сходится. Хотят наверное скорости и
> аппаратного ускорения и прочего:

Это все хотят. А еще хотелось бы чтобы либа не подкладывала при этом свинью. А если некто запросил аппаратное ускорение, а ему в апликуху напрямую сплюнули вывод аппаратного RNG, нисколько не парясь что он может быть пробэкдореный - это пипец! Даже разработчики линуха это понимают, предпочитая подмешивать вывод такого RNG в общий пул, так что в самом плохом случае - качество пула останется на том же уровне что и было, а атакующий не сможет ничего предсказывать, хоть там этот железячный RNG сто раз не случайный будет. А эти напрямую апликухе его. Совсем без пула энтропии и других источников. Вот те раз. Оказывается чтобы поюзать какой-нибудь аппаратный AES или SHA, надо бонусом получить потенциально неслучайные числа везде. Здорово придумано!

> чтобы ещё и на всех платформах работа и не пришлось поддерживать руками?

Начались аргументы в стиле "почему кушать г-но это вкусно и питательно"?

> Ох как же не нравится меня этот Tor, ибо ну всё очень не чисто.

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

> кирдык и ничего на основе Sbox-ов юзать нельзя.

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

> Каждый только и будет что из кэша легко доставать данные.

Ну я понимаю что некоторым надо крындец размером с heartbleed или как минимум с пуделя чтобы осознать очевидное. А мне такой подход кажется недальновидным.

> Можно написать реализации где кэш будет хорошенько засоряться,

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

> не будет прогрет: это медленнее, но безопаснее.

А операции регистр-регистр и быстрые и вообще не требуют лазить в кэш. Наверное это объясняет почему криптографы обратили на них внимание и забили на схемы с s-box и т.п.? ;)

> Опять же нефиг запускать недоверяемый софт (закрытый и проприетарный в первую
> очередь подразумеваю).

На х86 машине почти всегда есть как минимум обработчик SMM в максимально привилегированном режиме. Который нельзя вырубить средствами ОС вообще совсем никак. Если уж мы о грустном.

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

Вообще-то
1) Волнует. Поэтому криптографы в курсе что ключ живет ровно столько сколько нужен.
1.1) есть даже параноидальная версия AES, где ключ хранится в регистрах. Только AFAIK тормозная очень.
2) Память в нормальных ОС все-таки защищается друг от друга и даже чистится при отдаче другой программе. Времена win95 все-таки прошли.
3) Особо любопытные могут посмотреть например как биткоин с шифрованным кошельком поступает в том же линухе для минимизации шансов утечек.

> Разве что OpenBSD сильно что-то пытается сделать в этих условиях, но опять же
> от атак в виде какого-нибудь firewire с его DMA тоже не защищали.

Если у злодея есть физический доступ - он много чего сможет. Но если уж на то пошло, современное железо обычно имеет IOMMU. Это надо для проброса девайсов в виртуалки, поскольку в виртуалке ничего не подозревающий драйвер будет програмить "свою" железку, понятия не имея что она на хосте, а DMA со стороны железки при этом в два счета выносит память хоста, т.к. железка понятия не имеет что это не хост просил. Это ведет к краху хоста. Так что такие инициативы нынче активно зарубаются IOMMU (в случае виртуализации это будет редиректнуто в VM, а если это "само по себе" - в логе ядра будут вопли, а запись обломается). А что, опенбсдшники уже умеют с IOMMU работать, раз мы про DMA?

> Вот чего чего, а атаковать кэш будут в последнюю очередь,

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

> так как масса способов добраться до просто участка памяти в RAM.

Одно дело если атакующий должен кабель к компу цеплять и его может обломать iommu, и совсем иное - если атакующему достаточно плюхнуть контейнер или вм на тот же хост и подождать. Что там насчет рисков? :)

> По мне так вы не правильно взешиваете риски.

А как по мне - в самый раз. Вышеупомянутый сценарий атаки - подсмотрен на примере реального взлома, только "адаптирован" под иную цель: атаку на виртуализаторы и контейнеры. Заметьте, для этого не надо никакого особого доступа. Достаточно закосить под клиента хостера и за несколько попыток пристроиться на нужную машину. И все.

> до сих пор те же HMAC-MD5, в отличии от MD5 можно [..]

Можно даже бегать в ластах и противогазе по снегу вместо того чтобы взять лыжи. Но зачем?

> Но сколько RSA лет, а сколько лет DJB.

Этот аргумент ничего не говорит про "количество беляшей".

> (ну кроме DH) алгоритмов мурыжили больше всех криптографов.

А в результате нас потчуют DNSSEC с 1024-битными ключами. Замечательно.

> Криптография чтобы заменить большой секрет маленьким? Впервые такое слышу, честно говоря.

Если бы это было не так - пользовались бы одноразовыми блокнотами и не парились. Что-то вы не больно идете создателю опеннета свой блокнот заносить, а? Ну и я тоже.

> одноразовые шифроблокноты всё-таки до сих пор используют,

Только их юзабилити хромает и потому они очень нишевое нечто. Если посмотреть, поточные шифры - попытка получить то же самое, только с сокращением секрета до инициализатора PRNG. Более практично получается.

> Криптография всё-таки не только об уменьшении секрета :-).

Не только. Но если уж на то пошло - я могу и лично отнести письмо, проверив что его прочитал только получатель.

> чётко ограничен килобитом. RSA юзайте хоть 4k.

Только ждать загнешься. А при коммуникациях по сети - ремотные машины могут сильно грузить на ровном месте "интересную мишень". Да и передавать публичный ключ в 4Кбит не сильно практично. В SMS не отправишь, с клавиатуры не набьешь. Для проверки придется отдельный более компактный fingerprint считать. Лишняя операция и куча грабель на ровном месте.

> DJB стойкость на уровне 2k -- верно. Для кого-то этого может быть недостаточно.
> Шнайеры говорят что хватит, но и они не 100% доверяемые авторитеты.

В обозримом будущем 128 битов и более - должно хватить. Даже с учетом Мура, 2^128 - довольно много.

> минимальный требуемый уровень,

А почему тогда в DNSSEC смеют использовать 1024-битные ключи и впаривать сие?

> а вот у DJB нет запаса выше ибо он на этом минимуме.

Осталось найти тех кто реально пользовался бы 4096 битными ключами RSA.

> быстрых временных линков типа SSH/TLS/VPN. Но передавать поверх него что-то убер
> важное уже рисковано (для меня из-за отсутствия запаса прочности).

Смотря что понимать под запасом. Если мы рассматриваем взлом 128 бит - это наверное про квантовые компьютеры. А в этом случае есть мнения что для публичной криптографии которая устоит даже против них - надо смотреть на иную математику, где есть уверенность что специфичные свойства квантовых компьютеров не приведут к серьезному повышению эффективности взлома. Если эти упрощения получатся, RSA при этом завалится не лучше и не хуже эллиптических кривых, насколько я понимаю мнения криптографов. Симметричные шифры - где как, но сам по себе лобовой перебор 256 битов - не получится вообще совсем никак. Энергии не хватит на обсчет, чисто технически.

> Чую что всяких Шамиров вы не признаёте :-). Хотя их компетенция в
> виду даже возраста и тупо опыта я думаю запросто выше.

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

> Известных типа Шамира, BS, DJB конечно не очень.

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

> И никто не знает не связан ли DJB с госами,

По логике вещей, если бы был связан и там было бы что-то не так - его схемы внедряли бы намного раньше, нахраписто продвигали бы в стандарты и заваливали деньгами на успешные стартапы и масс-впаривание. Уж NIST наверняка смотрел бы не на какие-то свои кривые, а первым делом и схапал бы 25519, бонусом к dual EC. Вот только почему-то к Dual EC предъявы были, а 25519 с нами уже не первый год, но ничего такого этой кривой не предъявили.

> анализы, но там парни в ФСБ и АНБ давно знают уязвимости?

Наверное именно поэтому они подставили NIST и RSA с алгоритмом, в котором криптографы довольно быстро нащупали бэкдор. А какая логика в такой деятельности тогда, собственно?

> Ведь Dual-ы и другие ослабления как в Rijndael и прочих придумывают парни оттуда,

И что характерно - потом с нахрапом заталкивают в стандарты и размахивают аргументом "зато СТАНДАРТ!".

> наше ФСБ это самые крупные наниматели математиков.

Теории заговора это круто, но если в способность АНБ платить крутым спецам конкурентоспособные зарплаты и создать не слишком дискомфортную рабочую атмосферу я еще со скрипом поверю, то способность ФСБ делать это вызывает определенные сомнения.

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

> не реализуемы (если юзать реализацию проверяющую на слабые ключи).

Ну да, а то что табличная сущность утекает состояние алгоритма наружу мы будем игнорировать? Пока не долбанет в лоб на уровне heartbleed, да?

> Даже автор советует юзать Twofish хотя бы, но не говорит что BF надо
> взять и выкинуть.

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

> Я бы опасался куда больше ОС которые дадут умыкнуть ключ просто из памяти.

Просто - не дадут. Нынче вам не MS-DOS и даже не win95. И MMU появились не вчера.

> их компетенция на нуле у меня после этого.

Если честно - по моему нескромному мнению ssh давно пора переделать. По итогам грабель. И снеся совметимость с старьем. Сделав padding, убив все граблеопасные алгоритмы и кучу легаси барахла. А личное пожелание - вытряхнуть оттуда все кроме секурного шелла. А остальное - оформить либу и отдельные программы, на основе той же технологии, но - именно отдельные. А не макаронный монстр который и поганый впн и инопланетный портфорвардер и горбатая файлокачалка и что там еще.

> имеет корни в Тео Де Раадте, который мужик очень правильный и
> запросто только благодаря нему мы получили -etm, ну и DJB-related штуки.

А он вообще в криптографии разбирается? Большинство его аргументов обычно больше похожи на чесание ЧСВ.

> TLS как таковой.

TLS как таковой факинли сложный и речь о аудите просто не идет.

> Тут вы не правы в одном: хотели сказать Twofish, а не Threefish.

Я как минимум вижу что Шнайер и еще кучка криптографов вместе надизайнили Threefish. И он сделан вполне в духе остальной криптографии - регистровая математика и никаких таблиц.

> Новое лучше с TF делать.

А технические аргументы за это мнение будут? И нет, я не хотел сказать про twofish. Он также использует S-box, что означает что в половине юзкейсов любезно разложены грабли. Они ЗАВЕДОМО ЕСТЬ, в отличие от тех которые "может быть найдутся" в threefish.

> И опять же открыто говорит что Skein надёжен, не означает что
> Threefish тоже. Так же как и HMAC-MD5 надёжен, но не MD5.

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

> предупреждает что пока анализов мало -- в общем на свой страх и риск.

А вон та толпа криптографов предупреждает что таблицы текут через кэш. Так что ну его этот ваш twofish в современных реалиях.

> протокола это просто тупо много простого кода (но каждая строка это
> потенциальная ошибка), который к крипто не имеет отношения.

Большинство ошибок фатальны обычно в использовании криптографии или прикручивании оной к протоколу.

> В 25519 FP конечно излишен.

И это при прочих равных шаг вперед. Если сравнить с RSA2048, можно ключ напрямую передавать, работает намного быстрее. Ну и нафига пользоваться RSA2048?

> отвернёшься забьют на проверку или проверят только первый или последний hex

Это уже на их совести. При таком подходе можно и просто отдать приватный ключ атакующему :)

> с похожими с первого взгляда отпечатками).

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

> Отвернёшься: проверяет последний hex и долбит ok.

Тем не менее, при правильном подходе у mitm есть только 1 шанс подсуетиться - в самом начале, и только если юзеры невнимательны. Это сделает жизнь mitm не слишком пресной. Если это прошляпить - ключ может быть запомнен, а дальше потуги его подменять приведут только к воплям, программе в отличие от юзера не в облом проверять все с точностью до бита.

> Всё расписано: подтверждаю. Люди остаются людьми: напоминаю.

Следовать инструкции может практически любой кодер. А если кодер совсем пофигист - пусть лучше веселую ферму делает, это у него лучше получится. Если не уволят за пофигизм :).

> Просто человек даже CTR делает коряво.

Человек может не знать что такое CTR и понятия не иметь чем плохо то что сделал он. Но вот выполнить DJBшную инструкцию из мана - вполне в его силах.

> PRNG тоже не быстрый и энтропию из системы поглощает.

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

> Хотя счётчика было бы достаточно.

Кстати говоря, в качестве nonce у DJB допустимо использовать и счетчик. Там даже пример есть, IIRC, как это сделать правильно и безграбельно. Очевидный минус - утекает некая информация о характере обмена информацией. В виде счетчика пакетов видимого всем.

> в массе своей и CTR реализовать.

У DJB в мане несколько простых требований вообще очень косвенно относящихся к криптографии.

> На бумаге учитывают. А в реализации люди забивают.

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