вопрос на 1млн

[icreator]

по описанию из
http://btcsec.com/bitcoin-iznutri/

— Как только собственник хочет продать автомобиль какому-либо покупателю — он пишет открытое письмо, в котором указывает заводской номер и хеш-сумму публичного ключа второго владельца HASH(PUB2). И конечно же подписывает письмо своим секретным ключом PRIV1, прилагая публичный ключ PUB1.
— После передачи собственности секретный ключ перестает быть актуальным — второго такого письма быть не может (см. «Единая история»). Публичным ключом можно проверить само письмо, удостоверить второго собственника.

может я не правильно понимаю - то есть как только с этого адреса был платеж - его секретность резко падает?
и вообще может ли потом кто-то с этого адреса сам заплатить?

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

если переводить сдачу на свой адрес основной - монеты не уведут?

[Geo_log]

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

если переводить сдачу на свой адрес основной - монеты не уведут?

- насчёт "После передачи собственности секретный ключ перестает быть актуальным" не знаю,
а сдача по умолчанию переводится на новый адрес "на всякий случай", точнее - чтобы запутать следы (этакая псевдоанонимность адресов).
В специализированных кошельках (например, blockchain.info) можно явным образом указывать адрес, на который должна прийти сдача, в том числе и основной. И при этом монеты однозначно не уведут! :-))

[GGUL]

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

если переводить сдачу на свой адрес основной - монеты не уведут?

- насчёт "После передачи собственности секретный ключ перестает быть актуальным" не знаю,
а сдача по умолчанию переводится на новый адрес "на всякий случай", точнее - чтобы запутать следы (этакая псевдоанонимность адресов).
В специализированных кошельках (например, blockchain.info) можно явным образом указывать адрес, на который должна прийти сдача, в том числе и основной. И при этом монеты однозначно не уведут! :-))

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

[icreator]

спасибо за инфо
короче эта запутываемость только мешает!!!

https://multibit.org/ спасет ))
он отправляет с 1го адреса всегда и сдачу туда же кладет

[amaclin]

может я не правильно понимаю - то есть как только с этого адреса был платеж - его секретность резко падает?

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

Если же публичный ключ неизвестен (известен хеш), то для увода средств надо решить задачу
"Найти приватный ключ такой, что хеш его публичного ключа равен данному хешу"

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

и вообще может ли потом кто-то с этого адреса сам заплатить?

Милорд, вы накурились и начали задавать нубские вопросы?

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

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

В некоторых редких случаях совсем плохого рандома (но эти случаи тоже есть в блокчейне!) я могу востановить ваш приватный ключ по одной операции вывода! Я же об этом писал в топике
https://bitcointalk.org/index.php?topic=461351.msg6408633#msg6408633
и вы даже в этом топике отмечались (значит читали? или фигу видели?)

TL;DR Если вы каждый раз используете новый адрес - ваши биткойны в сохранности, даже если у вас плохой генератор случайных чисел (вариант, когда ваш рандом будет и адрес для сдачи генерировать один и тот же не рассматриваем)

если переводить сдачу на свой адрес основной - монеты не уведут?

Как я объяснил выше - это зависит от того, каким клиентом вы пользуетесь. Если клиент кривой - могут увести. Я лично "увел" немного "копеек". Не судите строго - не сделал бы этого я - сделал бы рано или поздно кто-то другой. Я уже "собирал крошки" (dust) которыми побрезговали до меня другие "собиратели", которые зарабатывают биткойны собственным умом.

[icreator]

спасибо за вразумительный ответ

короче если с одного и того же адреса переслать несколько раз то можно подобрать быстрее ключ к адресу

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

короче надо иногда менять свой адрес - так?
а если это не удобно - например я им подписываю свои сообщения

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

[amaclin]

короче если с одного и того же адреса переслать несколько раз то можно подобрать быстрее ключ к адресу

Странный вывод вы сделали.
Да, если вы с одного адреса переведете 2²⁵⁶ раз, то можно подобрать ваш приватный ключ.
Если речь идёт о двух, десяти, ста или миллиарде переводов - вероятность компроментации все равно "астрономически малая"
Повторяю - при неправильном генераторе рандома я узнаю ваш ключ после 1 или нескольких переводов.
Но если ваш адрес "одноразовый", то я получаю только дырки от ваших бубликов.

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

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

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

