Формат ключа, защищенный пароль частного экспорта | Биткоин форум

		Биткоин Форум > Разработка и Техническое Обсуждение
Формат ключа, защищенный пароль частного экспорта

10 августа 2011, 4:10:03 PM	# 1
samr7 Сообщения: 140 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Закрытые ключи в формате экспорта базы-58 идеально подходят для перемещения между Bitcoin бумажники, или для безопасного хранения вне wallet.dat. Они в настоящее время используются несколько систем 3-й партии, в том числе BitBills, vanitygen и pywallet. Тем не менее, они очень уязвимы для утечки или кражи, если определенные меры безопасности не принимаются. В то время как встроенный в Bitcoin wallet.dat шифрования способен шифровать закрытые ключи, хранящиеся в wallet.dat, эта защита не распространяется на экспортируемые ключи. Предложенный формат здесь является расширением формата экспорта базы-58 со встроенной защитой пароля. Этот формат использует сильное шифрование и мульти-итерации на основе пароли ключей вывода для шифрования секретного ключа Bitcoin. Как и с любым форматом этого типа, то пароль может быть взломан. Однако, по современным стандартам, это очень трудно, подобной сложности для взлома паролей WiFi WPA2-PSK. Сложные пароли без каких-либо слов из словаря, по крайней мере, девяти символов потребуются более трех лет, чтобы взломать в течение очень находчивого злоумышленника. Обновлено: Текущая схема выглядит следующим образом. Выражается в pixelglow для умных предложений. `privkey` = 32 байт EC закрытый ключ, большой обратный порядок байт форма `пары` = Дескриптор Параметр байт. 0: Краткий формат - без ведущего шифра, 4-байтовый соль, HMAC-SHA256 проверка пароля значение `pbhash` = HMAC-SHA256 `pbiter` = 4096 `шифровать` = AES-256-CBC 16: PKCS # 7-совместимый формат - проложенный шифр, 8-байтовое соль `pbhash` = HMAC-SHA256 `pbiter` = 4096 `шифровать` = AES-256-CBC Для краткой формы: `поваренная соль` = 4-байтовое случайное значение `ключ` знак равно `PBKDF2 (пароль, соль, pbhash, ИТЭР)` (`ключ` Затем разделить на `cipherkeyiv` а также `hmackey`. `hmackey` имеет длину 16 байт.) `pwcheck` знак равно `HMAC-SHA256 (hmackey, privkey)` `protkey = пары \| Шифр (privkey, cipherkeyiv, без ведущего) \| pwcheck [0:64] \| поваренная соль` Результат составляет 45 байт для большинства шифров Для PKCS # 7-совместимый формат: `поваренная соль` = 8-байтовое случайное значение `cipherkey` знак равно `PBKDF2 (пароль, соль, pbhash, ИТЭР)` `protkey = пары \| Шифр (privkey, cipherkey) \| поваренная соль` Результат составляет 58 байт для большинства шифров `protkey` значение, то есть класс данных байт (32 или 79) с префиксом к началу, и является основанием 58 кодируется в соответствии с функцией Биткойн `EncodeBase58Check ()`. Ниже приведен пример закрытого ключа защищен паролем, используя эту схему, с помощью тестового пароля `password1`: `Адрес: 1HacknYhLRpttqGAiBew1fQAKRGnMorkxk Privkey: 5JmsuCoDBDTPT8oBxx1Vv4cy9Fw14456rt7hvMKmvQY1DES2w6z Protkey: PsQg61gLtNX6bg7PG8Kw9bpdFEfuP8h1Ri8dAoBjRpV1i1rPPx72EYrGgi7CfWWkbutH Protkey: 2uhT7zkgeGXpVEw4aYTnCyAvTQ9G1hqSGPPNS5EpC4W62J28euHT8o9CQnKrZCqYwhcHgrxBASsWzYT bF3Qcx`(Осторожный: длинная форма выше, имеет дополнительное пространство, добавленное в форуме) Краткое представление делает некоторые конкретные компромиссы, чтобы сохранить короткое представление. В этом режиме блока шифрование выполняются без какой-либо PKCS # 7 обивки в конце. Поскольку прокладка обеспечивает способ проверки правильности пароля, значение HMAC `pwcheck` вычисляется и добавляется к выходу. `pwcheck` значение вычисляется с использованием HMAC-SHA256 хэш открытого текста секретного ключа, используя 16 байт ключа материала, взятого из функции PBKDF2 в качестве ключа сообщения. Это экономит несколько байт в окончательном представлении. Значение соли также занимает всего четыре байта, короче, чем рекомендовано восемь. Эта схема, если кто-то не может совать большое отверстие в нем или рекомендовать полезные изменения, будет отображаться в качестве дополнительного выходного формата в следующей версии vanitygen, наряду с паролем кодеком. Пример из JavaScript из пароля кодека доступен Вот. Она работает в вашем браузере, но не передает ключи или пароли по сети. Bounty: У меня нет много биткойна, чтобы бросить на это, но 5 BTC перейти к первому человеку, который может снять защиту с ниже ключа: `1NPHardFPnejsycvne2gvirm5MCr9gnAbf PsV8XM6n5FvjonHPwwjzqvzA6UXruAAJfQ5VwbXFCJrSQEiQ4gyNNDhuYfL8JUBt6mxt` Чтобы подсластить сделку: пароль длиной 14 символов, только с верхними и строчными буквами, и содержит по крайней мере один словарное слово.

