BIP 38 Обсуждение темы - Passphrase-Protected Private Key Format

Я начинаю дискуссионную тему о технических достоинствах и криптографической разумности моего недавнего предложения о PassPhrase защищенного закрытых ключей.

https://en.bitcoin.it/wiki/BIP_0038

Основные особенности:
* Зашифрованные ключи пятьдесят восемь Base58Check кодировка символов, начиная с "6P"
* Шифрование использует AES-256. Ключевой вывод использует Scrypt. Параметры фиксируются на 16384,8,8; неиспользуемое пространство в формате ключ позволяет будущие изменения спецификации.
* Обнаружение опечатки представляет собой 32-битный хэш полученного адреса Bitcoin и требует полного вывода и процесса расшифровки для того, чтобы быть проверен, поэтому он не обеспечивает ускорение для крекеров. Этот 32 бит также используется в качестве соли.
* Эллиптический кривой шаг умножения выбирается, позволяя схему, где Алиса может выбрать кодовую фразу и Боб может создать и фонд Bitcoin адресов, только Алиса может расшифровать; спецификация описывает то, что Алиса должна дать Бобу, чтобы это случилось, не разглашая ее ключевую фразу, и определяет Base58Check кодированного формата для него.
* Оба сжатых и несжатых форматов открытого ключа выбираются.

Полностью функциональная проверка концепции код был опубликован в https://github.com/casascius/Bitcoin-Address-Utility

Недавно я побежал конкурс где я создал зашифрованный бумажный бумажник с 5-буквенным паролем, погрузил его с 10 BTC и опубликовал зашифрованный секретный ключ, спрашивая человек, чтобы взломать на него. Прошло два дня, в конечном итоге победитель бросил 20 машин на него, и выиграл только после того, как я просочилась достаточно информации о пароле для сокращения поиска набора в соответствии с 6 миллионов возможных паролей. Его оценка того, сколько времени это заняло бы его искать все (уменьшенный) поиска набор был 45 до 60 часов.

Я надеюсь, что мое предложение будет рассматриваться как безопасное достаточно для реализации во всем мире в качестве стандарта, в любом месте кто-то попросил, чтобы обеспечить закрытый ключ для какой-либо причины. Это включает в себя любые частные ключевые развертки или функции импорта в клиенте Satoshi. В рабочем процессе пользовательского интерфейса, если защищенный паролем секретный ключ будет введен, то это должно быть определено автоматически, и пользователь будет предложено: "Введите пароль", В контексте RPC, пароль будет еще один аргумент на звонки.

котировка

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

Это в ответ на ваш другой поток, но единый вход работает, множественный не делает. Независимо от того, что я вхожу, это просто сказать незамеченной. Глядя на ваш код, кнопка для нескольких раз позволяет многострочный и изменения textBox1. Button1 посылает текст от переводчика, который не признает более одного адрес одновременно.

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

Может ли это быть модифицирована таким образом, что количество ЦП на догадку можно настроить? Например, если у вас что-то хэш в 100 раз, а не один раз, чтобы получить ключ, а не 1 раз, которое потребуется 6000 часов, чтобы взломать вместо 60. Но если вы знаете пароль, если он будет по-прежнему занимает всего несколько минут, чтобы расшифровать.

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

Цитата: J-Norm 05 декабря 2012 года, 7:57:32 PM

Как он это прямо сейчас, это займет около секунды, чтобы расшифровать на моей машине, если вы знаете пароль. Это сделало бы его так, чтобы это могло работать на телефоне в JavaScript на эту трудность, если пароль известен. То же машина бы полгода, чтобы взломать 5 символов одного случая. Убедитесь, что верхний ниже и вы 12 лет. Очевидно, что у него было двадцать машин и не использует неразделанный скомпилированный код. Для WAHT он предлагает текущая длина хэширования достаточно. Если я все вычисления этого права сделать это буквенно-цифровой верхний нижний и та же вещь занимает 29 лет на моем одном компьютере.

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

Код:

дд, если = / DEV / случайное шс = 1M Count = 1 | sha256sum

^^ Блин хороший пароль.

Цитата: J-Norm 05 декабря 2012 года, 9:15:10 PM

Код:

дд, если = / DEV / случайное шс = 1M Count = 1 | sha256sum

^^ Блин хороший пароль.

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

Цитата: wtfvanity от 05 декабря 2012 года, 9:19:56 PM

Цитата: J-Norm 05 декабря 2012 года, 9:15:10 PM

Код:

