Topic: Подозрительная кража битков - page 3. (Read 1598 times)

Попробую что-то такое сообразить, правда для bitcoin core. В принципе, некоторые числа можно сохранить как микроплатежи в направлении первых адресов, до 100к сатош можно 5-значные уместить вполн.

Нет, это просто указание стартового индекса, ничего считать комп не будет.Да, потерять их нельзя. Но я привел экстремальный пример, если вы сделаете m/84'/(тел.номер1)'/(тел.номер2)', то тоже будет неплохо (значения не должны быть больше двух миллиардов, если точно - не больше 2³¹).

А это не займет безобразно много времени, на обычном ПК? Получается и самому эти цифры надо будет как отдельный секрет сохранить тоже...

Это пока недоказанная гипотеза одного человека.

Да, можно и так страховаться. Только проще выбрать какие-то большие цифры в derivation path HD-кошелька. Например, импортировать в Electrum BIP39-сид и изменить путь с m/84'/0'/0' на m/84'/38654650'/98764370'/65487659'/657654997'/876456668' - сид можно публиковать на форуме - монеты никто никогда не найдет )).

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

Я вот ещё какую мыслю сейчас терзаю: из одной seed фразы можно породить миллиарды приватных ключей. Но сколько проверяет злоумышленник, попади к нему случайно или преднамеренно она? Сомневаюсь, что неделями генерирует адреса. Получается есть такой дополнительный вариант усиления безопасности: в течении суток (или больше) генерировать приватные ключи, и воспользоваться последним для холодного кошелька. В любом случае проверка балансов на этих ключах, займет в разы больше времени. После этого хранить сид-фразы может получиться более безопасным, в бумажном виде например. Особенно если на случайный адрес из первой 1000 (как это типично бывает), положить несколько сатошей - алгоритм брутфорса вора может вполне удовлетвориться этим.

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

Много циклов SHA, как я понял не есть хорошо?

А где он генерировал ключи в самом Electrum, или сторонней программе?

Что, так и будем обсуждать виды ненужного говна и платить за него кучу денег,
вместо того чтобы скинуться по копейке на исследования криптостойкости и найти в чём причина?..


PS  наши математики тут спасибо за тему передавали - а то их уже хотели сократить как не нужный балласт ))
(объяснять надо для тупых, или сами в соседнуюю тему(ссылка была) сходите разберётесь к чему приводят много циклов SHA?..
Но еслив кто тупой, то не стесняйтесь, так и пишите "йа тупой!", так и быть, разжуём в прядке гум.помощи, а то мож кто совсем без мозгов зубов, не гуманно ж морить голодом )) )

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

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

А так и Трезор и Леджер и Кипкей лучше подойдут для хранения 16 биткоинов (которых к несчастью уже нет) чем хранилище на Винде. Пускай и "супернадежное" (как показала практика - нет)

Про трезор не знаю, не изучал, но держал в руках. На ощуп говнина которую на 3D принтере распечатали, доверять такому я не стал бы, просто по тактильным ощущениям.

какая-то у Вас вера во всемогущество софта и вирусов ж)   
а на практике все просто же - если перевести в режим виртуалки, то тупо 50% софта перестает работать, так что вероятность не обнаружения такого вируса боле-мене грамотным пользователем(даже не программистом!) думаю ближе к 0...

Насчет возврата родного файла кошелька после похищения ключей - идея правильная...  но...

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


PS
https://bitcointalksearch.org/topic/m.53672404