Как заработать Биткоины?
Без вложений. Не майнинг.

10 августа 2011, 6:32:58 PM	# 2
ошибка Сообщения: 574 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Получил 1806 Биткоинов Реальная история. NPHard. Веселая. Мой первый вопрос, почему вы привязались, чтобы сохранить 4 байта здесь и там? Это не так, как мы бежим из космоса на наших гибких дисках?

10 августа 2011, 7:20:21 PM	# 3
dogisland Сообщения: 262 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Цитата: ошибки 10 августа 2011 года, 6:32:58 PM NPHard. Веселая. Мой первый вопрос, почему вы привязались, чтобы сохранить 4 байта здесь и там? Это не так, как мы бежим из космоса на наших гибких дисках? Это полезно, если вам нужно ввести секретный ключ в диалоге на импорт. Например, вы можете сохранить ваши личные ключей в бумажном кошельке.

10 августа 2011, 7:31:49 PM	# 4
ошибка Сообщения: 574 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Цитата: dogisland от 10 августа 2011 года, 7:20:21 PM Цитата: ошибки 10 августа 2011 года, 6:32:58 PM NPHard. Веселая. Мой первый вопрос, почему вы привязались, чтобы сохранить 4 байта здесь и там? Это не так, как мы бежим из космоса на наших гибких дисках? Это полезно, если вам нужно ввести секретный ключ в диалоге на импорт. Например, вы можете сохранить ваши личные ключей в бумажном кошельке. Хм, в этом случае общая длина не так важно, как визуальные разрывы. Подумайте о том, как Microsoft выводит свои ключи продукта, что люди должны ввести, чтобы активировать Windows.

10 августа 2011, 7:44:59 PM	# 5
kjj Сообщения: 1302 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Разница между 8 байт соли и 4 байта соли в не 4 байта, и это не является фактором 2. Это является фактором более 4 млрд. Это разница между "Есть минутка?" а также "Через некоторое время после окончания Вселенной", На самом деле, это, вероятно, не то, что крупные сделки. Предвычисление таблицы AES не является тривиальной задачей, и даже 4 или 5 битых соли, вероятно, достаточно, чтобы сделать это непрактично для далеко за пределы потенциальной жизни одного из этих защищенных ключей. Но криптосистемы разработаны с глубоко эшелонированной защитой для очень веских причин. Когда слабость в одной части обнаружена, что, как правило, не катастрофа, потому что мы добавили избыточные меры безопасности. Итак, вопрос: Является ли экономия нескольких нажатий клавиш, может быть, несколько раз в год для, возможно, пару миллиардов пользователей, стоит небольшой риск, что перерыв AES не будет "уф, должны обновление", Но вместо того, чтобы быть "Все ваши адреса принадлежат нам"? Я хотел бы голосовать за дополнительные нажатия клавиша, но это может быть просто мне. Кстати, это отличная идея. Одна мысль, что пришло на ум, было встраивание метаданных в сам ключ, используя DER. Так как эти ключи не могут быть использованы в сети, они должны, возможно, не будут присвоен ключом версии префикса.

