> Потому что ЯП C/C++ допускают использование памяти небезопасным способом

У криптографов свои, очень кастомные понятия отом что такое "безопасность", чувак. Так, навскидку:
1) Стандартные функции сравнения сравнения двух кусков памяти криптографам не нравятся. Дело в том что положительный и отрицательный результат возвращается за разное время. Что позволяет туеву хучу тайминг-атак, позволяющих угадывать ключи/пароли по косвенным признаками типа "за какое время приехал отлуп". Но жабисты о таком подумают потом, когда какой-нибудь гад пароль из 20 символов подберет за полчаса, меряя время отклика после проверки пароля и последовательно подбирая по букве. Так что 26^20 (или сколько там) плавно станет 26 * 20 (в хучшем случае). "Небольшое" упрощение подбора на основе таймингов, да? :)
2) Управление памятью требуется весьма тонкое и гранулярное. Надо аккуратно выделять, аккуратно освобождать, вовремя затирать, защищать от чтения другими/попадания в своп/etc. Не комильфо если другой процесс спи...т из нашего ключ, правда? Еще менее здорово если некто посторонний получит блок памяти который мы ранее юзали. А том - обана! - наш приватный ключ. Который никто не удосужился прибить оттуда.

> даже из другого потока — что и продемонстрировано уже миллион раз. Это на уровне
> ДНК конкретного языка и лечится только сменой ЯП.

Про ДНК ты прав, только для исправления ДНК надо не кровати переставлять, а менять б-дей^W программистов, пардон. Вот ты криптографические операции не напишешь безопасно ни на каком языке. Ни на жабе, ни на питоне, ни на си, на на брейнфаке.

> Понимай как хочешь. Как был упёртным синюшником, так и проживёшь им до
> старости. А там уж маразм прихватит — не до других концепций
> программирования будет.

Как раз си нормально ложится на криптографию. Он быстрый и там есть тонкое управление памятью, которое вообще-то должно использоваться для того чтобы криптография была реально безопасной, ну и он прост и предсказуем как топор, нет шансов что рантайм поумничает и подставит реализатора незапланированными/неучтенными свойствами. Криптография чувствительна к низкоуровневой механике и самым базовым свойствам самых простейших операций, типа сравнения 2 массивов. Впрочем, лабухов пишущих openssl это не касается - они с выделением памяти там нахимичили такого, что мало не покажется. В смысле, они выделение памяти перехватили, но ... не для того чтобы протирать освобожденные регионы, что было бы логично для криптографической либы и зарубило бы на корню атаку типа сабжа, а для того чтобы тормоза на каких-то особо кривых платформах воркэраундить. Елки, ну нихрена себе расстановка приоритетов у криптографической либы! Заметь, это организационная проблема - проблема расстановки приоритетов, etc.

> Наверно потому, что в C/C++ нет возможности определить, понадобится эта память ещё
> раз или нет — лучше перестраховаться,

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

> программа выполнила недопустимую операцию и будет свалена в кору", "память не
> может быть Read"?).

Знаешь, если привкей с которым работала программа может быть read когда этого быть не должно - это пипец и лютый баг. Сабж если что как раз про это. Кроме всего прочего, либа для шифрования оказывается довольно фривольно относится к содержимому памяти после деаллокации, да еще и мешает параноикам типа опенбздунов это фиксить. Что для криптографической либы вообще-то FAIL. Или уж сами протирайте, или уж хоть другим не мешайте. Но нет, эти с... починили тормоза в кривых платформах. Зато теперь они сливают память с паролями и привкеми по всему интернету. Вот это я понимаю, отсутствие мозга у разработчиков. Нет, я уже увидел достаточно признаков что они те еще ламеры, но чтобы _настолько_, что ...

> Да разработчики на C/C++ что и делают, так это парятся, как бы
> их поделия были устойчивыми и не ловили NPE на ровном месте

В криптографии вообще иные приоритеты. Приоритет номер ноль - не продолбать приватные ключи и прочий чувствительный материал. Это кроме всего прочего подразумевает при реализации в нормальном виде весьма аккуратное fine grained управление памятью и внимательность в самых базовых операциях. Криптографы ходят по минному полю и ошибаются 1 раз. В си на поле 10 мин, а в жабе - 5000. Ты какое предпочитаешь разминировать? :)

Прочий ламерский бред поскипан.

> Ты Java Memory Model изучил, чтобы такую чепуху городить здесь?

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