короче надо иногда менять свой адрес - так?
а если это не удобно - например я им подписываю свои сообщения

Еще раз повторяю четко и внятно.
От частоты подписей сохранность ваших денег не меняется. Ну была вероятность 0.000000000000000000000000000000000000001%, а станет через год в 10 раз больше - вы рассчитываете жить вечно?

А вот менять свой адрес стоит. Потому что есть и иные варианты утечек. Ну сопрёт сегодня кто-нибудь ваш wallet.dat, запустит перебор паролей и через 10 лет найдет ваш приватный ключ. Но ему достанется кукиш с маслом, если раз в год вы будете переходить на новый адрес.

да кстати а все другие электронно-цифровые подписи (ЭЦП) ведь точно так же вскрываются?

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

чем больше подписываешь что-то тем больше вероятности вскрыть подпись...

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

[tvv]

а зачем вам ждать транзакцию?   Если вы знаете дырку в каком-то ГСЧ - то проще тупо просканировать все адреса в блокчейне, и спереть все что там лежало, к чему ключи подходят...

короче если с одного и того же адреса переслать несколько раз то можно подобрать быстрее ключ к адресу

скорее наоборот - появляется возможность для дополнительного контроля (у меня так в некоторых проектах и сделано)

Биткоин в этом смысле довольно дырявая система - достаточно подобрать просто коллизию(а их в 2^128 раз больше!), чтобы увести все что лежит на адресе, ему же пофиг, он же все равно не проверяет на 100% знаете ли вы секретный ключ полностью, или просто нашли первую попавшуюся коллизию перебором(что проще во много раз).


Поэтому я и придумал "контрольные отпечатки" так сказать - с ними будет уже сложнее, то есть даже если найдете вообще все коллизии, то все равно не угадаете какая из них правильная (что и будет использовано для возврата монет если такая дырка в криптофункции обнаружиться, а вообще даже если я сделаю форк например всего с 32 бит ключом который вы полностью переберете за 1 сек, то вероятность что удастся спереть монеты будет 1/65536, то есть фиг вам с маслом все равно достанеться, а вот в битке это позволит спереть все монеты)

Vladimir

[amaclin]

а зачем вам ждать транзакцию?   Если вы знаете дырку в каком-то ГСЧ - то проще тупо просканировать все адреса в блокчейне, и спереть все что там лежало, к чему ключи подходят...

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

Итак, процесс подписания ECDSA начинается со слов "возьмем случайное число K" (256-битное)
Потом мы крутим-вертим исходные данные и это случайное число и получаем подпись (два 256-битных числа) R и S. Так вот R - это просто 1/K (деление не простое, а в поле G)

Что из этого следует? Если вы подписали ваши данные вашим приватным ключом и поместили подпись на всеобщее обозрение, то я знаю то самое случайное число K, которое вы использовали. Но мне совершенно ненужно. Пусть ваш генератор случайных чисел выдает просто N_(i+1) = N_(i) + 1
Это мне не поможет. Пока у вас не повторится K - взломать ваш ключ не получится.

Возвращаемся назад: Условно говоря, если ваш генератор случайных чисел выдает просто числа по порядку: ...10, 11, 12, 13, 14... и я это знаю - я все равно не смогу ничего увести у вас.

Самый интересный момент: а что если K=1? Это вам для домашнего изучения.

EDIT: Перечитал и понял что я немного налажал с формулами. Смысл в целом правильный, но не пытайтесь изучать криптографию по моим постам.

[tvv]

а зачем вам ждать транзакцию?   Если вы знаете дырку в каком-то ГСЧ - то проще тупо просканировать все адреса в блокчейне, и спереть все что там лежало, к чему ключи подходят...

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

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

Итак, процесс подписания ECDSA начинается со слов "возьмем случайное число K" (256-битное)
Потом мы крутим-вертим исходные данные и это случайное число и получаем подпись (два 256-битных числа) R и S. Так вот R - это просто 1/K (деление не простое, а в поле G)