10 августа 2011, 7:54:41 PM	# 6
samr7 Сообщения: 140 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Цитата: ошибки 10 августа 2011 года, 7:31:49 PM Хм, в этом случае общая длина не так важно, как визуальные разрывы. Подумайте о том, как Microsoft выводит свои ключи продукта, что люди должны ввести, чтобы активировать Windows. Это очень хороший момент. Сегментация как это то, что обычные адреса Bitcoin может воспользоваться, а также - набрав в 34 символов, достаточно сложно. Таким образом, защищенный паролем ключ выше, может выглядеть примерно так: `PAYxy8-B9zhSG-pbyC7Z-29KRS7-rsPzAc-TF3zSP-myAigb-AJYamt-9GmNws-FT9E95-dGfp6Ri` И адрес: `1Hackn-YhLRpt-tqGAiB-ew1fQA-KRGnMo-rkxk` Разрывы уверены, сделать его легко запомнить, где вы остановились, и они чертовски много легче транскрибировать и из бумаги, или между экранами! Но, ключ защищен паролем теперь только едва вписывается в терминал с 80 колонками, и с чем-нибудь приставкой в начале строки, она будет переливаться. Может быть, эта идея заслуживает свою собственную нить.

10 августа 2011, 7:56:16 PM	# 7
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Цитата: kjj от 10 августа 2011 года, 7:44:59 PM Разница между 8 байт соли и 4 байта соли в не 4 байта, и это не является фактором 2. Это является фактором более 4 млрд. Это разница между "Есть минутка?" а также "Через некоторое время после окончания Вселенной", На самом деле, это, вероятно, не то, что крупные сделки. Предвычисление таблицы AES не является тривиальной задачей, и даже 4 или 5 битых соли, вероятно, достаточно, чтобы сделать это непрактично для далеко за пределы потенциальной жизни одного из этих защищенных ключей. Но криптосистемы разработаны с глубоко эшелонированной защитой для очень веских причин. Когда слабость в одной части обнаружена, что, как правило, не катастрофа, потому что мы добавили избыточные меры безопасности. Итак, вопрос: Является ли экономия нескольких нажатий клавиш, может быть, несколько раз в год для, возможно, пару миллиардов пользователей, стоит небольшой риск, что перерыв AES не будет "уф, должны обновление", Но вместо того, чтобы быть "Все ваши адреса принадлежат нам"? Я хотел бы голосовать за дополнительные нажатия клавиша, но это может быть просто мне. Кстати, это отличная идея. Одна мысль, что пришло на ум, было встраивание метаданных в сам ключ, используя DER. Так как эти ключи не могут быть использованы в сети, они должны, возможно, не будут присвоен ключом версии префикса. Я думаю, что этот аргумент вроде уклоняется целью соли однако. Соль не секрет - это закодированная явно в зашифрованном ключ и свободно доступны для злоумышленника - так после определенной точки, это действительно не имеет значения, сколько бит это. Весь смысл соли, если я правильно понимаю, это просто сделать это неосуществимо взломать целую партию одновременно с тем же усилием (например, с предварительно сгенерированными таблицами радуги), заставляя атакующий сосредоточиться на взлом одного ключа на время. Если я прав, то соль нужно только достаточное количество битов, чтобы быть вряд ли столкнется с другими кодами, которые могут быть приобретены таким же атакующим и крекинг в рамках одной партии. EDIT: Я бы даже рекомендовать меньше бит пошли в проверки пароля. Как, возможно, всего лишь 8. Это позволит сделать его еще дороже бессловесные пароли силы, так как это приведет к огромному количеству ложных срабатываний, которые могут быть проверены только делая трудоемкую ЕС многократно (для получения адреса Bitcoin ) и база данных поиск (чтобы увидеть, если есть какая-либо монета по этому адресу, только чтобы найти их нет). В случае опечатки, даже с 8 битами, по-прежнему >99% шанс, что он все равно будет пойман. Проверка пароля, как он стоит, вероятно, просто подарок для взломщика.