1. Хвала битку, мне зарабатывать не требуется на жизнь. Спекулирую помаленьку, фьючерсы и опционы, с перекосом в хороший лонг по BTC/USD.
Ваша идея мне кажется чем-то сродни магии. Типа можно сообразить такую функцию, которая будет выбрасывать гигантские диапазоны nonce, в которых вероятность нахождения хэша меньше средней. У майнинговых пулов только и остается, что выдавать подключенным узлам диапазоны на проверку. Это ведь даже не AsicBoost технология, которая ещё на стороне майнеров изменения предполагает. Если математика в нашей вселенной не изменилась, тогда во всех диапазонах nonce одинаковой размерности, вероятность найти подходящий хэш равнозначная. Я не математик, даже в университете не учился, но этот вопрос считаю достаточно простым. При той сложности, которую подразумевает двойное хэширование, с частично изменяемыми данным на входе, никакой прогнозируемой функции быть не может. Это не число Pi, где алгоритмическая зависимость цифр в позиции предопределена заранее, т.е. имеются изначально все входные данные. В случае майнинга биткойнов, часть входных данных является условно случайной и до времени не определенной, или вы полагали что только nonce имеет значение?
2. Мне приходится доверять массе закрытого и открытого всего, без этого никак. Я никогда не совался в код биткойна, чтобы поискать там подозрительные вещи - квалификация далеко не та.
3. Это нелепо совершенно. На прерывании висят обработчики драйверов, а вредоносный код как правило не настолько крут, чтобы становиться посредником. В тех редких случаях, когда система поражена серьёзным руткитом, запускающим операционку как виртуальную машину, отладчик вообще ничего не выдаст и не покажет. И скажите, заради чего малвари клавиатуру перехватывать постоянно? При привилегиях уровня ring 0 (сосуществовании с ядром или выше), элементарно дампится память любой программы, и отследить это будет нельзя.
4. На флешке архив остался, но я сомневаюсь что нечто будет так серьёзно заметать следы. Будь настолько продуманным злоумышленник, он вернул-бы оригинальные файлы программы на место, после факта кражи приватных ключей.

если не секрет, то сколько зарабатываешь?

И во сколько оцениваешь доходы с пула, если скажем удастся ускорить майнинг на 20%? 
(а 1 бит всего - это уже +100%!
Один бит там можно выкроить даже просто с того, что SHA там двойная...)



а ты сообразительный!



не понял...  То есть, ты, _зная точно что в сборке эта хрень включена_, не зная(?) что там и как сделано внутри чипов,
вот так вот просто берешь и генерируешь свой новый кошелек на этой хрени?..


Да, и если ты действительно программист(?), то почему тебе проще сделать что-то на экзотическом железе, чем тупо посмотреть отладчиком что за хрень сидит на прерывании от клавиатуры?..




молодец!  Хоть это сделал...

Надеюсь копию на офлайновом носителе сохранил?   А то если это NSA или хакеры нашли дырку от нее, то боюсь твой архив на доступном для них хостинге может так-же совершенно случайно измениться...
(как насчет md5 или лучше sha256 хэшей по всем файлам, и в публикацию?..
Блин, какая же я все-же сволоч - даже сам не могу понять за что так не люблю NSA ж))) )

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

Загадки продолжаются. В прошлый раз я деинсталлировал "подозрительный" Electrum с ноутбука, потом система перезагружалась. Сегодня смотрю и глазам не верю, он на месте стоит и ярлык на рабочем столе. На всякий случай упаковал и выложил:
https://sendgb.com/Wth7zmKJ8ya
Деинсталлировал повторно, перезагрузился, пока нет его

жить становиться весело, жизнь становиться все веселее!! ж)

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



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


PS  что ещё знаете о подобных взломах, расскажите?..  (а то наши математики тут уже угорают - чем-то вы их весьма обрадовали...)

1. Я ещё ничего не решил, я только догадки имею на руках. Кошельки свои я всегда генерировал в Bitcoin-Core свежей версии, хотя сомневаюсь что там используется отличная библиотека криптографии от Electrum.
2. Это ещё школьникам должно быть понятно, что такое хэширование делает принципиально не восстановимой seed фразу из полученного набора байтов. Однако, этот набор байтов можно использовать напрямую, для иерархической генерации приватных ключей. На этот счет не заморачивайтесь даже, основную стоимость вычислений в брутфорсе будет занимать генерация и сравнение публичных адресов с списком "денежных" публичных адресов. Для некоторого ускорения можно ограничить список адресов с битками, очень крупными, например от 100 монет, но все равно количество операций потребуется большое.
3. Многоядерные чипы стоят несколько дороже, из-за большего брака, и относительно высокой сложности проектирования. Но безусловно, в целом их использование удешевляет вычислительную систему. Однако чипов с миллионами ядер хотя-бы уровня i7 я думаю в обозримом времени не появиться.
4. У меня хватает работы. Да и специализация смешанная gamedev/IoT/lowlevel. 

