Я на самом деле есть предложение в работах для делать именно это. Он избегает расширяющийся закрытого ключа слишком большого запаса (в настоящее время добавляет около 4-5 символов).

Я выпустил проект Casascius Bitcoin Адрес утилиту, которая работает (в том смысле, что она будет шифровать и дешифровать ключи), но спецификации будут пересмотрены, чтобы ключевая фраза более устойчива к грубому форсированию, прежде чем спецификация когда-либо становится какой-либо официальная частью Bitcoin. Если / когда это произойдет, все ключи, созданные с помощью утилиты теперь не будут работать. Текущая версия генерирует закрытые ключи, которые начинаются с "6p" и только несколько символов больше, чем "5J" один выше.

Сам алгоритм AES не добавляет накладные расходы, что-то выходит из того же размера. Но использование AES надежно требует некоторой случайной "инициализация" байты, чтобы помочь шифру начать в зашифрованном состоянии - это добавляет фиксированные 16 или 32 байт накладных расходов для любого использования этого. И Base64encoding двоичных данных влечет за собой автоматическую нагрузку 25% все само по себе, зашифрованную или нет.

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

Когда все сказано и сделано, окончательный алгоритм, вероятно, производить AES шифрованием Base58, как частные ключи, 57 символов в длину, а также начать с "6p",