10 августа 2011, 9:05:24 PM	# 8
samr7 Сообщения: 140 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Цитата: kjj от 10 августа 2011 года, 7:44:59 PM Разница между 8 байт соли и 4 байта соли в не 4 байта, и это не является фактором 2. Это является фактором более 4 млрд. Это разница между "Есть минутка?" а также "Через некоторое время после окончания Вселенной", На самом деле, это, вероятно, не то, что крупные сделки. Предвычисление таблицы AES не является тривиальной задачей, и даже 4 или 5 битых соли, вероятно, достаточно, чтобы сделать это непрактично для далеко за пределы потенциальной жизни одного из этих защищенных ключей. Но криптосистемы разработаны с глубоко эшелонированной защитой для очень веских причин. Когда слабость в одной части обнаружена, что, как правило, не катастрофа, потому что мы добавили избыточные меры безопасности. Вы делаете некоторые очень хорошие моменты об этом. С точкой зрения цели, солей, что будет модель использования любого рода предвычисленных таблиц для этой проблемы? Похоже, что это будет ограничено создание списка ключей AES, полученных из возможных паролей, каждый из которых должен был бы быть испытаны, по-прежнему требует экспоненциального времени в длину пароля, но позволяя злоумышленнику обойти запуск дорогостоящую функцию PBKDF для каждого теста. Есть ли что-то тапок и еще более изощренная, что злоумышленник может сделать с этой конкретной проблемой? Я не думаю, что это похоже на попытку построить таблицу для хэш-функции, где выходы зависят только пароль и соли, в этом случае злоумышленник может индексировать выхода к входам и создать настоящую таблицу поиска или ее радуга стол. Во всяком случае, если это правда, то в 48 байт на AES ключ + IV, и 2 ^ 32 солей вариаций каждого из них, злоумышленник должен был бы быть в состоянии хранить 192GB на предвычисленными пароль. По крайней мере, без какого-то хитрого способа сжатия цифровых клавиш. Это намного проще, чем 2 ^ 64 вариантов каждого из них, но до сих пор кажется неразрешимой. Компромисс на наличие четырех дополнительных байтов хэша будет шесть дополнительных символов в закодированном выходе. Пример бок о бок ниже: `PAYxy8B9zhSGpbyC7Z29KRS7rsPzAcTF3zSPmyAigbAJYamt9GmNwsFT9E95dGfp6Ri 3W3qzi2Sow4o7LP7jwwnrmqiiGxyMcwLdubKxYhNy4J63eigN3jz7avYqSWfGwxz3nMDDXwwc` Редактировать: Это возможно, используя меньшее значение типа байт, чтобы уменьшить его до пяти дополнительных символов. Ваше замечание по поводу смягчения слабости хорошо принято, хотя, и компромисс может быть стоят. Цитата: casascius от 10 августа 2011 года, 7:56:16 PM EDIT: Я бы даже рекомендовать меньше бит пошли в проверки пароля. Как, возможно, всего лишь 8. Это позволит сделать его еще дороже бессловесные пароли силы, так как это приведет к огромному количеству ложных срабатываний, которые могут быть проверены только делая трудоемкую ЕС многократно (для получения адреса Bitcoin ) и база данных поиск (чтобы увидеть, если есть какая-либо монета по этому адресу, только чтобы найти их нет). В случае опечатки, даже с 8 битами, по-прежнему >99% шанс, что он все равно будет пойман. Проверка пароля, как он стоит, вероятно, просто подарок для взломщика. Функция PBKDF здесь требует 8192 раундов функции SHA256 хэш, поэтому она должна быть уже намного дороже, чем вычисление адреса Bitcoin и ищет его в списке. Даже если злоумышленник использовал таблицу, имея необходимость сделать операцию ЕС так часто, как каждые 2 ^ 8 клавиш, вероятно, не вызовет большой спад. Но, это сделает взломщик паролей немного сложнее. Для одного человека, который получает письмо от своего пароля неправильно, и это не повезло достаточно, чтобы он молча принял и сопоставляется с неправильной учетной записью, а также адрес Bitcoin не известен или не по сравнению с ожидаемым значением, они лучше надеюсь, защищенный пароль версия их ключ не выбрасывала.