дд, если = / DEV / случайное шс = 1M Count = 1 | sha256sum

^^ Блин хороший пароль.

Мало того, что трудно запомнить, он имеет достаточное количество битов, чтобы быть сам закрытый ключ. Я делал небольшую шутку, не очень хорошо на шутки.

Цитата: J-Norm 05 декабря 2012 года, 9:30:31 PM

Цитата: wtfvanity от 05 декабря 2012 года, 9:19:56 PM

Цитата: J-Norm 05 декабря 2012 года, 9:15:10 PM

Код:

дд, если = / DEV / случайное шс = 1M Count = 1 | sha256sum

^^ Блин хороший пароль.

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

Способность генерировать адреса без знания (воздействия) закрытые ключи властен. Я изучал криптографию (и даже цифровые наличные деньги) в аспирантуре и практиковал Applied Cryptography профессионально в течение нескольких лет, но я должен был бы действительно вернуться в свои исследования, чтобы правильно проанализировать свои методы. Если они звук, то это прекрасная возможность для Bitcoin. Сама BIP написано очень четко и лаконично.

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

РЕДАКТИРОВАТЬ: Вот что-то более существенным: Это позволило бы решить тщеславия Адрес Service дилемму. Сценарий: Алиса хочет тщеславие адреса, но не имеет мощности процессора генерировать один. Алиса посылает Бобу ее intermediate_passphrase_string. Боб имеет много вычислительной мощности и может генерировать адреса без знания секретных ключей. При желании строки тщеславие Алисы найдена, Боб может предоставить адрес и зашифрованный ключ Алисе, который может расшифровать секретный ключ и использовать его, не опасаясь, что Боб будет эксплуатировать его позже. Боб может даже показать доказательство того, что он нашел правильный адрес тщеславия, прежде чем отпустить зашифрованный секретный ключ обратно Алисе (например, просить плату за услуги).

Я видел что-то вроде этого предложил для тщеславия адресов раньше, но я считаю, что это BIP решает его довольно хорошо. Это точно?

ОБНОВИТЬ: ... и теперь у меня есть еще одна идея ...

Цитата: Nyhm от 07 декабря 2012 года, 3:40:03 PM

РЕДАКТИРОВАТЬ: Вот что-то более существенным: Это позволило бы решить тщеславия Адрес Service дилемму. Сценарий: Алиса хочет тщеславие адреса, но не имеет мощности процессора генерировать один. Алиса посылает Бобу ее intermediate_passphrase_string. Боб имеет много вычислительной мощности и может генерировать адреса без знания секретных ключей. При желании строки тщеславие Алисы найдена, Боб может предоставить адрес и зашифрованный ключ Алисе, который может расшифровать секретный ключ и использовать его, не опасаясь, что Боб будет эксплуатировать его позже. Боб может даже показать доказательство того, что он нашел правильный адрес тщеславия, прежде чем отпустить зашифрованный секретный ключ обратно Алисе (например, просить плату за услуги).

Я видел что-то вроде этого предложил для тщеславия адресов раньше, но я считаю, что это BIP решает его довольно хорошо. Это точно?

Я думаю, что это будет работать для добычи тщеславия. Эта проблема не имеет уже какое-то решение. https://vanitypool.appspot.com/

Как будет дано доказательство?

Цитата: Nyhm от 07 декабря 2012 года, 3:40:03 PM

Да, но, к сожалению, работает не тонны лучше, чем стандартная практика в настоящее время: отправить открытый ключ, держать закрытый ключ, и объединить их с добавлением EC (моя утилита может сделать это, а).

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

Кроме того, AFAIK, поколение тщеславия должно использовать сложение ЕС, а не умножение, в противном случае она будет работать слишком медленно, чтобы быть полезными. Добавление EC имеет недостаток безопасности, но это влияет только на очень конкретный случай использования и не влияет на генерацию тщеславия.

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

Какова цель шифрования AES во втором методе (режим умножения ЕС)?
Вы можете просто разместить seedb в незашифрованном виде зашифрованного секретного ключа вместо encryptedpart1 и 2.

Цитата: casascius от 08 декабря 2012 года, 7:47:39 AM

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

Какой недостаток безопасности?

Цитата: casascius от 05 декабря 2012 года, 7:20:22 PM

Скажем, Боб создает enrypted Bitcoin адрес. Но вместо того, чтобы посылать это Алисе он отправляет данные Чарли. Я предполагаю, что существует тривиальный способ для Боба proove Чарли, что адрес, верно? Я спрашиваю, потому что я считаю, что это может иметь большие последствия для различных цифровых денежных систем.

