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

А именно, для ситуации бумажного бумажника или физического объекта (монеты и т.д.) создается кем-то еще, почему бы не использовать HMAC_SHA256 функцию? Это будет выглядеть примерно так:

Клиент выбирает пароль п и соль S. Использование HMAC_SHA256, с п в качестве ключа, подписывая сообщение S, выходной хэш К из 256-битной длины, то становится закрытым ключом для Bitcoin адреса. Клиент получает публичный адрес К, и посылает S а также К на принтер для печати на физическом бумажник. Когда клиент получает (удивительно великолепный!) Бумажник, они могут добавить п к нему, прежде чем хранить его безопасно, гарантируя всем, кто находился в распоряжении его можно было легко получить К из п а также S, или оставить п секрет, что делает его "brainwallet" что только клиент может открыть.

Резюме Переменные:

• п Частный пароль выбрал клиент
  
• S Частная соль, совместно с бумажником создателя
  
• К Адрес закрытого ключа, полученный из п а также S
  
• К Общественный адрес К
  

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

Таким образом, чтобы предотвратить людей от выбора "щенки" в качестве пароля п, как насчет использования BIP39 для этого? Сделать как п а также S случайные 128-битовое число, которое обычно выражается в виде мнемонических 12 слов. 128 бит равен 16 байт, что 32 символов выражено в Hex, которая вписывается в 3-Q QR кода (Version 3; 29x29 клеток, исправление ошибок Q уровня; 25% восстановления после ошибок). Кошелек может иметь QR-код S и / или его мнемонические или base58 кодировке, оба необязательно покрыты голограммы с помощью принтера. Затем клиент может распечатать Мнемо п на нем, как указано выше. 128-бит такой же силы, как коды цепи BIP32 и электра, которые должны быть достаточно сильны сами по себе, чтобы противостоять атаке перебором.

С другой стороны, сделать битовую длину п а также S меньше, и использовать Scrypt на HMAC_SHA256, чтобы обеспечить грубой заставляя по-прежнему трудно. Если п а также S были 64-бит, который был бы шесть слов Мнемоника, 16 шестнадцатеричных символов (помещается в 1-Q QR кода; 21х21 клеток), или 11 символов base58. Будет ли Scrypt параметры что-то вроде г = 8, р = 1, N = 1024 будет хорошей отправной точкой?

Таким образом, из списка требований, полагая S действительно "minikey" в этой схеме:

• 30-значный код, который начинается с Р (так, 29 случайных символов): Нет, это было бы идентифицировать как ключ из двух частей, обе половины представленных как BIP39 (или аналогичный) мнемонические.
• Способность человека создавать minikeys, не зная пароля: В отличие от существующей схемы minikey, это один не требует "добыча" для одного, но создатель только наполовину ключ требуется, чтобы получить К
• Использует Scrypt для хэширования пароля и получения закрытого ключа: Да.
• Перестраиваемые параметры Scrypt: Да. Расчет Scrypt будет сделан клиентом, прежде чем обратиться кошелек будет создан / печатным, так может быть, что они хотят.
• Способность дорогостоящей операции Scrypt быть переданы: Нет.
• Обнаружение опечатки на пароле, который требует, чтобы все дорогостоящего вычисления было сделано, чтобы знать, проходит ли проверка или не: Да опечатка обнаружения (BIP39 имеет функцию контрольной суммы), не дорого.
• Около 169 бит, 156 из этого случайного: Два 64-битных половинных ключей будет только 128 бит энтропии, но это может быть скорректирована выше.
  

Таким образом, не идеальный матч с вашими требованиями, но очень просто. Один другой недостаток этого метода заключается в том, что если клиент хочет десятки кошельков, созданных им необходимо заранее рассчитать все их заранее (в отличие, скажем, BIP38 используя умножение ЕС и последовательность нескольких адресов). Насколько оценивая ваши требования, я не ценю "аутсорсинг поколение Scrypt" как очень. Я действительно думаю, что эта простая схема может быть улучшена путем добавления в метаданных, чтобы указать параметры, используемые Scrypt (как часть п) И флаг в качестве части S чтобы указать, что это половина ключ (начиная с некоторым флагом, как «P» вы предложили, что делает S лучше всего выражается в base58, а не мнемоника), нуждающихся в некоторых п для завершения (и некоторые хэш / контрольная сумма п чтобы соединить их обратно, если они разделены). Имея 156-бит энтропии Я думаю, что все в порядке; Я думаю, что это должно быть где-то в пределах 128-160 бит (если 128-бит нормально для кода Электрум / BIP32 цепи, я бы установить, что в качестве нижнего предела).

Любые вопиющие дыры с этим довольно простым вариантом?