11 августа 2011, 2:01:40 AM	# 9
pixelglow Сообщений: 19 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Цитата: samr7 от 10 августа 2011 года, 4:10:03 PM Схема, которую я предложил dogisland проекта StrongCoin выглядит следующим образом. `privkey` = 32 байт EC закрытый ключ, большой обратный порядок байт форма `поваренная соль` = 4-байтовое значение случайного соли `symkey` знак равно `PBKDF (пароль, соль, SHA256, 4096)` `pwcheck` знак равно `SHA256 (SHA256 (privkey \| соль))` `protkey = AES-CBC-256 (privkey, symkey) \| pwcheck [0:64] \| поваренная соль` 44-байтовый `protkey` значение, то есть тип байт (136) префикс к началу, и является основанием 58 кодируется в соответствии с функцией Биткойн `EncodeBase58Check ()`. Интересно, хотя ваше наслоение / составление различных криптографических схем может вернуться укусить вас. Как я понимаю, вы хотите, чтобы зашифровать пароль, а также убедиться в том, что зашифрованные биты остаются неизменными. Вот небольшая модификация выше: `privkey` = 32 байт EC закрытый ключ, большой обратный порядок байт форма `поваренная соль` = 4-байтовое значение случайного соли `symkey` знак равно `PBKDF2 (HMAC-SHA1, пароль, соль, 4096, 64)` `cryptedprivkey` знак равно `(Privkey исключающее symkey [0:32])` `pwcheck` знак равно `HMAC-SHA1 (symkey [33:64], cryptedprivkey)` `protkey = cryptedprivkey \| pwcheck \| поваренная соль` Вы должны использовать более позднюю PBKDF2 (http://www.di-mgt.com.au/cryptoKDFs.html), Что позволяет производить произвольные ключи длины. В этом случае мы генерации ключа длиной 64-байт, половина из которых мы будем использовать для шифрования, а другая половина для аутентификации. Далее мы зашифровать privkey с половиной symkey по XOR-их вместе, простой потоковый шифр. Это позволяет избежать использования AES в коде клиента (медленно в Javascript ?, отсутствует вектор инициализации, открытый текст длина < AES размер блока 128 бит) и должно быть довольно безопасно. Потоковые шифры как RC4 просто случайный поток ключи XOR с открытым текстом и трудно сломать, при условии, что случайный ключевой поток действительно непредсказуемый, и вы никогда не повторять ключ. Проблема с потоковыми шифрами, то проявляется, когда у вас есть достаточно большой куска данных для кодирования, то без надлежащего CPRNG как RC4 Ключевого потока может повторить и т.д., и, таким образом, блочные шифры под CBC стать полезными. Поскольку у нас есть 32-байтовый секретный ключ и 32-байтовый symkey для XOR вместе, это не должно быть проблемой. Затем мы используем MAC, в частности с HMAC-SHA1, выступать в качестве проверки пароля против изменений. Мы используем вторую половину symkey как секрет. HMAC являются особенно предназначены для проверки подлинности сообщения. В качестве альтернативы (безопаснее / более параноидально), вы можете использовать две соли для получения двух 32-байтовых ключей, один для шифрования, один для аутентификации.

11 августа 2011, 4:19:24 PM	# 10
samr7 Сообщения: 140 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Цитата: pixelglow от 11 августа 2011 года, 2:01:40 AM Интересно, хотя ваше наслоение / составление различных криптографических схем может вернуться укусить вас. Как я понимаю, вы хотите, чтобы зашифровать пароль, а также убедиться в том, что зашифрованные биты остаются неизменными. Вот небольшая модификация выше: `privkey` = 32 байт EC закрытый ключ, большой обратный порядок байт форма `поваренная соль` = 4-байтовое значение случайного соли `symkey` знак равно `PBKDF2 (HMAC-SHA1, пароль, соль, 4096, 64)` `cryptedprivkey` знак равно `(Privkey исключающее symkey [0:32])` `pwcheck` знак равно `HMAC-SHA1 (symkey [33:64], cryptedprivkey)` `protkey = cryptedprivkey \| pwcheck \| поваренная соль` Вы должны использовать более позднюю PBKDF2 (http://www.di-mgt.com.au/cryptoKDFs.html), Что позволяет производить произвольные ключи длины. В этом случае мы генерации ключа длиной 64-байт, половина из которых мы будем использовать для шифрования, а другая половина для аутентификации. Далее мы зашифровать privkey с половиной symkey по XOR-их вместе, простой потоковый шифр. Это позволяет избежать использования AES в коде клиента (медленно в Javascript ?, отсутствует вектор инициализации, открытый текст длина < AES размер блока 128 бит) и должно быть довольно безопасно. Потоковые шифры как RC4 просто случайный поток ключи XOR с открытым текстом и трудно сломать, при условии, что случайный ключевой поток действительно непредсказуемый, и вы никогда не повторять ключ. Проблема с потоковыми шифрами, то проявляется, когда у вас есть достаточно большой куска данных для кодирования, то без надлежащего CPRNG как RC4 Ключевого потока может повторить и т.д., и, таким образом, блочные шифры под CBC стать полезными. Поскольку у нас есть 32-байтовый секретный ключ и 32-байтовый symkey для XOR вместе, это не должно быть проблемой. Затем мы используем MAC, в частности с HMAC-SHA1, выступать в качестве проверки пароля против изменений. Мы используем вторую половину symkey как секрет. HMAC являются особенно предназначены для проверки подлинности сообщения. В качестве альтернативы (безопаснее / более параноидально), вы можете использовать две соли для получения двух 32-байтовых ключей, один для шифрования, один для аутентификации. Отлично!! Pixelglow, вы на самом деле, кажется, знаю ваши вещи, ты про ?? PBKDF, что я использую не совсем PKCS # 5 v1, это на самом деле EVP_BytesToKey OpenSSL (в). Это похоже, но будет производить сколь угодно большой материал ключа. В противном случае, там, конечно, не будет достаточно ключевой материал для SHA256 с использованием AES IV. Несмотря на это, используя PBKDF2 с функцией HMAC, казалось бы очень желательным изменение, а также, кажется, очень легко получить с помощью OpenSSL. Что касается pwcheck, то использование функции HMAC там с каким-то дополнительным ключевым материалом также представляется как соответствующий инструмент для работы, тем более, чем мой взломан-вместе месиво. не могу сказать, не к тому, что либо. Вы рекомендовали бы HMAC-SHA1 над HMAC-SHA256? Кто-то умный сказал, что работа закончена не тогда, когда было добавлено все, что можно добавить к этому, но когда все, что может быть удален был удален. AES может вписаться в эту категорию. Тем не менее, другие подобные схемы защиты пароля, включая Bitcoin встроенного шифрования бумажника, а также использовать AES для фиксированного размера закрытых ключей, и это нервы, чтобы заменить его XOR, даже если это может быть правильным, что нужно сделать. Большое спасибо!!

12 августа 2011, 2:17:19 AM	# 11
pixelglow Сообщений: 19 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Цитата: samr7 от 11 августа 2011 года, 4:19:24 PM Pixelglow, вы на самом деле, кажется, знаю ваши вещи, ты про ?? Я всего лишь обычный программист с математическим образованием, следовательно, интерес к криптографии. Я когда-то работал на схему DRM шрифт, который использовал криптографию, и я в настоящее время работаю над австралийским обменом Bitcoin, которая будет отличать криптографию, а также. Остальное только Google. котировка PBKDF, что я использую не совсем PKCS # 5 v1, это на самом деле EVP_BytesToKey OpenSSL (в). Это похоже, но будет производить сколь угодно большой материал ключа. В противном случае, там, конечно, не будет достаточно ключевой материал для SHA256 с использованием AES IV. http://www.openssl.org/docs/crypto/EVP_BytesToKey.html кажется, указывает, следует перейти к PKCS # 5 v2.0, которая PBKDF2. котировка Несмотря на это, используя PBKDF2 с функцией HMAC, казалось бы очень желательным изменение, а также, кажется, очень легко получить с помощью OpenSSL. Действительно, есть функция PKCS5_PBKDF2_HMAC_SHA1 в OpenSSL. Я просто представила патч для node.js, чтобы включить это: https://github.com/joyent/node/pull/1491 котировка Что касается pwcheck, то использование функции HMAC там с каким-то дополнительным ключевым материалом также представляется как соответствующий инструмент для работы, тем более, чем мой взломан-вместе месиво. не могу сказать, не к тому, что либо. Вы рекомендовали бы HMAC-SHA1 над HMAC-SHA256? RFC 2104 (http://tools.ietf.org/html/rfc2104), Кажется, думает, что любая половина приличная cryptohash будет делать, даже MD5 (!), Так как HMAC имеет секретный ключ, который значительно увеличивает объем вычислений вам нужно сделать, чтобы разорвать его. Я предложил HMAC-SHA1, так как PBKDF2 в OpenSSL основан на ней (симметрию!), Он, кажется, используется достаточно часто (более новые схемы менее криптоанализ сделаны, может иметь недостатки, вы не ожидаете особенно используются в тандеме как с HMAC ) и дает меньший выход. котировка Кто-то умный сказал, что работа закончена не тогда, когда было добавлено все, что можно добавить к этому, но когда все, что может быть удален был удален. AES может вписаться в эту категорию. Тем не менее, другие подобные схемы защиты пароля, включая Bitcoin встроенного шифрования бумажника, а также использовать AES для фиксированного размера закрытых ключей, и это нервы, чтобы заменить его XOR, даже если это может быть правильным, что нужно сделать. В самом деле. Простые схемы лучше всего работают иногда в шифровании, так как меньше ошибутся. Что касается использования XOR, проверить статью Википедии о Вернамом шифров: http://en.wikipedia.org/wiki/Vernam_cipher. TL; DR: до тех пор, пока ключ действительно случайным, так как большой, как открытый текст и никогда не использовать повторно в целом или его части, она должна быть нерушимой. Очевидно, что мы не можем получить первый 100%, так как мы начинаем с человеческим паролем и PBKDF2 я думаю, что не дает никаких гарантий относительно случайности результата. Второе требование справедливо. Последнее требование должно быть обеспечено за счет использования случайных солей. Есть ли использование Bitcoin шифрования AES с одним ключом на всем кошельке, или AES на отдельных клавишах (без капельницы или, начиная с той же точкой)? Первый из них является довольно разумным. Последнее может быть опасно, так как вы эффективно повторно использовать ключ.

12 августа 2011, 11:36:38 AM	# 12
Pieter Wuille Сообщения: 1050 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Я не уверен, что ваш случай использования здесь. Зашифрованные отвалы бумажника, очевидно, полезно, но я думаю, что они бывают двух категорий: 1) в сочетании с зашифрованным кошельком, только свалкой зашифрованных ключей в нем. Это позволит вам экспортировать и импортировать дамп без ввода пароля. Я считаю, что это самый безопасный вариант, но это будет по сути своей конкретной реализации (шифрование внутри Bitcoin, как запланировано на 0.4.0, использует ключи EVP-SHA512, полученные из пароля, используемых для шифрования 256-битный мастер-ключ с помощью AES256 -CBC кошелька сами ключи шифруются с помощью этого мастер-ключ с помощью AES256-CBC, с хэш их Публичных как IV). 2) портативный формат для обмена бумажники (надеюсь между несколькими приложениями). если шифрование не зависит от самого хранения бумажника, это означает, что экспорт требует знаний бумажника ключевой фразы + другого ключ шифрования дампа с. Хотя, безусловно, есть заслуга в этом это внутри Bitcoin сам по себе, я не думаю, что есть что-нибудь лучше, чем делать нормальный бумажник дамп + GPG / OpenSSL / ... шифрованием.