Видеть:

Цитата: 2_Thumbs_Up 09 декабря 2012 года, 6:35:45 PM

Если Боб должны были раскрыть оба "промежуточный код" и зашифрованный закрытый ключ, он создал Чарли~d, то Чарли мог определить, что два из них связаны, и может самостоятельно вычислить адрес Bitcoin. С промежуточным кодом, Чарли может "расшифровывать" шифрование AES на ключах порождена Боба, который, как он может получить адрес Bitcoin, но он по-прежнему не хватает ключевой материал Алисы, который доступен только с оригинальной ключевой фразой, поэтому он не может получить закрытый ключ на самом деле необходимый тратить средства.

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

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

https://en.bitcoin.it/wiki/User:Casascius/Escrow_scheme_draft

Цитата: casascius от 05 декабря 2012 года, 7:20:22 PM

* Зашифрованные ключи пятьдесят восемь Base58Check кодировка символов, начиная с "6P"

Вы не могли бы обновить эту статью вики, чтобы отразить это?
- http://en.bitcoin.it/wiki/List_of_address_prefixes

Цитата: thanke 09 декабря 2012 года, 7:39:33 AM

Удар.

Вопрос по-прежнему спрашивают. Если сторона генерации адреса, зная seedb, не может вычислить частные ключи, то почему seedb никогда не шифруются? Адрес PassPoint * factorb не может быть погашен, не зная кодовую фразу и ownersalt.

Есть еще одна причина для шифрования seedb?

Цитата: thanke от 10 декабря 2012 года, 8:54:14 PM

Цитата: thanke 09 декабря 2012 года, 7:39:33 AM

Потому что это может быть, и немного больше.

По той же причине мы используем SHA256 (SHA256 (любой)) вместо SHA256 (что угодно).

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

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

Цитата: casascius от 10 декабря 2012 года, 9:09:33 PM

Цитата: thanke от 10 декабря 2012 года, 8:54:14 PM

Цитата: thanke 09 декабря 2012 года, 7:39:33 AM

Потому что это может быть, и немного больше.

По той же причине мы используем SHA256 (SHA256 (любой)) вместо SHA256 (что угодно).

Я не знаю, почему мы используем двойной хэш.

Цитата: casascius от 10 декабря 2012 года, 9:09:33 PM

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

Атака может быть: У вас есть две зашифрованных ключей, расшифровать один из них, частично потратить и сохранить расшифрованную версию вокруг для последующих расходов. Предположим, что они оба основаны на том же промежуточном коде и производится без шифрования AES части. Если кто-то находит их (один расшифрованы, один зашифрованный), то, что человек может также провести зашифрованные один. Так что я вижу вашу точку для AES сейчас, если не запрещает повторное использование промежуточных кодов.

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

5 декабря 2012, 7:20:22 PM	# 1
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Я начинаю дискуссионную тему о технических достоинствах и криптографической разумности моего недавнего предложения о PassPhrase защищенного закрытых ключей. https://en.bitcoin.it/wiki/BIP_0038 Основные особенности: * Зашифрованные ключи пятьдесят восемь Base58Check кодировка символов, начиная с "6P" * Шифрование использует AES-256. Ключевой вывод использует Scrypt. Параметры фиксируются на 16384,8,8; неиспользуемое пространство в формате ключ позволяет будущие изменения спецификации. * Обнаружение опечатки представляет собой 32-битный хэш полученного адреса Bitcoin и требует полного вывода и процесса расшифровки для того, чтобы быть проверен, поэтому он не обеспечивает ускорение для крекеров. Этот 32 бит также используется в качестве соли. * Эллиптический кривой шаг умножения выбирается, позволяя схему, где Алиса может выбрать кодовую фразу и Боб может создать и фонд Bitcoin адресов, только Алиса может расшифровать; спецификация описывает то, что Алиса должна дать Бобу, чтобы это случилось, не разглашая ее ключевую фразу, и определяет Base58Check кодированного формата для него. * Оба сжатых и несжатых форматов открытого ключа выбираются. Полностью функциональная проверка концепции код был опубликован в https://github.com/casascius/Bitcoin-Address-Utility Недавно я побежал конкурс где я создал зашифрованный бумажный бумажник с 5-буквенным паролем, погрузил его с 10 BTC и опубликовал зашифрованный секретный ключ, спрашивая человек, чтобы взломать на него. Прошло два дня, в конечном итоге победитель бросил 20 машин на него, и выиграл только после того, как я просочилась достаточно информации о пароле для сокращения поиска набора в соответствии с 6 миллионов возможных паролей. Его оценка того, сколько времени это заняло бы его искать все (уменьшенный) поиска набор был 45 до 60 часов. Я надеюсь, что мое предложение будет рассматриваться как безопасное достаточно для реализации во всем мире в качестве стандарта, в любом месте кто-то попросил, чтобы обеспечить закрытый ключ для какой-либо причины. Это включает в себя любые частные ключевые развертки или функции импорта в клиенте Satoshi. В рабочем процессе пользовательского интерфейса, если защищенный паролем секретный ключ будет введен, то это должно быть определено автоматически, и пользователь будет предложено: "Введите пароль", В контексте RPC, пароль будет еще один аргумент на звонки.

