Раскрыты (https://davidgerard.co.uk/blockchain/2018/04/11/javascript-s... сведения о серьёзных проблемах с качеством генерации ключей криптовалют через браузерные web-интерфейсы или старые приложения, написанные на JavaScript, в которых для получения случайных чисел использовался класс SecureRandom() из библиотеки jsbn (https://github.com/andyperlitch/jsbn). Недостаточный размер энтропии приводил к созданию предсказуемых ключей и делал реальным подбор закрытого ключа по открытому.
Проблема затрагивает только ключи, сгенерированные при помощи JavaScript-приложений, в которых применяется старая версия библиотеки jsbn, выпущенная до 2013 года. Например, проблема зафиксирована в выпусках приложения BitAddress до 2013 года и bitcoinjs до 2014 года. Важно отметить, что в сети в JavaScript-реализациях криптовалют и в web-сервисах до сих пор встречается уязвимый старый код, например, при запросе jsbn на первом месте в выдаче Google выдаётся ссылка на форк репозитория jsbn на GitHub, который был ответвлён 7 лет назад (автор данного форка несколько дней назад удалил (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018... его).Суть проблемы в том, что до появления Web Crypto API класс SecureRandom() пытался (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018... собрать энтропию при помощи API window.crypto (nsIDOMCrypto), предоставляющего доступ к CSPRNG, но из-за опечатки в функции сравнения версии браузера создавалась ситуация, при которой библиотека пыталась обратиться к window.crypto.random в бразузере без его поддержки и без вывода ошибки откатывалась на использование ненадёжного математического генератора псевдослучайных чисел math.Random, который способен обеспечить всего 48-бит энтропии (в реальных конфигурациях выдаёт заметно меньше).
Трудоёмкость воссоздания закрытого ключа методом прямого перебора (brute force) для уязвимых ключей, созданных при уровне энтропии 48-бит, оценивается при наличии достаточно большой вычислительной мощности примерно в одну неделю работы. Поэтому всем пользователям, использующим подверженные уязвимости адреса криптоваолют, рекомендуется перенести с них средства на новые адреса, созданные с использованием качественного генератора случайных чисел. Кроме того, даже при использовании
CSPRNG, ключ, созданный в программах на базе jsbn, не может считаться надёжным, так как SecureRandom() прогоняет выход через ненадёжный алгоритм RC4, который приводит (https://ru.wikipedia.org/wiki/RC4#%D0%98%D1... к появлению коррелирующих смещений (biases).URL: https://davidgerard.co.uk/blockchain/2018/04/11/javascript-s.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=48448
Надо было собирать энтропию с событий ввода как GnuPG
Ой, какие бомбы замедленного действия.. Похоже криптой не следует пользоваться еще лет 15 , пока не отладят ..
А ЯваСкриптом нужно было начинать не пользоваться ещё 15 лет назад.
А слабо предоставить замену? Ну хотя бы частично компенсирующую жс, не надо всех возможностей сразу.
Assembler, C, Lisp. В принципе, при грамотном отношении этих трёх было бы достаточноНо тут вопрос, какие из "возможностей" вам нужны. Если для вас критично, чтобы софт разрабатывали именно низкоквалифицированные сотрудники, то с JavaScript, конечно, мало что сравнится.
Ты злой. Нет, хуже. Ты во власти стереотипов. На ЯваСкрипте не пишут дураки. Вовсе нет. На этом языке пишут многие умные люди. Беда в том, что пишут они дурацкие, вредные вещи. А сам язык неплох. Наверное.
> На этом языке пишут многие умные люди. Беда в том, что пишут они дурацкие, вредные вещи.- А если хороший человек сделает гадость, он так и останется хорошим?
- Хороший человек гадость не сделает.> А сам язык неплох. Наверное.
В ЯваСкрипте (да и не только) сейчас мода на асинхронную разработку. Оттуда растут ноги возросшей популярности функционального программирования, добавления лямбда-функций в языки, средний программист на которых никогда о них не слышал, и т.д. В ЯваСкрипт в том числе всякие костыли вставляют типа промисов для того, чтобы нелинейные участки кода визуально были похожи на линейные. С Лиспом это было бы проще.
Вместо всяких
objectбыло бы что-то типа
.method1(someArgument)
.then(function(){
return doSomething();
})
.then(function(){
return doSomethingOther();
});(then (method1 object someArgument)(я не достаточно хорошо разбираюсь в лиспе, но думается, что, скорее всего, в лиспе УЖЕ есть необходимые возможности).
(doSomething)
(doSomethingOther))Да, сейчас уже реализуют (возможно, даже реализовали) async/await. Да, избавились от рябящих в глазах "function". Но взяли бы лисп и ничего этого можно было бы не делать. У лиспа вообще нет синтаксиса - в него (насколько я вижу) можно вообще любые возможности вкрутить. А яваскриптовый пример выше - лишь попытка натянуть ужа на ежа.
Т.е. блобы во все щели?
Про квалификацию тыжпограммистов на С и Lisp можно сказать тоже самое
Слышал про такую штуку, как свободный софт? Хотя выбор языков забавный, конечно.
M$ или Гугель сделают браузер в котором работать будет только код написанный под их браузеры, для безопасности, а потом пропихнут это в стандарты. Мало DRM, хочется больше и толще?
Когда на них тыжпрограммисты писали? Они же фокспро, дельфи и сишарпик используют.
Как раз тыжпограмисты используют C, т.к. это даёт +100500 к крутости.
> Т.е. блобы во все щели?Какие ещё блобы?
<script type="text/lisp">($ (onload
#'(lambda (this)
($ (find "p.to-apply") (html "HelloWorld"))
(alert "Done!")))</script>
Для ускорения работы и повышения безопасности это надо поместить в специальную сборку, а то мало ли перехватят и изменят или ещё что нибудь.
> Assembler, C, Lisp. В принципе, при грамотном отношении этих трёх было бы
> достаточноОстаётся ответить только на вопрос:
Как имеющиеся браузеры заставить выполнять программы на этих языках?
И к каким ресурсам браузера из этих языков можно получить доступ? Это каким-то образом удастся дать ответ на первый вопрос. :-)
А что, понятие API только для js изобрели и для других языков принципиально нельзя программный интерфейс к возможностям браузера?
> А что, понятие API только для js изобрели и для других языков
> принципиально нельзя программный интерфейс к возможностям браузера?Ну конечно же изобрести можно любые программы, подпрограммы да алгоритмы. Но в браузерах сейчас это есть? Если этого нет, то не будут же вебмастеры ждать снисхождения благодатного АПИ на браузеры вместо того, чтобы ваять программы на каком-никаком, но зато на уже имеющемся, JS?
> Но в браузерах сейчас это есть?Изначально вопрос стоял "предложите альтернативы яваскрипту". Если одним из критериев будет "есть в браузерах ПРЯМО СЕЙЧАС", то вопрос теряет смысл, так как кроме яваскрипта ничего и нет.
> Как имеющиеся браузеры заставить выполнять программы на этих языках?Первые два - в виде устанавливаемых из репозитория пакетного менеджера (или скачиваемых с левых сайтов, в зависимости от ОС) расширений,
третий - прямо в исходниках страниц в форме <script type="text/lisp">Разумеется, "само" это не заработает, кто-то должен сделать поддержку в браузерах.
>> Как имеющиеся браузеры заставить выполнять программы на этих языках?
> Первые два - в виде устанавливаемых из репозитория пакетного менеджераЭто слова для кого? Для программистов и сисадминов? Или для пользователей? Программисты и сами напишут себе что угодно. А пользователи не знают даже что такое браузер. Они его называют - вот та штука, как её там... интернет короче... А менеджер для них - это такой человек, который ходит по магазину и пристаёт с вопросами типа "вам что-нибудь подсказать"? Соответственно, если вебмастеры вместо наваяния скриптов на JS будут пользователям сайтов писать что-то типа - да установите такую-то приблдуду из репозитория, то такие вебмастеры быстро лишатся работы и заказов.
(или скачиваемых
> с левых сайтов, в зависимости от ОС) расширений,
> третий - прямо в исходниках страниц в форме <script type="text/lisp">
> Разумеется, "само" это не заработает, кто-то должен сделать поддержку в браузерах.
для анимации кнопочек JS более чем достаточно
>Похоже криптой не следует пользоваться еще лет 15Да эта пирамида дай Б-г год ещё протянет.
Что еще по "телевизеру" сказали?
https://ru.wikipedia.org/wiki/%D0%91%D0%...
>в которых для получения случайных чисел использовался класс SecureRandom() из библиотеки jsbn.Сами виноваты. Я никогда не пользовался этим дерьмом. Зачем пользоваться всяким промежуточным дерьмом, если в браузере ВСЁ НУЖНОЕ ЕСТЬ? Вся суть фреймворкомакак.
Суть проблемы как раз в том, что в некоторых браузерах нужного нет, а в комбинации с ошибкой проверки версии (что, кстати, тоже не шибко умное решение, проверять намного лучше по наличию API) получилось то, что получилось.Надо было вместо фолбэка на Math.random() кидать new Error("your browser sucks").
>Суть проблемы как раз в том, что в некоторых браузерах нужного нетЗначит эти браузеры - гoвно и их пользователей надо послать на хер, раз они не могут себе поставить браузер. А не юзать всякие сраные библиотеки-прокладки вроде jquery, как это модно у фреймворкомакак.
От проекта зависит. Я б с удовольствием слал, но некоторые заказчики хотят, чтобы у всех работало, и даже готовы это оплачивать. И я их прекрасно понимаю - сто баксов одинаковые и у пользователя Хрома, и у пользователя MSIE.Впрочем, совсем древность уже никто не требует, а для MSIE 9+ вполне можно без всяких jquery обойтись, да.
Впрочем, Math.random() голый я бы все равно не брал. Сходил бы на сервер за рандомом, если в браузере все плохо.
> Сходил бы на сервер за рандомом, если в браузере все плохо.Ага, отличная идея - формировать приватные ключи пользователя на сервере.
>но из-за опечатки в функции сравнения версии браузера создавалась ситуация, при которой библиотека пыталась обратиться к window.crypto.random в браузере без его поддержки и без вывода ошибки откатывалась на использование ненадёжного математического генератора псевдослучайных чисел math.RandomJavaScript во все поля и минимум юнит-тестов - что ты с хипстеров возьмёшь.
> минимум юнит-тестов - что ты с хипстеров возьмёшь.У хипстеров как раз TDD вместо мозга. Написали тест - написали реализацию. Не написали тест - не написали реализацию.