12 августа 2011, 1:10:49 PM	# 13
dogisland Сообщения: 262 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Цитата: Pieter Wuille 12 августа 2011, 11:36:38 AM Я не уверен, что ваш случай использования здесь. Зашифрованные отвалы бумажника, очевидно, полезно, но я думаю, что они бывают двух категорий: Речь идет не о демпинге бумажника, но общая схему шифрования закрытых ключей. Возможный вариант использования Вы можете сгенерировать автономный бумажный кошелек, содержащий ряд общих адресов Bitcoin и соответствующих им закрытых ключей. Частные ключи будут зашифрованы с помощью пароля только вы знаете, но в стандартном формате. Основная причина, чтобы иметь стандартное шифрование для закрытого ключа является то, что если вы хотите, чтобы выкупить монеты по этим адресам Bitcoin-клиент или интернет-кошелек сможет расшифровать их для вас, когда вы даете свой пароль. Кроме того, интернет-кошелек может хранить зашифрованные ключи для вас. Вам не придется беспокоиться о сервисе будучи атаковано, частные ключи будут бесполезны, без паролей. (Предполагается, что сильные пароли). Надеюсь это поможет.

12 августа 2011, 1:51:15 PM	# 14
Pieter Wuille Сообщения: 1050 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Правильно, конечно. Я просто обобщил вещи немного. Если вы говорите о закрытых ключей, то distiction остается: либо вы хотите экспортировать / импортировать, что в уже зашифрованном бумажнике (полезно для резервного копирования), или вы хотите сделать шифрование отдельно. Цель здесь, кажется, второй случай, который прекрасно. Это просто означает, что вы должны будете как бумажник ключевой фразы и пароль ключа готов, если вы хотите импортировать. Кроме того, с учетом используемой версии байт, может следовать эта нить? Я бы сказал, что шифрованные privkeys образуют новый класс данных.

