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

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

Теперь для шифрования бумажника. Я хотел бы спросить у пользователя пароль и обеспечить некоторую базовую минимальную энтропию и пароль силы. Затем взять пароль и применить криптографический хэш с солью (т.е. SHA256) с получением производного пароля, скажем, 24 байт в длину. Это ключ, который будет использоваться для шифрования бумажника с AES-256. Зашифрованный кошелек передается на сервер с помощью SSL (который использует публичные крипто ключ). Сервер может зашифровать еще раз для хранения на диске (в случае, если кто-то получает доступ к файлам на сервере).

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

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

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

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

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

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