5 декабря 2012, 7:53:51 PM	# 2
wtfvanity Сообщения: 504 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Получил 1806 Биткоинов Реальная история. котировка Я думаю, что я проверил в элементах пользовательского интерфейса, чтобы разрешить запись партии, но не написал код на самом деле разобрать их. Это в ответ на ваш другой поток, но единый вход работает, множественный не делает. Независимо от того, что я вхожу, это просто сказать незамеченной. Глядя на ваш код, кнопка для нескольких раз позволяет многострочный и изменения textBox1. Button1 посылает текст от переводчика, который не признает более одного адрес одновременно. Что-то еще я заметил, если бы я только добавить адрес, он говорит секретный ключ, неизвестно. Есть в любом случае, чтобы сказать ему, что закрытый ключ, если я введу его в обратном направлении, как это?

5 декабря 2012, 7:57:32 PM	# 3
J-Норм Сообщений: 56 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Может ли это быть модифицирована таким образом, что количество ЦП на догадку можно настроить? Например, если у вас что-то хэш в 100 раз, а не один раз, чтобы получить ключ, а не 1 раз, которое потребуется 6000 часов, чтобы взломать вместо 60. Но если вы знаете пароль, если он будет по-прежнему занимает всего несколько минут, чтобы расшифровать. Не уверен, что о точных внутренностях вашего протокола, но что-то подобное, что было бы хорошо, и действительно раздражать Грубые атакующие силы.

5 декабря 2012, 8:02:28 PM	# 4
wtfvanity Сообщения: 504 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Цитата: J-Norm 05 декабря 2012 года, 7:57:32 PM Может ли это быть модифицирована таким образом, что количество ЦП на догадку можно настроить? Например, если у вас что-то хэш в 100 раз, а не один раз, чтобы получить ключ, а не 1 раз, которое потребуется 6000 часов, чтобы взломать вместо 60. Но если вы знаете пароль, если он будет по-прежнему занимает всего несколько минут, чтобы расшифровать. Не уверен, что о точных внутренностях вашего протокола, но что-то подобное, что было бы хорошо, и действительно раздражать Грубые атакующие силы. Как он это прямо сейчас, это займет около секунды, чтобы расшифровать на моей машине, если вы знаете пароль. Это сделало бы его так, чтобы это могло работать на телефоне в JavaScript на эту трудность, если пароль известен. То же машина бы полгода, чтобы взломать 5 символов одного случая. Убедитесь, что верхний ниже и вы 12 лет. Очевидно, что у него было двадцать машин и не использует неразделанный скомпилированный код. Для WAHT он предлагает текущая длина хэширования достаточно. Если я все вычисления этого права сделать это буквенно-цифровой верхний нижний и та же вещь занимает 29 лет на моем одном компьютере.

5 декабря 2012, 9:15:10 PM	# 5
J-Норм Сообщений: 56 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Я согласен, что в настоящее время трудности достаточно. Я думал, что трудность заключается в том конфигурируемый будет хорошая особенность, но вы всегда можете просто использовать более длинный пароль. Код: дд, если = / DEV / случайное шс = 1M Count = 1 \| sha256sum ^^ Блин хороший пароль.

5 декабря 2012, 9:19:56 PM	# 6
wtfvanity Сообщения: 504 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Цитата: J-Norm 05 декабря 2012 года, 9:15:10 PM Я согласен, что в настоящее время трудности достаточно. Я думал, что трудность заключается в том конфигурируемый будет хорошая особенность, но вы всегда можете просто использовать более длинный пароль. Код: дд, если = / DEV / случайное шс = 1M Count = 1 \| sha256sum ^^ Блин хороший пароль. Трудно вспомнить хотя. 5 алфавитно-цифровой не должно быть слишком трудно запомнить без необходимости писать его или опечатки очень длинный пароль.