поля Галуа имеете ввиду?   Там их опошлили и превратили в обычные 32-бит целочисленные операции...
(и кстати там только на битах переноса уже ускорение до 8 бит (256 раз) можно получить - но майнерам как я понимаю ускорение не нужно)

Что из этого следует? Если вы подписали ваши данные вашим приватным ключом и поместили подпись на всеобщее обозрение, то я знаю то самое случайное число K, которое вы использовали. Но мне совершенно ненужно. Пусть ваш генератор случайных чисел выдает просто N_(i+1) = N_(i) + 1
Это мне не поможет. Пока у вас не повторится K - взломать ваш ключ не получится.

Возвращаемся назад: Условно говоря, если ваш генератор случайных чисел выдает просто числа по порядку: ...10, 11, 12, 13, 14... и я это знаю - я все равно не смогу ничего увести у вас.

Самый интересный момент: а что если K=1? Это вам для домашнего изучения.

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

Vladimir

[tvv]

Итак, процесс подписания ECDSA начинается со слов "возьмем случайное число K" (256-битное)
Потом мы крутим-вертим исходные данные и это случайное число и получаем подпись (два 256-битных числа) R и S. Так вот R - это просто 1/K (деление не простое, а в поле G)

упс, какая прелесть   А это я так понимаю еще одно место где стоит поискать дырки...

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


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

Vladimir

[amaclin]

поля Галуа имеете ввиду?   Там их опошлили и превратили в обычные 32-бит целочисленные операции...

А как вы себе представляете алгоритм, который нельзя было бы реализовать на 32-битном процессоре? Вообще-то и на машине Тьюринга можно подписывание реализовать

(и кстати там только на битах переноса уже ускорение до 8 бит (256 раз) можно получить - но майнерам как я понимаю ускорение не нужно)

Не путайте вычисление SHA256 и ECDSA.
Майнеры тупо пересчитвыают SHA256 - у них тут никаких эллиптических кривых нет. Эллиптические кривые мы используем когда (1) клиент создает транзакцию (2) узлы сети проверяют чужие транзакции (как дикие, так и включенные в блок)

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

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

[tvv]

поля Галуа имеете ввиду?   Там их опошлили и превратили в обычные 32-бит целочисленные операции...

А как вы себе представляете алгоритм, который нельзя было бы реализовать на 32-битном процессоре? Вообще-то и на машине Тьюринга можно подписывание реализовать

эмулировать только можно все - но будет сильно тормозить.

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

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

И что за 8 бит вы имеете в виду?

в SHA когда суммируют результаты с передыдущими блоками используется сумма без переноса, то есть по модулю 2^32.

В принципе в подписи это даже осложняет взлом, но при таком дубовом применении SHA не по назначению как в майнинге...

[tvv]

Не путайте вычисление SHA256 и ECDSA.
Майнеры тупо пересчитвыают SHA256 - у них тут никаких эллиптических кривых нет. Эллиптические кривые мы используем когда (1) клиент создает транзакцию (2) узлы сети проверяют чужие транзакции (как дикие, так и включенные в блок)

а че они там накосячили?

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

Vladimir
PS  я этот дебильный код на Ц вообще не перевариваю - боюсь что проще и быстрее будет с нуля написать реализацию, чем делать форк этого винегрета.

[amaclin]

а че они там накосячили?

Кто "они"? "Их" много.
Сперва накосячили Сони http://mollyrocket.com/forums/molly_forum_906.html (это не связано с биткойном, ссылка - первая попавшаяся в гугле)
Потом накосячили разработчики Андроида https://bitcoin.org/en/alert/2013-08-11-android
Потом... А, впрочем, ищите сами и найдете. Я все подсказки дал. Дополнительная информация - за символическую, но ненулевую плату.
Я думаю, еще будут косячить.

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

Потому что эллиптическая криптография - это не "черный ящик". Ей генератор рандома нужен. Рандом нельзя внутрь этого ящика положить. Рандом - это вещь, которая зависит от каждой конкретной системы.

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

Вроде разработчики биткойна хотели вообще перенести всё нужное из OpenSSL и отказаться от использования сторонней библиотеки. Хотя может я неправильно понял.