РегистрацияBitcoin protected paper backup
Дано: приватный ключ от адреса bitcoin, base58.
Надо: зашифрованную "бумажную" резервную копию (то есть хранить ключ в читаемом, но не в открытом виде).
Как лучше сделать?
На ум приходит:
1) key xor base58(password) – стойко ли? Еще где-то реализацию base58 найти надо.
2) hex от aes(key, sha2(password)) – сложнее, тоже нужно искать приемлемый софт.
комментариев: 9796 документов: 488 редакций: 5664
Основная идея, как я понял, такая — заводится отдельный кошелёк, куда переводится некая (обычно круглая в BTC) сумма. Он и распечатывается в виде QR-кода.
При желании считывается обратно. Есть и мысленные кошельки — пара «закрытый-открытый» ключ выводится из пароля (главное не забыть его вовремя завещать потомкам).
Проблема со всем этим — штатно в стандартном клиенте такие операции не предусмотрены и надо в нём вызывать консоль, где проделывать массу неочевидных команд, в ходе которых есть шанс расстаться с деньгами по ошибке. Или нужно установить неофициальный навороченный
глючный и тормознойклиент типа Armory.Armory делает свой собственный, т.н. root ключ, который выступает как некое зерно для генератора адресов, уникального для его (armory) кошелька – один такой ключ дает доступ ко всем адресам, сгенерированным и тем, которые будут сгенерированы в будущем. Он тоже в открытом виде.
Нативный клиент, действительно, через консоль нормально экспортирует ключи, так что зачем armory вообще нужен и чем он так уж защищенней, я не понял.
Вопрос не про биткоин вовсе, а про то, как технически проще зашифровать уже данный ключ парольной фразой и поместить на неэлектронный носитель (вдруг опыт у кого был). Так, что бы это потом можно было вручную перебить и расшифровать обратно. В том то и дело, что начиная искать "aes text encryption implementation", находятся либо какие-то школоподелки, либо проприетарщина, либо онлайн сервисы, которые оффлайн запустить не получится, либо реализации aes, в которых, хоть убейся, не получается воссоздать test vectors, а я не хочу шифровать непонятно чем. Так что простая, казалось бы, задача, растягивается во времени. =)
Сейчас я остановился на aes(key, sha2(password)) и стремительном дописывании маленького консольного интерфейса к openssh, дабы в состоянии это осилить. То есть шифруем key как он есть (в виде строки текста) хэшем парольной фразы, байты в виде 11 EE 22 печатаем на бумажку.
комментариев: 9796 документов: 488 редакций: 5664
Выбирайте, что удобнее:
Если xxd -p, то
Обратно в бинарник через xxd -r. Т.е. распечатываете для наглядности как в примере выше, а набираете в формате xxd -p, убрав все пробелы и выровняв в строку. После того, как сделаете xxd -r, то визуально будет легко сравнить, где ошиблись и поправить перед расшифровкой.
Наконец, codegroup — там вроде даже встроенная коррекция ошибок есть:
Всё-таки лучше gpg -c --cipher-algo AES → gpg -c --cipher-algo rijndael256, а то вдруг он AES-128 берёт, который в КК превратится в AES-64 и, вполне вероятно, может быть сломан перебором.
комментариев: 1060 документов: 16 редакций: 32
Надо gpg -c --cipher-algo aes256, rijndael256 там вроде нет и никогда не было.
Не вдруг, а точно :)
Дайте угадаю: вы активный пользователь хабра или ЛОРа. Кулхацкеры не знают матчасти, но любят кодить. Вместо того, чтобы воспользоваться стандартным инструментом, можно поступить более TRUEшно: написать свою поделку-велосипед. Кстати, прежде чем рожать потуги типа aes(key, sha2(password)), почему бы не узнать хотя бы про KDF, PBKDF2 и scrypt?
Перед тем, как написать, я проверяю то, что пишу:
комментариев: 1060 документов: 16 редакций: 32
Ага, как раз когда исправлял, появился новый коммент :)
А не, rijndael256 таки есть.
Судя по pgpru-поиску, это древние рекомендации, которые ссылаются на ещё более античные.
Если вы прочитаете более внимательно, то заметите, что его вопрос был о том, какой стандартный инструмент лучше выбрать, а не как что-то накодить. Вполне логично задать его здесь, дабы те, кто знает матчасть, сообщили наилучшее решение.
комментариев: 9796 документов: 488 редакций: 5664
Название топика почитайте.
Ничего не имею против, но человек всё же проговорился:
поэтому имело смысл указать на то, что он не только технически, но и концептуально далёк от того, что нужно. Ну, и всё же сначала находят ответы на вопросы, а только потом начинают кодить. Тут же человек всё решил, уже клепает на коленке решение, а потом бац — и засомневался, пошёл спрашивать. Хорошо, что хоть на этой стадии пошёл.
Имеется в виду, что «приватный ключ от адреса bitcoin» протоколом защищён посредством AES-128, поэтому не имеет смысла усиливать шифр?