как-то странно у Вас голова работает(IMHO конечно, но если хотите могу позвать психологов для консультации)...

1.  Если было много дыр(_теоретических_), то почему Вы решили, что не могло быть дыры именно в алгоритме генерации пароля?
При этом будет уже без разницы, где Вы его генерировали, и переносили ли на онлайн защифрованным или нет...

2.  Там 2000 циклов SHA крутят потом после сид-кода!!!   Как думаете, это понижает, или повышает криптостойкость?
   (ладно, так и быть, подскажу:  _Для каких_ алгоритмов и методов? )

3.  Стоимость параллельных вычислений ниже, тк ядер больше, а цена чипа практически почти такая-же!..
   (Вот насчет энергии на 1 операцию это да - тут без разницы параллельно или нет - но там где ядер больше, и технология более мелкая, более экономичная то есть!)


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

1. Мои новые кошельки сгенерированы в оффлайне, на Raspberry Pi 4 (полную ноду пришлось несколько часов собирать). В течении секунды после создания эти кошельки подвергались шифрованию, и выгрузке из памяти. Уже в онлайновые системы они были скопированы зашифроваными. Что-же касается друга, там ключи генерировались на онлайн системе, пусть и чистейшей. И кошелек разблокировался неоднократно "чтобы посмотреть баланс" - до сих пор меня это раздражает. Были установлены такие мессенджеры как Telegram и Viber, что помимо Kaspersky Total Security увеличивало риск компрометации. Мелких ошибок если так посчитать, было сделано более чем достаточно. Мне намекнули, что стащить приватные ключи мог даже javascript используя уязвимость meltdown, не выходя за пределы браузера.
При этом сам я подозреваю, что имела быть место какая-то уязвимость в генерации сидов у самого Electrum или в какой-то момент была установлена поддельная версия: должно быть какое-то обоснование массовой кражи в июне 2019-го.

2. Да даже 2^124, с учетом энергетической стоимости суммы операций. Уж не знаю, что за магия там может на 40 битов сократить перебор, если с ГСЧ при генерации все нормально. Стоимость проверки каждой seed фразы невообразимо огромна, я думаю на самом современном ПК она будет занимать многие секунды: надо сгенерировать приватные ключи, из ключей получить списки адресов для пополнения, проверить пересечение этих списков с списком непустых (в моменте!) адресов. Даже если-бы потребовалось перебрать 2^64 (18.44 квинтиллиона) вариаций, по 1 секунде, это в идеальном случае 585 миллиардов лет эксплуатации мощного компьютера. Если теоретический компьютер кушает 0.5кВт*Ч, год его работы обойдется в 4.3МВт*ч. Т.е. даже в столь неимоверно упрощенном случае, для полного перебора за год потребуется затратить 1.1 миллион ТВт*ч, покрыв всю материки компьютерами и электростанциями. А по вашей оценке, минимум 84 бита сложность, что предполагает такими расходами обнаружить меньше 1/1048576 всех ключей!

https://bitcointalksearch.org/topic/are-the-12-worded-seeds-really-secure-from-brute-force-1716725 вот тут ещё люди обсуждают эту задачу
И наконец примите с сведению факт: параллельные вычисления могут сократить время задачи, ценой кратного увеличения стоимости оборудования. Если один компьютер решает задачу последовательного перебора за миллиард лет, то за один год её решат никак не менее миллиарда компьютеров (при полной загрузке 24/365). Мне как программисту это все слишком очевидно, чтобы объяснять и разжевывать. Энергетические расходы будут одинаковыми примерно.

и распараллеливания, и алгоритмов оптимизации полно находиться!

Обязательно сначала находить 1% а потом изымать или можно все таки постепенно - подсчитал 10^-80%, нашел BTC, изъял, потом следующие  10^-80%, и тд.? И походу я вам сообщу что все эти числа со звездами, песчинками и тд сделаны при условии последовательного счета но никто не приводил цифр для случая распараллеливания задачи.

так что в теме винду оправдали штоле не понял