5 декабря 2012, 9:30:31 PM	# 7
J-Норм Сообщений: 56 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Цитата: wtfvanity от 05 декабря 2012 года, 9:19:56 PM Цитата: J-Norm 05 декабря 2012 года, 9:15:10 PM Я согласен, что в настоящее время трудности достаточно. Я думал, что трудность заключается в том конфигурируемый будет хорошая особенность, но вы всегда можете просто использовать более длинный пароль. Код: дд, если = / DEV / случайное шс = 1M Count = 1 \| sha256sum ^^ Блин хороший пароль. Трудно вспомнить хотя. 5 алфавитно-цифровой не должно быть слишком трудно запомнить без необходимости писать его или опечатки очень длинный пароль. Мало того, что трудно запомнить, он имеет достаточное количество битов, чтобы быть сам закрытый ключ. Я делал небольшую шутку, не очень хорошо на шутки.

5 декабря 2012, 9:32:36 PM	# 8
wtfvanity Сообщения: 504 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Цитата: J-Norm 05 декабря 2012 года, 9:30:31 PM Цитата: wtfvanity от 05 декабря 2012 года, 9:19:56 PM Цитата: J-Norm 05 декабря 2012 года, 9:15:10 PM Я согласен, что в настоящее время трудности достаточно. Я думал, что трудность заключается в том конфигурируемый будет хорошая особенность, но вы всегда можете просто использовать более длинный пароль. Код: дд, если = / DEV / случайное шс = 1M Count = 1 \| sha256sum ^^ Блин хороший пароль. Трудно вспомнить хотя. 5 алфавитно-цифровой не должно быть слишком трудно запомнить без необходимости писать его или опечатки очень длинный пароль. Мало того, что трудно запомнить, он имеет достаточное количество битов, чтобы быть сам закрытый ключ. Я делал небольшую шутку, не очень хорошо на шутки. Над моей головой, извините. Получить в виде набора дискуссии о некоторых вещах и шутка заскучать.

7 декабря 2012, 3:40:03 PM	# 9
Nyhm Сообщения: 216 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Способность генерировать адреса без знания (воздействия) закрытые ключи властен. Я изучал криптографию (и даже цифровые наличные деньги) в аспирантуре и практиковал Applied Cryptography профессионально в течение нескольких лет, но я должен был бы действительно вернуться в свои исследования, чтобы правильно проанализировать свои методы. Если они звук, то это прекрасная возможность для Bitcoin. Сама BIP написано очень четко и лаконично. Я знаю, что это замечание не очень содержательно дискуссии, но я хотел бы поблагодарить вас за ваши усилия. Я уже думал, что вы были удивительными для изготовления физических монет Bitcoin (сочетание двух моих любимых вещей: чеканки и криптографии), так что теперь вы в значительной степени мой новый герой. РЕДАКТИРОВАТЬ: Вот что-то более существенным: Это позволило бы решить тщеславия Адрес Service дилемму. Сценарий: Алиса хочет тщеславие адреса, но не имеет мощности процессора генерировать один. Алиса посылает Бобу ее intermediate_passphrase_string. Боб имеет много вычислительной мощности и может генерировать адреса без знания секретных ключей. При желании строки тщеславие Алисы найдена, Боб может предоставить адрес и зашифрованный ключ Алисе, который может расшифровать секретный ключ и использовать его, не опасаясь, что Боб будет эксплуатировать его позже. Боб может даже показать доказательство того, что он нашел правильный адрес тщеславия, прежде чем отпустить зашифрованный секретный ключ обратно Алисе (например, просить плату за услуги). Я видел что-то вроде этого предложил для тщеславия адресов раньше, но я считаю, что это BIP решает его довольно хорошо. Это точно? ОБНОВИТЬ: ... и теперь у меня есть еще одна идея ...

8 декабря 2012, 7:32:14 AM	# 10
Red Emerald Сообщения: 742 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Цитата: Nyhm от 07 декабря 2012 года, 3:40:03 PM РЕДАКТИРОВАТЬ: Вот что-то более существенным: Это позволило бы решить тщеславия Адрес Service дилемму. Сценарий: Алиса хочет тщеславие адреса, но не имеет мощности процессора генерировать один. Алиса посылает Бобу ее intermediate_passphrase_string. Боб имеет много вычислительной мощности и может генерировать адреса без знания секретных ключей. При желании строки тщеславие Алисы найдена, Боб может предоставить адрес и зашифрованный ключ Алисе, который может расшифровать секретный ключ и использовать его, не опасаясь, что Боб будет эксплуатировать его позже. Боб может даже показать доказательство того, что он нашел правильный адрес тщеславия, прежде чем отпустить зашифрованный секретный ключ обратно Алисе (например, просить плату за услуги). Я видел что-то вроде этого предложил для тщеславия адресов раньше, но я считаю, что это BIP решает его довольно хорошо. Это точно? Я думаю, что это будет работать для добычи тщеславия. Эта проблема не имеет уже какое-то решение. https://vanitypool.appspot.com/ Как будет дано доказательство?

8 декабря 2012, 7:47:39 AM	# 11
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Цитата: Nyhm от 07 декабря 2012 года, 3:40:03 PM РЕДАКТИРОВАТЬ: Вот что-то более существенным: Это позволило бы решить тщеславия Адрес Service дилемму. Сценарий: Алиса хочет тщеславие адреса, но не имеет мощности процессора генерировать один. Алиса посылает Бобу ее intermediate_passphrase_string. Боб имеет много вычислительной мощности и может генерировать адреса без знания секретных ключей. При желании строки тщеславие Алисы найдена, Боб может предоставить адрес и зашифрованный ключ Алисе, который может расшифровать секретный ключ и использовать его, не опасаясь, что Боб будет эксплуатировать его позже. Боб может даже показать доказательство того, что он нашел правильный адрес тщеславия, прежде чем отпустить зашифрованный секретный ключ обратно Алисе (например, просить плату за услуги). Я видел что-то вроде этого предложил для тщеславия адресов раньше, но я считаю, что это BIP решает его довольно хорошо. Это точно? Да, но, к сожалению, работает не тонны лучше, чем стандартная практика в настоящее время: отправить открытый ключ, держать закрытый ключ, и объединить их с добавлением EC (моя утилита может сделать это, а). Промежуточный код столь же некрасиво как открытый ключ, и единственное преимущество будет заключаться в том, что первоначальный запрашивающий будет держать вокруг ключевой фразы вместо закрытого ключа. То это не очень полезно, потому что улучшение является ли это фраза или ключ, он больше не нужен, как только адрес тщеславие генерируется ... пользователь не будет иметь интерес к запоминанию его или пытаться выгравировать его в ограниченном пространстве. Кроме того, AFAIK, поколение тщеславия должно использовать сложение ЕС, а не умножение, в противном случае она будет работать слишком медленно, чтобы быть полезными. Добавление EC имеет недостаток безопасности, но это влияет только на очень конкретный случай использования и не влияет на генерацию тщеславия.

8 декабря 2012, 1:57:24 PM	# 12
Nyhm Сообщения: 216 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Спасибо за пояснение. Я знал, что есть какой-то метод генерации тщеславия, но я не был знаком с этим процессом. Я вижу, что BIP38 специально разработана для случаев использования, когда пользователь хочет пароль ключа на основе. (Я пойду читать больше о процессе присоединения ЕС. Когда я изучал криптографию, мы не попали в ЕС так много, как алгоритмы факторизации на основе, и я действительно хочу, чтобы укрепить мое понимание корней Bitcoin.) Вдохновляющими работа - спасибо.

9 декабря 2012, 7:39:33 AM	# 13
thanke Сообщения: 104 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Какова цель шифрования AES во втором методе (режим умножения ЕС)? Вы можете просто разместить seedb в незашифрованном виде зашифрованного секретного ключа вместо encryptedpart1 и 2.

9 декабря 2012, 7:43:55 AM	# 14
thanke Сообщения: 104 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Цитата: casascius от 08 декабря 2012 года, 7:47:39 AM Добавление EC имеет недостаток безопасности, но это влияет только на очень конкретный случай использования и не влияет на генерацию тщеславия. Какой недостаток безопасности?

9 декабря 2012, 6:35:45 PM	# 15
2_Thumbs_Up Сообщения: 323 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Цитата: casascius от 05 декабря 2012 года, 7:20:22 PM Я начинаю дискуссионную тему о технических достоинствах и криптографической разумности моего недавнего предложения о PassPhrase защищенного закрытых ключей. https://en.bitcoin.it/wiki/BIP_0038 Основные особенности: * Зашифрованные ключи пятьдесят восемь Base58Check кодировка символов, начиная с "6P" * Шифрование использует AES-256. Ключевой вывод использует Scrypt. Параметры фиксируются на 16384,8,8; неиспользуемое пространство в формате ключ позволяет будущие изменения спецификации. * Обнаружение опечатки представляет собой 32-битный хэш полученного адреса Bitcoin и требует полного вывода и процесса расшифровки для того, чтобы быть проверен, поэтому он не обеспечивает ускорение для крекеров. Этот 32 бит также используется в качестве соли. * Эллиптический кривой шаг умножения выбирается, позволяя схему, где Алиса может выбрать кодовую фразу и Боб может создать и фонд Bitcoin адресов, только Алиса может расшифровать; спецификация описывает то, что Алиса должна дать Бобу, чтобы это случилось, не разглашая ее ключевую фразу, и определяет Base58Check кодированного формата для него. * Оба сжатых и несжатых форматов открытого ключа выбираются. Полностью функциональная проверка концепции код был опубликован в https://github.com/casascius/Bitcoin-Address-Utility Недавно я побежал конкурс где я создал зашифрованный бумажный бумажник с 5-буквенным паролем, погрузил его с 10 BTC и опубликовал зашифрованный секретный ключ, спрашивая человек, чтобы взломать на него. Прошло два дня, в конечном итоге победитель бросил 20 машин на него, и выиграл только после того, как я просочилась достаточно информации о пароле для сокращения поиска набора в соответствии с 6 миллионов возможных паролей. Его оценка того, сколько времени это заняло бы его искать все (уменьшенный) поиска набор был 45 до 60 часов. Я надеюсь, что мое предложение будет рассматриваться как безопасное достаточно для реализации во всем мире в качестве стандарта, в любом месте кто-то попросил, чтобы обеспечить закрытый ключ для какой-либо причины. Это включает в себя любые частные ключевые развертки или функции импорта в клиенте Satoshi. В рабочем процессе пользовательского интерфейса, если защищенный паролем секретный ключ будет введен, то это должно быть определено автоматически, и пользователь будет предложено: "Введите пароль", В контексте RPC, пароль будет еще один аргумент на звонки. Скажем, Боб создает enrypted Bitcoin адрес. Но вместо того, чтобы посылать это Алисе он отправляет данные Чарли. Я предполагаю, что существует тривиальный способ для Боба proove Чарли, что адрес, верно? Я спрашиваю, потому что я считаю, что это может иметь большие последствия для различных цифровых денежных систем. Видеть:

9 декабря 2012, 7:06:08 PM	# 16
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Цитата: 2_Thumbs_Up 09 декабря 2012 года, 6:35:45 PM Скажем, Боб создает enrypted Bitcoin адрес. Но вместо того, чтобы посылать это Алисе он отправляет данные Чарли. Я предполагаю, что существует тривиальный способ для Боба proove Чарли, что адрес, верно? Я спрашиваю, потому что я считаю, что это может иметь большие последствия для различных цифровых денежных систем. Видеть: Если Боб должны были раскрыть оба "промежуточный код" и зашифрованный закрытый ключ, он создал Чарли~d, то Чарли мог определить, что два из них связаны, и может самостоятельно вычислить адрес Bitcoin. С промежуточным кодом, Чарли может "расшифровывать" шифрование AES на ключах порождена Боба, который, как он может получить адрес Bitcoin, но он по-прежнему не хватает ключевой материал Алисы, который доступен только с оригинальной ключевой фразой, поэтому он не может получить закрытый ключ на самом деле необходимый тратить средства. Предложение, которое я разработка имеет ровно такое же свойство вы описываете, возможно, по той же самой цели вы описываете, но имеет больше возможностей, а именно, Эдди эскроу агент в состоянии высвободить средства Алисе или Бобу, при этом не имея доступа взять их для себя. Это предложение также не полагаться на Эдди для средств, которые будут выпущены к Бобу, как бы типичный случай, если сделка прошла успешно. Посмотрите на это (что может иметь основные нерешенные вопросы, являющиеся проект в стадии разработки). https://en.bitcoin.it/wiki/User:Casascius/Escrow_scheme_draft

10 декабря 2012, 12:11:06 AM	# 17
Стивен Gornick Сообщения: 2352 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Цитата: casascius от 05 декабря 2012 года, 7:20:22 PM * Зашифрованные ключи пятьдесят восемь Base58Check кодировка символов, начиная с "6P" Вы не могли бы обновить эту статью вики, чтобы отразить это? - http://en.bitcoin.it/wiki/List_of_address_prefixes