12 августа 2011, 4:04:23 PM	# 15
samr7 Сообщения: 140 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Цитата: Pieter Wuille 12 августа 2011 года, 1:51:15 PM Если вы говорите о закрытых ключей, то distiction остается: либо вы хотите экспортировать / импортировать, что в уже зашифрованном бумажнике (полезно для резервного копирования), или вы хотите сделать шифрование отдельно. Цель здесь, кажется, второй случай, который прекрасно. Это просто означает, что вы должны будете как бумажник ключевой фразы и пароль ключа готов, если вы хотите импортировать. Абсолютно! Цель состоит в том, чтобы обрабатывать манипуляцию независимо друг от друга и не зависит от главного ключа конкретного зашифрованного кошелька. Таким образом, если оно было использовано для экспорта, было бы не так удобно, как "backupwallet," и по меньшей мере один экспортный пароль не потребуется. Но это может быть реализовано, чтобы быть более удобным, чем dumpwallet + GPG. котировка Кроме того, с учетом используемой версии байт, может следовать эта нить? Я бы сказал, что шифрованные privkeys образуют новый класс данных. Благодаря! Я отправил записку в список и ссылки, что нить.

12 августа 2011, 6:28:32 PM	# 16
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Две различные схемы шифрования и / или паролей кажется плохой идеей для меня, как с точки кода обслуживания / зрения безопасности и удобства использования с точки зрения из-. Вы можете расширить "закрытые ключи в формате экспорт базы-58 прекрасно подходит для перекачки вокруг" - что случай использования? Кто вы обменивать с, и как?

