Предложение (+ доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin Частные ключи

Недавно я предложил частный формат ключ для Bitcoin частных ключей, которые требуют пароля для того, чтобы использовать. Сегодня я с поправками мое предложение включить парольную фразу шифрования AES на основе, и обновил свой Casascius Bitcoin Адрес утилиты для работы в качестве доказательства-концепции. Это понятие доказательства правильности может печатать PassPhrase зашифрованного бумажных бумажников, а также расшифровать зашифрованные секретные ключи.

Предложение: https://en.bitcoin.it/wiki/User:Casascius/Base58Check-encoded_objects_proposal
Доказательство концепции с источником: https://casascius.com/bitaddress.zip

Краткая информация о предложении:

* Ключи начинаются с "6p", И посмотреть, как (например): 6poiKAg7ZAGGLGfTMcwaqHixuEU3txKjFsDpxfxrmBrY6bAPwLjcfp
* AES256 используется. SHA256 (ключевая фраза) является ключевым. Чтобы сохранить ключ короткий, не используется вектор инициализации, хотя сцепление сохраняется.
* Спецификация включает в себя битовый флаг для указания, должен ли быть сжат открытый ключ.
* В спецификации включает в себя 14-битную контрольную сумму на ключевой фразе, так что большинство Passphrase опечатки может быть обнаружена и отклонена.

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

Я реализовать шифрование AES как часть Strongcoin PDF бумаги бумажника.

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

https://www.strongcoin.com/en/blog/decrypting_private_keys_generated_with_strongcoin

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

Это отличная идея, и мы бы стандартизировать бумажные бумажники, которые были бы велики.

Привет Casascius,

Вместо того чтобы использовать SHA256 (пароль), почему бы не использовать Scrypt в качестве KDF?

Если взглянуть на предлагаемом / а Multibit альфа существует спецификация для bitcoinj зашифрована частных ключей вы можете увидеть, что Scrypt выбрана в качестве KDF из-за его устойчивость к реализации кремния:

https://docs.google.com/document/d/1Z7kUZJePDS274mawMlMgQwN7C-W88f_ITL4l0F5SVDY/edit

Я считаю, что Scrypt + AES также используется в Оружейной.

Вы упоминаете, что IV не используется, но первый блок АЭС должен быть инициализирован с * что-то *. Я предлагаю вам явно указать 16 байт 0x00 придавить спецификации.

Если вы используете Scrypt как KDF, указать точные параметры, которые будут использоваться таким образом, что не существует никакой двусмысленности (например, см по умолчанию в документе Google.)

Цитата: jim618 13 августа 2012, 12:02:21 PM

Вы упоминаете, что IV не используется, но первый блок АЭС должен быть инициализирован с * что-то *. Я предлагаю вам явно указать 16 байт 0x00 придавить спецификации.

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

Что касается ключевого вывода: только с помощью SHA256 (парольной фразы) выставят адреса в blockchain к относительно простой грубой силы атаки (связанной только с умножением ЕС, в SHA256 круглого и ripemd160 раунда).

Одна вещь, которую я рекомендовал бы использовать что-то ANYTYHING кроме SHA-256 для KDF. ~~AES-256~~ SHA-256 уже быстрый алгоритм IT никогда не предназначался для ключевых производных обязанностей. Однако быстро, как это, скорее всего, это все равно будет "достаточно хорошо" ... для этого называется добычи, за исключением. Существует уже огромный финансовый стимул для более быстрого и лучшего шахтеры как в алгоритмах (OpenCL оптимизаций, FPGA битового поток оптимизации), так и в аппаратных средств и, таким образом, мы видели огромное количество оптимизации. Использование SHA-256 позволяет злоумышленнику использовать все, что "инвестиции" при очень низкой стоимости. Даже при использовании SHA-512 была бы предпочтительнее.

Это подводит меня ко второму вопросу. Действительный секретный ключ является произвольным, что означает шифрование не лучший вариант.

Зачем идти:
Ключевая фраза -> KDF -> ключ
ключ & зашифрованный закрытый ключ -> расшифрован секретный ключ

почему бы просто не пойти
Ключевая фраза -> KDF (PBKDF2, Scrypt, Bcrypt) -> Секретный ключ

котировка

Это подводит меня ко второму вопросу. Действительный секретный ключ является произвольным, что означает шифрование не лучший вариант.

Зачем идти:
Ключевая фраза -> KDF -> ключ
ключ & зашифрованный закрытый ключ -> расшифрован секретный ключ

почему бы просто не пойти
Ключевая фраза -> KDF (PBKDF2, Scrypt, Bcrypt) -> Секретный ключ

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

Правда, я не думал об этом.

"атакующий оптимизировано" KDF является большим вопросом.

Цитата: casascius 13 августа 2012, 12:11:04 AM

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

Пожалуйста, не представить BIP для схемы шифрования, которая несоленое и использует слабый KDF на поставки пользовательских паролей. Особенно не сделать это с быстрым значением обнаружения ошибок.

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

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

Цитата: Pieter Wuille 13 августа 2012, 12:17:55 PM

Что касается ключевого вывода: только с помощью SHA256 (парольной фразы) выставят адреса в blockchain к относительно простой грубой силы атаки (связанной только с умножением ЕС, в SHA256 круглого и ripemd160 раунда).

Я не думаю так: это не означает, как brainwallet. Это не указывает, как создать Bitcoin секретный ключ шифруется, который должен быть создан с хорошей ГСЧ. Для кого-то, чтобы иметь возможность провести атаку, они должны быть в распоряжении зашифрованного секретного ключа, и будет только в состоянии атаковать то, что они обладают, а не blockchain в целом.

Цитата: TangibleCryptography 13 августа 2012, 12:29:32 PM

Одна вещь, которую я рекомендовал бы использовать что-то ANYTYHING кроме SHA-256 для KDF. AES-256 уже быстро шифровать IT никогда не предназначалось для ключевых derivitive обязанностей.

AES не предлагаются для ключевого вывода. Она предлагается для шифрования секрета Bitcoin с ключом, полученным из пароля. Я могу просто изменить предложение и пример использования PBKDF2 HMAC SHA512.

К сожалению AES-256 была опечатка. "SHA-256 уже быстрый алгоритм ...."

Цитата: gmaxwell от 13 августа 2012 года, 1:07:14 PM

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

Возможно, лучшим выбором является CRC-16 от былых дней. Как я понимаю, он обладает свойством, что единичные ошибки или всплески ошибок (например, опечатки) не могут, или крайне маловероятно, чтобы произвести столкновения.

Цитата: gmaxwell от 13 августа 2012 года, 1:07:14 PM

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

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

Цитата: Pieter Wuille 13 августа 2012, 12:17:55 PM

Цитата: jim618 13 августа 2012, 12:02:21 PM

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

Я действительно обращаясь к самому блочному шифру. С того, что я предложил использовать XOR для цепи первого блок на второй, я думаю, что я очень возможно, предложил эквивалент использования CBC с вектором инициализации всех 0-х.

Цитата: casascius от 13 августа 2012 года, 6:14:33 PM

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

"в значительной степени невозможно", Нет- хорошо, полностью соленая это все еще несчастно возможно, особенно с CRC дает вам ~ 2 ^ 16 ускорения и такой быстрый растрескиванию дружественный KDF. Но, да, это будет в значительной степени удалить пакет и Предвычисления ускорение. Хотя 32 бита случайная соль занимает больше места, чем адрес они вы бы отправки в любом случае. Использование адреса также дает абсолютную правильность уверенность, но не давая никакого ускорения вообще (его крепко на дорогой стороне KDF).

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

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

При использовании PBKDF2 с солью, как KDF, AES является излишеством. В этот момент, учитывая случайный открытый текст, XOR будет точно так же, безопасность. Но AES дешев в этом контексте, так могли бы также.

Цитата: gmaxwell от 13 августа 2012 года, 7:15:07 PM

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

Цитата: gmaxwell от 13 августа 2012 года, 7:15:07 PM

"в значительной степени невозможно", Нет- хорошо, полностью соленая это все еще несчастно возможно, особенно с CRC дает вам ~ 2 ^ 16 ускорения и такой быстрый растрескиванию дружественный KDF. Но, да, это будет в значительной степени удалить пакет и Предвычисления ускорение. Хотя 32 бита случайная соль занимает больше места, чем адрес они вы бы отправки в любом случае. Использование адреса также дает абсолютную правильность уверенность, но не давая никакого ускорения вообще (его крепко на дорогой стороне KDF).

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

Тем не менее, 32 бита адреса вполне может сделать то же самое без CRC ... есть еще 1-в-2 ^ 32 вероятность любой данный опечатка может проскочить, но я бы сказал, что это приемлемо в качестве супер -редкое неудобство. Если на бумажном счете, это означает, что я кодирующая больше 32 бит через два QR-кодов, чем я бы с одним QR код, для меня это приемлемая стоимость ресурсов, чтобы сохранить возможность сканировать адрес Bitcoin сам по себе.

Цитата: casascius от 13 августа 2012 года, 8:00:42 PM

Правша, но почему не требуют, чтобы как быть предусмотрено, чтобы расшифровать секретный ключ?

Адрес:
Passphrase:
PrivateKey:

котировка

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

Право, Addr + privkey меньше адр + privkey + соль.

котировка

Тем не менее, 32 бита адреса вполне может сделать то же самое без CRC ... есть еще 1-в-2 ^ 32 вероятность любой данный опечатка может проскочить, но я бы сказал, что это приемлемо в качестве супер -редкое неудобство. Если на бумажном счете, это означает, что я кодирующая больше 32 бит через два QR-кодов, чем я бы с одним QR код, для меня это приемлемая стоимость ресурсов, чтобы сохранить возможность сканировать адрес Bitcoin сам по себе.

32 бита адреса еще лучше, для обнаружения ошибок, чем 16 бит CRC при большинстве моделей ошибок.

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

Цитата: gmaxwell от 13 августа 2012 года, 8:53:13 PM

Потому что это увеличивает сложность и длину кода без необходимости. Если единственное преимущество является то, что один-в-4 миллиарда PassPhrase опечаток больше будет ошибочно принято, нет, я предпочел бы длину кода, 15 символов короче вместо. Если я делаю Bitcoin наличные деньги, я либо должен заставить пользователей сканировать два QR-кодов вместо одного, или избыточно добавить массу ко второму QR код для никакой практической пользы. Если у меня есть биты в обрез, я бы лучше потратить их на более исправлении ошибок кодовых слов для QR кода, чтобы он более устойчив к повреждениям.

котировка

Не могли бы вы рекомендовать ваши любимые KDF, где это примеры кода для большинства платформ разработки легко прийти? (Часть почему я первоначально выбранный SHA256 была максимизировать вероятность, что разработчики будут иметь возможность реализовать это предложение, так как если вы работаете с Bitcoin это уже есть.)

Вот что я думаю, что я буду делать с этим:

* Изменение формата, так это 57 символов, начиная с "6p", Который является 38-base58 закодированных байт.
* 14 бит требуется, чтобы держать "6p" Префикс нетронутыми. Остальные предложения 1 бит для "не сжимать / не-компресс" флаг, 4 байта для соли и 32 байт для ключа. Существует один дополнительный бит.
* 32 бита соли будет просто первый 32 бита SHA256 (ожидаемый Bitcoin адреса в ASCII), чтобы удвоить в качестве проверки опечатки.
* The KDF будет Scrypt со следующими параметрами: N = 1024, г = 8, р = 1, и выведенный ключ длиной 64 байта.
* Первые 32 байт, возвращаемые сценарий будет использоваться в качестве IV для AES-CBC, последние 32 байт ключа.

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

gmaxwell, не могли бы вы предоставляя свой опыт относительно выдвижения KDF, выбранных параметров, и methology? Кроме того, если предположить, что я на правильном пути, вы можете порекомендовать то, что "Другие" Выбор параметров может должно быть, когда дополнительный бит переворачивается? Вы пошли бы слабее или сильнее, и почему? Заранее спасибо.

Цитата: casascius от 16 августа 2012 года, 4:55:31 AM

* 32 бита соли будет просто первый 32 бита SHA256 (ожидаемый Bitcoin адреса в ASCII), чтобы удвоить в качестве проверки опечатки.
* The KDF будет Scrypt со следующими параметрами: N = 1024, г = 8, р = 1, и выведенный ключ длиной 64 байта.

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

Значения по умолчанию для Scrypt являются N = 2¹⁴, г = 8, р = 1. (Из первоначального представления в 2009 году). Я бы не идти ниже, если вы не уверены, что они должны быть доступны на устройствах с менее чем 16 МБ свободной оперативной памяти.

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

13 августа 2012, 12:11:04 AM	# 1
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru Недавно я предложил частный формат ключ для Bitcoin частных ключей, которые требуют пароля для того, чтобы использовать. Сегодня я с поправками мое предложение включить парольную фразу шифрования AES на основе, и обновил свой Casascius Bitcoin Адрес утилиты для работы в качестве доказательства-концепции. Это понятие доказательства правильности может печатать PassPhrase зашифрованного бумажных бумажников, а также расшифровать зашифрованные секретные ключи. Предложение: https://en.bitcoin.it/wiki/User:Casascius/Base58Check-encoded_objects_proposal Доказательство концепции с источником: https://casascius.com/bitaddress.zip Краткая информация о предложении: * Ключи начинаются с "6p", И посмотреть, как (например): 6poiKAg7ZAGGLGfTMcwaqHixuEU3txKjFsDpxfxrmBrY6bAPwLjcfp * AES256 используется. SHA256 (ключевая фраза) является ключевым. Чтобы сохранить ключ короткий, не используется вектор инициализации, хотя сцепление сохраняется. * Спецификация включает в себя битовый флаг для указания, должен ли быть сжат открытый ключ. * В спецификации включает в себя 14-битную контрольную сумму на ключевой фразе, так что большинство Passphrase опечатки может быть обнаружена и отклонена. Я хотел бы получить комментарии по этому предложению, так как я рассматриваю его продвижение в направлении BIP.

13 августа 2012, 11:20:00 AM	# 2
dogisland Сообщения: 262 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Получил 1806 Биткоинов Реальная история. Я реализовать шифрование AES как часть Strongcoin PDF бумаги бумажника. Если память основные вопросы были совместимость между OpenSSL и другими librairies, то есть у меня было несколько вопросов, возвращаясь и вперед совместимость между ними. Я думаю, что версия открытого SSL, который вы используете могут повлиять на тип шифрования вы получите. https://www.strongcoin.com/en/blog/decrypting_private_keys_generated_with_strongcoin Так может быть, стоит показать, как вы получили результаты для примеров, которые Вы дали (т.е. команд или инструментов, которые вы использовали) и попробовать несколько других инструментов, чтобы увидеть, если вы получите те же результаты. Это отличная идея, и мы бы стандартизировать бумажные бумажники, которые были бы велики.

13 августа 2012, 12:02:21 PM	# 3
jim618 Сообщения: 1708 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Привет Casascius, Вместо того чтобы использовать SHA256 (пароль), почему бы не использовать Scrypt в качестве KDF? Если взглянуть на предлагаемом / а Multibit альфа существует спецификация для bitcoinj зашифрована частных ключей вы можете увидеть, что Scrypt выбрана в качестве KDF из-за его устойчивость к реализации кремния: https://docs.google.com/document/d/1Z7kUZJePDS274mawMlMgQwN7C-W88f_ITL4l0F5SVDY/edit Я считаю, что Scrypt + AES также используется в Оружейной. Вы упоминаете, что IV не используется, но первый блок АЭС должен быть инициализирован с * что-то *. Я предлагаю вам явно указать 16 байт 0x00 придавить спецификации. Если вы используете Scrypt как KDF, указать точные параметры, которые будут использоваться таким образом, что не существует никакой двусмысленности (например, см по умолчанию в документе Google.)

13 августа 2012, 12:17:55 PM	# 4
Pieter Wuille Сообщения: 1050 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Цитата: jim618 13 августа 2012, 12:02:21 PM Вы упоминаете, что IV не используется, но первый блок АЭС должен быть инициализирован с * что-то *. Я предлагаю вам явно указать 16 байт 0x00 придавить спецификации. Я думаю, что вы говорите о AES в режиме CBC, который действительно нуждается в векторе инициализации. AES сам блок шифра не делает, и может быть, что casascius имел в виду. Что касается ключевого вывода: только с помощью SHA256 (парольной фразы) выставят адреса в blockchain к относительно простой грубой силы атаки (связанной только с умножением ЕС, в SHA256 круглого и ripemd160 раунда).

13 августа 2012, 12:29:32 PM	# 5
TangibleCryptography Сообщения: 476 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Одна вещь, которую я рекомендовал бы использовать что-то ANYTYHING кроме SHA-256 для KDF. ~~AES-256~~ SHA-256 уже быстрый алгоритм IT никогда не предназначался для ключевых производных обязанностей. Однако быстро, как это, скорее всего, это все равно будет "достаточно хорошо" ... для этого называется добычи, за исключением. Существует уже огромный финансовый стимул для более быстрого и лучшего шахтеры как в алгоритмах (OpenCL оптимизаций, FPGA битового поток оптимизации), так и в аппаратных средств и, таким образом, мы видели огромное количество оптимизации. Использование SHA-256 позволяет злоумышленнику использовать все, что "инвестиции" при очень низкой стоимости. Даже при использовании SHA-512 была бы предпочтительнее. Это подводит меня ко второму вопросу. Действительный секретный ключ является произвольным, что означает шифрование не лучший вариант. Зачем идти: Ключевая фраза -> KDF -> ключ ключ & зашифрованный закрытый ключ -> расшифрован секретный ключ почему бы просто не пойти Ключевая фраза -> KDF (PBKDF2, Scrypt, Bcrypt) -> Секретный ключ

13 августа 2012, 12:45:01 PM	# 6
jim618 Сообщения: 1708 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей котировка Это подводит меня ко второму вопросу. Действительный секретный ключ является произвольным, что означает шифрование не лучший вариант. Зачем идти: Ключевая фраза -> KDF -> ключ ключ & зашифрованный закрытый ключ -> расшифрован секретный ключ почему бы просто не пойти Ключевая фраза -> KDF (PBKDF2, Scrypt, Bcrypt) -> Секретный ключ Пользователь может иметь существующий закрытый ключ, который они хотят, чтобы зашифровать, а не создавать новый.

13 августа 2012, 12:53:44 PM	# 7
TangibleCryptography Сообщения: 476 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Правда, я не думал об этом. "атакующий оптимизировано" KDF является большим вопросом.

13 августа 2012, 1:07:14 PM	# 8
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Цитата: casascius 13 августа 2012, 12:11:04 AM Я хотел бы получить комментарии по этому предложению, так как я рассматриваю его продвижение в направлении BIP. Пожалуйста, не представить BIP для схемы шифрования, которая несоленое и использует слабый KDF на поставки пользовательских паролей. Особенно не сделать это с быстрым значением обнаружения ошибок. Гораздо менее важно, если есть значение обнаружения ошибок на всех, это действительно должно быть достаточно большим, что ошибки очень маловероятно, чтобы сделать это сквозным "все работает" а также "только правильные значения работы" являются разумными с точки зрения пользовательского интерфейса (хотя последний гораздо лучше). "Вряд ли, но достаточно вероятно, что люди будут по-прежнему ударил его" очень запутанный на практике. Использование полученного публичного адреса в качестве соли убивает двух зайцев одним выстрелом, так как она позволяет отслеживать, которая, которые до их расшифровки, поэтому, возможно, вам следует учесть, что?

13 августа 2012, 6:02:09 PM	# 9
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Цитата: Pieter Wuille 13 августа 2012, 12:17:55 PM Что касается ключевого вывода: только с помощью SHA256 (парольной фразы) выставят адреса в blockchain к относительно простой грубой силы атаки (связанной только с умножением ЕС, в SHA256 круглого и ripemd160 раунда). Я не думаю так: это не означает, как brainwallet. Это не указывает, как создать Bitcoin секретный ключ шифруется, который должен быть создан с хорошей ГСЧ. Для кого-то, чтобы иметь возможность провести атаку, они должны быть в распоряжении зашифрованного секретного ключа, и будет только в состоянии атаковать то, что они обладают, а не blockchain в целом.

13 августа 2012, 6:04:52 PM	# 10
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Цитата: TangibleCryptography 13 августа 2012, 12:29:32 PM Одна вещь, которую я рекомендовал бы использовать что-то ANYTYHING кроме SHA-256 для KDF. AES-256 уже быстро шифровать IT никогда не предназначалось для ключевых derivitive обязанностей. AES не предлагаются для ключевого вывода. Она предлагается для шифрования секрета Bitcoin с ключом, полученным из пароля. Я могу просто изменить предложение и пример использования PBKDF2 HMAC SHA512.

13 августа 2012, 6:05:49 PM	# 11
TangibleCryptography Сообщения: 476 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей К сожалению AES-256 была опечатка. "SHA-256 уже быстрый алгоритм ...."

13 августа 2012, 6:14:33 PM	# 12
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Цитата: gmaxwell от 13 августа 2012 года, 1:07:14 PM Гораздо менее важно, если есть значение обнаружения ошибок на всех, это действительно должно быть достаточно большим, что ошибки очень маловероятно, чтобы сделать это сквозным "все работает" а также "только правильные значения работы" являются разумными с точки зрения пользовательского интерфейса (хотя последний гораздо лучше). "Вряд ли, но достаточно вероятно, что люди будут по-прежнему ударил его" очень запутанный на практике. Возможно, лучшим выбором является CRC-16 от былых дней. Как я понимаю, он обладает свойством, что единичные ошибки или всплески ошибок (например, опечатки) не могут, или крайне маловероятно, чтобы произвести столкновения. Цитата: gmaxwell от 13 августа 2012 года, 1:07:14 PM Использование полученного публичного адреса в качестве соли убивает двух зайцев одним выстрелом, так как она позволяет отслеживать, которая, которые до их расшифровки, поэтому, возможно, вам следует учесть, что? В результате публичный адрес не известен до тех пор, полезная нагрузка не будет расшифрована и поэтому не может быть использована в качестве соли. Все, что используется в качестве соли просто должно быть добавлено к полезной нагрузке, удлиняя его. Возможный компромисс, который приходит на ум, чтобы добавить 32 случайных битов соли на сообщение, которое удлиняет сообщение незначительно, но все же делает растрескивание крупной партии похищенных частных ключей с тем же усилием в основном невозможно.

13 августа 2012, 7:05:36 PM	# 13
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Цитата: Pieter Wuille 13 августа 2012, 12:17:55 PM Цитата: jim618 13 августа 2012, 12:02:21 PM Вы упоминаете, что IV не используется, но первый блок АЭС должен быть инициализирован с * что-то *. Я предлагаю вам явно указать 16 байт 0x00 придавить спецификации. Я думаю, что вы говорите о AES в режиме CBC, который действительно нуждается в векторе инициализации. AES сам блок шифра не делает, и может быть, что casascius имел в виду. Я действительно обращаясь к самому блочному шифру. С того, что я предложил использовать XOR для цепи первого блок на второй, я думаю, что я очень возможно, предложил эквивалент использования CBC с вектором инициализации всех 0-х.

13 августа 2012, 7:15:07 PM	# 14
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Цитата: casascius от 13 августа 2012 года, 6:14:33 PM В результате публичный адрес не известен до тех пор, полезная нагрузка не будет расшифрована и поэтому не может быть использована в качестве соли. Все, что используется в качестве соли просто должно быть добавлено к полезной нагрузке, удлиняя его. Возможный компромисс, который приходит на ум, чтобы добавить 32 случайных битов соли на сообщение, которое удлиняет сообщение незначительно, но все же делает растрескивание крупной партии похищенных частных ключей с тем же усилием в основном невозможно. Да, я хорошо осведомлен о IT-, но практическое использование нужно будет включать в себя адрес слишком- или вы не сможете сказать, какой шифрованный ключ, который и который вы в настоящее время необходимо без их расшифровки. "в значительной степени невозможно", Нет- хорошо, полностью соленая это все еще несчастно возможно, особенно с CRC дает вам ~ 2 ^ 16 ускорения и такой быстрый растрескиванию дружественный KDF. Но, да, это будет в значительной степени удалить пакет и Предвычисления ускорение. Хотя 32 бита случайная соль занимает больше места, чем адрес они вы бы отправки в любом случае. Использование адреса также дает абсолютную правильность уверенность, но не давая никакого ускорения вообще (его крепко на дорогой стороне KDF).

13 августа 2012, 7:58:11 PM	# 15
kjj Сообщения: 1302 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Это выглядит хорошо для меня. Большинство возражений, которые я имел при чтении его были рассмотрены позже. KDF по-прежнему является проблемой, хотя. Лучшая практика будет просто использовать PBKDF2 и встроить соль для этого на выходе. 64 бита соли не смертельно удлинить зашифрованный ключ. При использовании PBKDF2 с солью, как KDF, AES является излишеством. В этот момент, учитывая случайный открытый текст, XOR будет точно так же, безопасность. Но AES дешев в этом контексте, так могли бы также.

13 августа 2012, 8:00:42 PM	# 16
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Цитата: gmaxwell от 13 августа 2012 года, 7:15:07 PM Да, я хорошо осведомлен о IT-, но практическое использование нужно будет включать в себя адрес слишком- или вы не сможете сказать, какой шифрованный ключ, который и который вы в настоящее время необходимо без их расшифровки. Практические обыкновения, я имею в виде очень хорошо могут включать в себя адрес, но не обязательно закодированы в закрытом ключе. Если я передаю вам счет бумаги Bitcoin защищена паролем (который я даю вам), законопроект, скорее всего, уже имеет адрес Bitcoin на левой стороне. Кодирование его в закрытом ключе будет излишним. Я не хотел бы требовать, чтобы они были закодированы вместе, потому что есть практические приложения к иметь их в отдельных QR кодов (например, финансирование или проверки баланса без разглашения секретного ключа в любой форме, в зашифрованной или иным образом). Цитата: gmaxwell от 13 августа 2012 года, 7:15:07 PM "в значительной степени невозможно", Нет- хорошо, полностью соленая это все еще несчастно возможно, особенно с CRC дает вам ~ 2 ^ 16 ускорения и такой быстрый растрескиванию дружественный KDF. Но, да, это будет в значительной степени удалить пакет и Предвычисления ускорение. Хотя 32 бита случайная соль занимает больше места, чем адрес они вы бы отправки в любом случае. Использование адреса также дает абсолютную правильность уверенность, но не давая никакого ускорения вообще (его крепко на дорогой стороне KDF). От "в значительной степени невозможно" Я имею в виду тот факт, что тот, кто сумел украсть большое количество закрытых ключей зашифрованного таким образом все равно придется взломать на ключи один за одним. Я не уверен в том, как 32-битное случайное соль занимает больше места, чем 160 разрядного адрес ... 32<160 конечно, поэтому я должен быть что-то недоразумение, но если то, что вы говорите, если нужно передать как адрес и соль, то сумма действительно больше, то я согласен. Тем не менее, 32 бита адреса вполне может сделать то же самое без CRC ... есть еще 1-в-2 ^ 32 вероятность любой данный опечатка может проскочить, но я бы сказал, что это приемлемо в качестве супер -редкое неудобство. Если на бумажном счете, это означает, что я кодирующая больше 32 бит через два QR-кодов, чем я бы с одним QR код, для меня это приемлемая стоимость ресурсов, чтобы сохранить возможность сканировать адрес Bitcoin сам по себе.

13 августа 2012, 8:53:13 PM	# 17
gmaxwell Сообщения: 2366 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Цитата: casascius от 13 августа 2012 года, 8:00:42 PM Практические обыкновения, я имею в виде очень хорошо могут включать в себя адрес, но не обязательно закодированы в закрытом ключе. Если я передаю вам счет бумаги Bitcoin защищена паролем (который я даю вам), законопроект, скорее всего, уже имеет адрес Bitcoin на левой стороне. Кодирование его в закрытом ключе будет излишним. Я не хотел бы требовать, чтобы они были закодированы вместе, потому что есть практические приложения к иметь их в отдельных QR кодов (например, финансирование или проверки баланса без разглашения секретного ключа в любой форме, в зашифрованной или иным образом). Правша, но почему не требуют, чтобы как быть предусмотрено, чтобы расшифровать секретный ключ? Адрес: Passphrase: PrivateKey: котировка хотя, если то, что вы говорите, если нужно передать как адрес и соль, то сумма действительно больше, то я согласен. Право, Addr + privkey меньше адр + privkey + соль. котировка Тем не менее, 32 бита адреса вполне может сделать то же самое без CRC ... есть еще 1-в-2 ^ 32 вероятность любой данный опечатка может проскочить, но я бы сказал, что это приемлемо в качестве супер -редкое неудобство. Если на бумажном счете, это означает, что я кодирующая больше 32 бит через два QR-кодов, чем я бы с одним QR код, для меня это приемлемая стоимость ресурсов, чтобы сохранить возможность сканировать адрес Bitcoin сам по себе. 32 бита адреса еще лучше, для обнаружения ошибок, чем 16 бит CRC при большинстве моделей ошибок. Я бы еще лучше использовать весь адрес, но это не так уж плохо звучащие .... Теперь, используя хороший KDF вместо этого?

13 августа 2012, 9:54:07 PM	# 18
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Цитата: gmaxwell от 13 августа 2012 года, 8:53:13 PM Правша, но почему не требуют, чтобы как быть предусмотрено, чтобы расшифровать секретный ключ? Адрес: Passphrase: PrivateKey: Потому что это увеличивает сложность и длину кода без необходимости. Если единственное преимущество является то, что один-в-4 миллиарда PassPhrase опечаток больше будет ошибочно принято, нет, я предпочел бы длину кода, 15 символов короче вместо. Если я делаю Bitcoin наличные деньги, я либо должен заставить пользователей сканировать два QR-кодов вместо одного, или избыточно добавить массу ко второму QR код для никакой практической пользы. Если у меня есть биты в обрез, я бы лучше потратить их на более исправлении ошибок кодовых слов для QR кода, чтобы он более устойчив к повреждениям. котировка 32 бита адреса еще лучше, для обнаружения ошибок, чем 16 бит CRC при большинстве моделей ошибок. Я бы еще лучше использовать весь адрес, но это не так уж плохо звучащие .... Теперь, используя хороший KDF вместо этого? Не могли бы вы рекомендовать ваши любимые KDF, где это примеры кода для большинства платформ разработки легко прийти? (Часть почему я первоначально выбранный SHA256 была максимизировать вероятность, что разработчики будут иметь возможность реализовать это предложение, так как если вы работаете с Bitcoin это уже есть.)

16 августа 2012, 4:55:31 AM	# 19
casascius Сообщения: 1372 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Вот что я думаю, что я буду делать с этим: * Изменение формата, так это 57 символов, начиная с "6p", Который является 38-base58 закодированных байт. * 14 бит требуется, чтобы держать "6p" Префикс нетронутыми. Остальные предложения 1 бит для "не сжимать / не-компресс" флаг, 4 байта для соли и 32 байт для ключа. Существует один дополнительный бит. * 32 бита соли будет просто первый 32 бита SHA256 (ожидаемый Bitcoin адреса в ASCII), чтобы удвоить в качестве проверки опечатки. * The KDF будет Scrypt со следующими параметрами: N = 1024, г = 8, р = 1, и выведенный ключ длиной 64 байта. * Первые 32 байт, возвращаемые сценарий будет использоваться в качестве IV для AES-CBC, последние 32 байт ключа. Выбор параметров Scrypt предназначены, чтобы сделать шифрование приблизительной стоимости центрального процессора по генерации адреса Bitcoin, по крайней мере, в пределах порядка величины или три. Один бит доступен для задания различных параметров Scrypt - в зависимости от того, точки этого не достаточно, я считаю, что это должно быть сделано с новым префиксом (например, 6P вместо 6ра), поэтому совместимостью и прочности виден пользователю. gmaxwell, не могли бы вы предоставляя свой опыт относительно выдвижения KDF, выбранных параметров, и methology? Кроме того, если предположить, что я на правильном пути, вы можете порекомендовать то, что "Другие" Выбор параметров может должно быть, когда дополнительный бит переворачивается? Вы пошли бы слабее или сильнее, и почему? Заранее спасибо.

16 августа 2012, 6:23:21 AM	# 20
kjj Сообщения: 1302 Цитировать по имени цитировать ответ	Re: Предложение (+ Доказательство концепции программного обеспечения): AES-Зашифрованные Bitcoin частных ключей Цитата: casascius от 16 августа 2012 года, 4:55:31 AM * 32 бита соли будет просто первый 32 бита SHA256 (ожидаемый Bitcoin адреса в ASCII), чтобы удвоить в качестве проверки опечатки. * The KDF будет Scrypt со следующими параметрами: N = 1024, г = 8, р = 1, и выведенный ключ длиной 64 байта. Выбор параметров Scrypt предназначены, чтобы сделать шифрование приблизительной стоимости центрального процессора по генерации адреса Bitcoin, по крайней мере, в пределах порядка величины или три. Один бит доступен для задания различных параметров Scrypt - в зависимости от того, точки этого не достаточно, я считаю, что это должно быть сделано с новым префиксом (например, 6P вместо 6ра), поэтому совместимостью и прочности виден пользователю. Значения по умолчанию для Scrypt являются N = 2¹⁴, г = 8, р = 1. (Из первоначального представления в 2009 году). Я бы не идти ниже, если вы не уверены, что они должны быть доступны на устройствах с менее чем 16 МБ свободной оперативной памяти. На мой взгляд, соль должна быть случайной и хранится в выходных данных. Если вы основываете соль на выходе, то вам нужен зашифрованный ключ и открытый ключ как восстановить секретный ключ. Это не является подавляющим требованием, но до сих пор кажется глупым.

Заголовок