10 декабря 2012, 8:54:14 PM	# 18
thanke Сообщения: 104 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Цитата: thanke 09 декабря 2012 года, 7:39:33 AM Какова цель шифрования AES во втором методе (режим умножения ЕС)? Вы можете просто разместить seedb в незашифрованном виде зашифрованного секретного ключа вместо encryptedpart1 и 2. Удар. Вопрос по-прежнему спрашивают. Если сторона генерации адреса, зная seedb, не может вычислить частные ключи, то почему seedb никогда не шифруются? Адрес PassPoint * factorb не может быть погашен, не зная кодовую фразу и ownersalt. Есть еще одна причина для шифрования seedb?

10 декабря 2012, 9:09:33 PM	# 19
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Цитата: thanke от 10 декабря 2012 года, 8:54:14 PM Цитата: thanke 09 декабря 2012 года, 7:39:33 AM Какова цель шифрования AES во втором методе (режим умножения ЕС)? Вы можете просто разместить seedb в незашифрованном виде зашифрованного секретного ключа вместо encryptedpart1 и 2. Удар. Вопрос по-прежнему спрашивают. Если сторона генерации адреса, зная seedb, не может вычислить частные ключи, то почему seedb никогда не шифруются? Адрес PassPoint * factorb не может быть погашен, не зная кодовую фразу и ownersalt. Есть еще одна причина для шифрования seedb? Потому что это может быть, и немного больше. По той же причине мы используем SHA256 (SHA256 (любой)) вместо SHA256 (что угодно). Потому что, я полагаю, почему дать атакующему 1 фактор, когда мы можем дать ему 0 факторов в значительной степени без дополнительных затрат. Кроме того, злоумышленник может иметь какое-то преимущество, если у него есть еще один зашифрованный закрытый ключ и знает соответствующий закрытый ключ в незашифрованном виде (но не факторы) для другой пары ключей на основе того же промежуточный код. Если такая атака существует, я не знаю, что это такое, но я сделал, что атака намного сложнее, отрицая атакующую халяву ему необходимо выполнить. Кто-то также отметил то, что я понял так: если кто-то, чтобы сделать СИС взломать их, его работа только что получил, что гораздо сложнее.

11 декабря 2012, 4:48:08 PM	# 20
thanke Сообщения: 104 Цитировать по имени цитировать ответ	Re: BIP 38 Обсуждение Тема - Passphrase-Protected Private Key Format Цитата: casascius от 10 декабря 2012 года, 9:09:33 PM Цитата: thanke от 10 декабря 2012 года, 8:54:14 PM Цитата: thanke 09 декабря 2012 года, 7:39:33 AM Какова цель шифрования AES во втором методе (режим умножения ЕС)? Вы можете просто разместить seedb в незашифрованном виде зашифрованного секретного ключа вместо encryptedpart1 и 2. Удар. Вопрос по-прежнему спрашивают. Если сторона генерации адреса, зная seedb, не может вычислить частные ключи, то почему seedb никогда не шифруются? Адрес PassPoint * factorb не может быть погашен, не зная кодовую фразу и ownersalt. Есть еще одна причина для шифрования seedb? Потому что это может быть, и немного больше. По той же причине мы используем SHA256 (SHA256 (любой)) вместо SHA256 (что угодно). Я не знаю, почему мы используем двойной хэш. Цитата: casascius от 10 декабря 2012 года, 9:09:33 PM Потому что, я полагаю, почему дать атакующему 1 фактор, когда мы можем дать ему 0 факторов в значительной степени без дополнительных затрат. Кроме того, злоумышленник может иметь какое-то преимущество, если у него есть еще один зашифрованный закрытый ключ и знает соответствующий закрытый ключ в незашифрованном виде (но не факторы) для другой пары ключей на основе того же промежуточный код. Если такая атака существует, я не знаю, что это такое, но я сделал, что атака намного сложнее, отрицая атакующую халяву ему необходимо выполнить. Атака может быть: У вас есть две зашифрованных ключей, расшифровать один из них, частично потратить и сохранить расшифрованную версию вокруг для последующих расходов. Предположим, что они оба основаны на том же промежуточном коде и производится без шифрования AES части. Если кто-то находит их (один расшифрованы, один зашифрованный), то, что человек может также провести зашифрованные один. Так что я вижу вашу точку для AES сейчас, если не запрещает повторное использование промежуточных кодов. Другой вопрос: какова цель коды подтверждения? Если я могу расшифровать зашифрованный ключ с моей ключевой фразой, я также могу быть уверен, что адрес зависит от ключевой фразы, и что это только расходуемый с ключевой фразой. Нет необходимости для кода подтверждения кажется.

Заголовок