12 августа 2011, 6:50:23 PM	# 17
kjj Сообщения: 1302 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Мы находимся в точке, где внешние утилиты начинают нуждаться в более широком доступе к кошельку. См pywallet, для примера очень полезный инструмент, который я хочу у меня не было, чтобы закрыть мой клиент, чтобы использовать. Один из вариантов будут иметь клиент открыть базу данных бумажника без полной блокировки, так, чтобы другие вещи могли использовать его в то же время. В этом случае, используя за ключ шифрования внутри бумажника будет хорошая вещь наверняка. Но большинство вещей, которые бы позволили, позволяя одновременный доступ бумажника также может быть сделано через RPC, если мы можем просто сделать команды правильной RPC. Да, и мы, возможно, потребуется, по крайней мере немного зернистости в системе безопасности RPC. Во всяком случае, эти шифрованные одиночные ключи всегда будут полезны в качестве формата передачи для перемещения ключей между серверами, архивированием на бумагу или компакт-диски, в автономном режиме генерации и т.д., являются ли они полезны в качестве альтернативного формата хранение внутри кошелька будет зависеть от того, мы идти с RPC или разблокирование базы данных.

12 августа 2011, 6:54:09 PM	# 18
ошибка Сообщения: 574 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Я убежден, в этой точке, которая должна быть полностью утилизирован и переработан с нуля формата бумажник на диске. К сожалению, я, скорее всего, есть свободное время посвятить работе над этим нет.

12 августа 2011, 6:55:44 PM	# 19
kinlo Сообщения: 263 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Если особое внимание следует перейти к вводу секретного ключа с помощью клавиатуры, что делает его коротким и так далее, не должен формат предвидеть несколько контрольных суммы для обнаружения ошибок ввода вместо стандартной проверки хэша предоставленного EncodeBase58Check? Если вы хотите разделить длинный секретный ключ - скажем - 6 блоков, контрольной сумма для каждого блока вместо одного на всей строке, как EncodeBase58Check делает прямо сейчас, ГИП, которые позволяют ввести ключ в части был бы способен hilighting определенной части в красный, который содержит опечатку, вместо недействительности всего входа.

12 августа 2011, 7:00:49 PM	# 20
samr7 Сообщения: 140 Цитировать по имени цитировать ответ	Re: секретный ключ формат экспорт, защищенный пароль Цитата: Гэвин Андресен 12 августа 2011 года, 6:28:32 PM Две различные схемы шифрования и / или паролей кажется плохой идеей для меня, как с точки кода обслуживания / зрения безопасности и удобства использования с точки зрения из-. Вы можете расширить "закрытые ключи в формате экспорт базы-58 прекрасно подходит для перекачки вокруг" - что случай использования? Кто вы обменивать с, и как? Перестановка вокруг средства хранения секретного ключа снаружи из wallet.dat, либо импортировать в другой wallet.dat или другой Bitcoin реализации клиента. Это формат обмен, а не конкретная реализация бумажника. Предложенный формат здесь является расширение, которое позволяет экспортированный закрытый ключ, чтобы быть защищен паролем. Естественно, если это должно быть взаимозаменяемыми с другим Bitcoin кошельке или другой реализации, он не должен / не может быть защищен, используя тот же пароль или главный ключ в качестве кошелька, из которого он пришел (если кошелек шифруется). Первоначальный вариант использования, чтобы позволить кому-то использовать vanitygen, чтобы сформировать адрес, и надежно хранить закрытый ключ, пока он не будет в последствии импортировать в клиент. Во всяком случае, я думаю, что это предложение является ортогональным к шифрованию wallet.dat. Если вы предпочитаете этот формат следовать тому же пароль и выводу схеме шифрования в качестве мастер-ключей Bitcoin системы шифрования бумажника, это, конечно, возможно. Они уже очень похожи, и, пока pixelglow не вышел и рекомендовал PBKDF2, они оба использовали EVP_BytesToKey (). Я не думаю, что случаи использования между главным ключом бумажника и формат экспорта защищенных паролем совсем то же самое, хотя.

« Предыдущая тема | Следующая тема »

Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW