24-04-2014 - Изменен расчет PREH и POSTH. Еще раз.
21-04-2014 - Изменен расчет PREH и POSTH.
15-02-2014 - Обновлены формулировки различных частей.
06-02-2014 - реализация добавляемой Ягер в качестве эталона.
05-02-2014 - Измененный префикс к 2 байта, «RK» и «гк» для чистой версии и зашифрованной версии соответственно.
05-02-2014 - Добавлено энтропия поля для зашифрованной версии, переехал поле KDF из префикса в поле энтропии.
05-02-2014 - Изменено вычисление H использовать PBKDF2-HMAC-SHA512 вместо Scrypt.
05-02-2014 - Измененное поле контрольной суммы расцветать поле в зашифрованной версии. Теперь поддерживает 2 пароли.
27-12-2013 - Добавлены некоторые пояснения, такие как набор символов пароля (UTF-8) и байтов полей.
26-12-2013 - Измененный контрольная сумма удвоится SHA256 закрытого ключа, добавил 3й поддержка партии KDF.
01-10-2013 - Expanded соли быть префикс даты + + контрольной сумму и переименован в «посевной» в «корневом ключ».
24-07-2013 - Добавлен по выбору пользователя KDF + параметры, закодированные в префиксе.
22-07-2013 - Добавлено 2 создания байт поля даты, в результате, префикс расширяется до 3 байта.
BIP:
Название: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Авторы: Жан-Поль Kogelman, Уильям Yager
Статус: Проект
Тип: Информационный
Создано: 18-07-2013
Абстрактные
Это предложение описывает способ кодирования и при необходимости шифрования Биткойн Иерархическая детерминированный (HD) корневой ключ бумажника. Закодированные ключи корневых предназначены для использования на бумажных кошельках. Каждая строка содержит всю информацию, необходимую для проверки и восстановить в HD кошелек для опциональных фраз кроме. Зашифрованные версия использует посола и выбираемый пользователем функция формирования ключа (KDF) + параметры, чтобы противостоять атакам грубой силы в той или иной степени и, возможно, второй пароль для правдоподобного отрицания.
Способ предусматривает две методики кодирования, в 3-х длинах каждый (16, 32 и 64 байт корневых ключей). Одним из них является четкой версией корневого ключа с информацией проверки для проверки целостности, а другие представляет собой зашифрованное представление.
Кроме того, в 2 байтовое поле сжимается дата присутствует, чтобы ограничить блок цепь повторное сканирование на импорт бумажника.
мотивация
Расширенные закрытые ключи, предложенные в BIP 0032 длинные, записи фиксированной длины и не предлагают какую-либо формы безопасности. Корневой ключ используется для генерации HD бумажник, как правило, короче, чем расширенной мастер закрытого ключа, который является результатом этого.
Компактное представление корневого ключа проще в обращении и версия 2-фактор ключа записи корня позволяет для безопасного хранения и создания бумажных кошельков по 3й стороны. KDF и его параметры по выбору пользователя, что позволяет разным уровнем сопротивления против грубой силы. Это предложение в настоящее время определяет 5 наборов параметров с комнатой на 27 больше, что может быть определено позднее. Implementors рекомендуется связаться с автором с новыми предложениями KDF.
Авторские права
Это предложение настоящим размещено в открытом доступе.
обоснование
История пользователя: Как пользователь Bitcoin, который использует HD бумажники, я хотел бы возможность хранить свой кошелек корневой ключ в компактной форме в виде бумажного бумажника.
История пользователя: Как пользователь Bitcoin, который использует HD бумажники, я хотел бы возможность иметь третий участник создать бумажный бумажник с моей корневой ключ в нем, не имея доступ к денежным средствам, хранящимся в кошельке.
История пользователя: Как пользователь Bitcoin, который использует HD бумажники, я хотел бы возможность выбирать силу корневого ключа в зависимости от моих требований к безопасности и, как я хочу, чтобы сохранить его.
История пользователя: Как пользователь Bitcoin, который использует HD бумажники, я хотел бы возможность импортировать корневой ключ в проверку упрощенной оплаты (SPV) клиент без необходимости перезакачает весь блок цепь, но оценщик ограниченного диапазона, чтобы найти связанную с ним транзакцию ,
История пользователя: Как пользователь Bitcoin, который использует HD бумажники, я хотел бы выбрать KDF и его параметры, которые используются хэш пароля, который защищает мой корневой ключ, чтобы соответствовать моим требованиям безопасности и доступной вычислительной мощности.
История пользователя: Как пользователь Bitcoin, который использует HD бумажники, я хотел бы перенесу вычисление KDF к 3й партия с большей вычислительной мощностью.
История пользователя: Как пользователь Bitcoin, который использует HD бумажники, я хотел бы иметь второй пароль, который может расшифровать второй корневой ключ.
Спецификация
Это предложение позволяет использовать следующие функции и определения:
Все ввода / вывода текст должен быть UTF-8, кодированные
AES256Encrypt, AES256Decrypt: АЭ блочный шифр, применяемый в режиме ECB.
SHA256, SHA512: хэш алгоритмы одного и того же имени.
HMAC-SHA512: Алгоритм HMAC код аутентификации сообщения, используя SHA512 в качестве хэш-функции
PBKDF2-HMAC-SHA512: Алгоритм PBKDF2 ключа вывод, описанный в PKCS # 5 v2.0 и RFC 2898, используя HMAC-SHA512 в качестве функции псевдослучайной
Scrypt: Ключ растяжку алгоритм того же имени
Base58Check: Кодирование Текстовые данные часто используются различными системами Биткойн связанных
"Корневой ключ": Значение 16/32/64 байт кодируется в бумажнике. Это значение используется для получения секретных ключей для адресов в бумажнике Bitcoin
"Мастер ключ": Первичный Bitcoin секретный ключ, который является производным от корневого ключа
"||" относится к конкатенации, а не логическая операция ИЛИ
"г", "N": Константы определены как часть secp256k1 эллиптической кривой. G является эллиптическими кривыми точками, и N является большим положительным целым числом.
Префикс
Представление Base58Check кошелька будет начинаться с "RK" (Root Key), если кошелек в незашифрованном виде, и будет начинаться с "гк" если кошелек в зашифрованном виде.
Предлагаемая спецификация
Незашифрованная бумажник:
Префиксы:
0x28C1: 16 байт корневой ключ, без шифрования. 24 байта Общая длина
0x4AC5: 32 байт корневой ключ, без шифрования. 40 байт общая длина
0xFBB3: 64 байт корневой ключ, без шифрования. 72 байта Общая длина
Эти постоянные байты, которые появляются в начале Base58Check закодированной записи, и их присутствие вызывает результирующую строку, чтобы иметь предсказуемый префикс.
"Дата" является 2-байтовое, обратным порядком байтов поле, содержащее количество недель с 1 жань 2013. Это используется для оптимизации blockchain сканирования на импорт бумажника.
"контрольная сумма" есть первые 4 байта SHA256 (SHA256 (master_secret)), где master_secret является "Master Secret Key (IL)" из спецификации BIP32. Другими словами, "контрольная сумма"= SHA256 (SHA256 (HMAC-SHA512 ("Bitcoin семян", Root_key) [0:32])) [0: 4].
"root_key" является корневой ключ 16/32/64 байт, используемый для HD бумажника
В целом, очевидно, бумажник выглядит следующим образом:
[Префикс, 2 байта] [дата, 2 байта] [контрольная сумма, 4 байта] [root_key, 16/32/64 байт]
Диапазон в кодировании Base58Check для ясного 16 байт корневого ключа (префикс РК):
Минимальное значение: RK52zvuD3xRhwto8JDTonxhru6awsFfNqKCTmT (на основе 0x28 0xC1 плюс двадцать два 0x00 ых)
Максимальное значение: RKCsfF9RpLnrxo1kp2o7mfWYeAV1NNYxWSMRym (на основе 0x28 0xC1 плюс двадцать два 0xFF в)
Диапазон при кодировании Base58Check для четких 32 байт корневого ключа (префикс РК):
Минимальное значение: RK15fXAj9BEMooghtx2gY5YrSh23LYKS8mZnaz8oYf1EDnqAwtAADGMVUDHG (на основе 0x4a 0xC5 плюс тридцать восемь 0x00 лет)
Максимальное значение: RK5MUEoFU24QARcsX5HR2ieCjem468hDeQm4J2aH5zsCVJXUCGn6nsVQEFhN (основано на 0x4a 0xC5 плюс тридцать-восемь 0xFF в)
Диапазон при кодировании Base58Check для ясного 64 байт корневого ключа (префикс РК):
Минимальное значение: RK1uXsCQAKqaa2s7YBDeaLS2KTqZcNjjQSgdSfDv4fqGkTw8KBfZ2ND4Cp7vHdzhjJ2C2Jtf4CwgScR nXvpzuQT2W4Vj2SgCyfBgpTzF (на основе 0xFB 0xB3 плюс семьдесят 0x00 годов)
Максимальное значение: RK3B9TMn55dey3an1oHpwB81FPZboakivYtqFvCaeknPzPK4iTvoFKzxVWKcD9YfJwjkyS36bqnSqji bUurcQ7J2EsQww5zPpJNzqjkw (на основе 0xFB 0xB3 плюс семьдесят 0xFF в)
Зашифрованные бумажник:
Префиксы:
0xF83F: 16 байт корневой ключ, зашифрованный. 26 байт общая длина
0x6731: 32 байт корневой ключ, зашифрованный. 43 байта Общая длина
0x4EB4: 64 байта корневой ключ, зашифрованный. 76 байта Общая длина
Эти постоянные байты, которые появляются в начале Base58Check закодированной записи, и их присутствие вызывает результирующую строку, чтобы иметь предсказуемый префикс.
"Дата" является 2-байтовое, обратным порядком байтов поле, содержащее количество недель с 1 жань 2013. Это используется для оптимизации blockchain сканирования на импорт бумажника. Максимальное значение 0xFFFF приводит к: 1 джан 3269
"энтропия" является 2/3/4 байт (соответствует ли ключ 16/32/64 байт) поле. Первые пять битов содержат тип KDF, а все остальные биты содержат случайные данные. Это используется в качестве соли, чтобы взлом пароля бумажника сложнее.
"bloom_filter" это 4 байта прямой порядок байтов поле, содержащее фильтр цветения, чтобы проверить, что пользователь ввел свой пароль правильно.
"encrypted_root_key" является 16/32/64 байт шифруется корневой ключ, используемый для HD бумажника
Таким образом, зашифрованный кошелек выглядит следующим образом:
[Префикс, 2 байта] [дата, 2 байта] [энтропия, 2/3/4 байт] [bloom_filter, 4 байта] [encrypted_root_key, 16/32/64 байт]
Диапазон при кодировании Base58Check для зашифрованных 16 байт корневого ключа (префикс РК):
Минимальное значение: rk2V4R2ys91WigNPL5nots6a97rfMnwTkPAb2XgNo (на основе 0xf8 0x3F плюс двадцать четыре 0x00 ых)
Максимальное значение: rk57mv9oertBLsHfncAvqnbetCBdNS1gFHQaFsD3p (на основе 0xf8 0x3F плюс двадцать четыре 0xFF в)
Диапазон при кодировании Base58Check для зашифрованных 32 байт корневого ключа (префикс РК):
Минимальное значение: rk1CYsqKjsbXa7uvncEaW4XSeVzcpq1U9yDMxd2cWwfkGf1FMjENaVThYpLRNwqo (на основе 0x67 0x31 плюс СОРОК один 0x00-х)
Максимальное значение: rk7Xw5b6fidaCk489LhaiMqHkZo7RYGTmzvJY9A5joxe8KXAn8BC66cmQPYYYvy8 (на основе 0x67 0x31 плюс сорок-один 0xFF в)
Диапазон при кодировании Base58Check для зашифрованных 64 байт корневого ключа (префикс РК):
Минимальное значение: rk48BmQWeQbATSXbP5U6XVsXRJTs4Ea1TVZBbHLPPsboCFyxDj2Jaz2JAJno97hq6dq2bANLuWydY8Q SZgKVGhPRZazXt1swPXwzVLw1QnVAz (на основе 0x4e 0xB4 плюс семьдесят четыре 0x00 ых)
Максимальное значение: rkCRtT9R9kuAapCaLQFif5uo8gUrjgKsvYmGGTpX2ZTjTfwe9M7A6KezTh7f4FDxfZFVbHypodMNnNd mWYb8mzTokHXVR1u7KicrLLFFu7GJW (на основе 0x4e 0xB4 плюс семьдесят-четыре 0xFF в)
Кодирование KDF + параметров:
Ряд функций KDF доступен, чтобы приспособить широкий диапазон возможных вариантов использования. В KDFs определяется следующим образом:
| Я БЫ | |
|
|
Как заработать Биткоины?
Без вложений. Не майнинг.
|
19 июля 2013, 3:25:46 PM
|
# 2 |
Сообщения: 116
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
|
|
|
|
|
20 июля 2013, 6:37:18 AM
|
# 3 |
|
Сообщения: 836
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Я думаю, что это несколько не хватает потребности.
Сериализация BIP32 дается и достаточно для холодного хранения, возможно, с добавлением предложений СИПА в IRC: ключ @ момент создание, где ключ BIP32 сериализация и создание в Unix время (я предлагаю в миллисекундах и 64 бит предполагается). Сериализация HD бумажников будет нужно больше, чем семена, но, например, также используется иерархия. |
|
|
|
|
20 июля 2013, 7:59:48 AM
|
# 4 |
|
Сообщения: 666
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
я надеюсь, что будет консенсус по кошелькам, как расширить иерархию.
что, как вы могли бы вычесть из иерархии blockchain. им некоторых случаях дополнительные метаданные иерархия по-прежнему необходимому. (Если вы генерировать миллионы узлов никогда не использовать их, например) |
|
|
|
|
20 июля 2013, 3:08:09 PM
|
# 5 |
Сообщения: 116
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Я думаю, что это несколько не хватает потребности. Сериализация BIP32 дается и является достаточным для холодного хранения Я не согласен с уважением. Текущее решение расширенной открытых и закрытых ключей необходимо хранить это: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6Ln F5kejMRNNU3TGtRBeJgk33yuGBxrMPHi по сравнению с моим предложением о хранении этого: wsHb15443fYPmneEXskd6wUZeP15fCiA69n Это для 128 битного засева. 256-битные семена (более чем достаточно энтропия) потребовали бы только это: wsFp1uM2gFhd2PuRzmNFReRud71hgmVwPoc7cGpxuvgETRsv8J1wHNANJ Пожалуйста, обратите внимание, что эти семена бумажника могут быть (и те, показанные выше) зашифрованными, в то время как частные расширенные ключи всегда в явном виде. возможно, с добавлением предложения СИПА в IRC: ключ @ момент создание, где ключ BIP32 сериализация и создание в Unix время (я предлагаю в миллисекундах и 64 бит предполагается). Сериализация HD бумажников будет нужно больше, чем семена, но, например, также используется иерархия. В сети хранения всей иерархии высокой четкости бумажника находится вне сферы действия этого предложения. Я не уверен, если представляющее дерево достаточной сложности в читабельной форме даже желательно, но это мое личное мнение. Я думаю, что иерархия является прекрасным местом для людей, чтобы новшества. Как вы сказали, секвенирование на время UNIX является прекрасным местом для начала, однако, у вас есть 256 уровней в вашем распоряжении, чтобы вы могли просто написать свой суб дерево в читаемом виде: ... / 2013/07/20/18 / 45/16 / ... будет работать тоже. |
|
|
|
|
21 июля 2013, 5:12:14 AM
|
# 6 |
|
Сообщения: 836
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Текущее решение расширенной открытых и закрытых ключей необходимо хранить это: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6Ln F5kejMRNNU3TGtRBeJgk33yuGBxrMPHi по сравнению с моим предложением о хранении этого: wsHb15443fYPmneEXskd6wUZeP15fCiA69n Да, он короче, но это само по себе не оправдывает, чтобы определить новый стандарт, так как сериализация BIP32 вписывается в код квадрата QR, что лишь 13% выше и шире, чем ваш код. В сети хранения всей иерархии высокой четкости бумажника находится вне сферы действия этого предложения. Это моя точка зрения. Будучи в состоянии воссоздать мастер-ключ бумажника из зашифрованного семени хорошо, но я думаю, что нужно больше, чтобы быть в состоянии эффективно воссоздать кошелек. 1. Импорт частного ключа в кошелек довольно дорого, не зная, ключевой момент времени создания (что бы ограничить отсканированные блоки после этого), следовательно, предложения с ключом @ созданием 2. Один только семя не достаточно, чтобы воссоздать бумажник, так как сканирование для всех возможных иерархий непозволительно дорого. |
|
|
|
|
21 июля 2013, 5:56:31 AM
|
# 7 |
|
Сообщения: 116
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Текущее решение расширенной открытых и закрытых ключей необходимо хранить это: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6Ln F5kejMRNNU3TGtRBeJgk33yuGBxrMPHi по сравнению с моим предложением о хранении этого: wsHb15443fYPmneEXskd6wUZeP15fCiA69n Да, он короче, но это само по себе не оправдывает, чтобы определить новый стандарт, Вы игнорируете дополнительное шифрование. так как сериализация BIP32 вписывается в коде квадрат QR, что лишь 13% выше и шире, чем ваш код. QR-код расширенного закрытого ключа составляет ~ 50% выше и шире и имеет ~ 75% больше, чем площадь поверхности главного семени. Мастер семян QR-код: Расширенный закрытый ключ QR-код: В сети хранения всей иерархии высокой четкости бумажника находится вне сферы действия этого предложения. Это моя точка зрения. Будучи в состоянии воссоздать мастер кошелек ключ от зашифрованного семени хорошо, И это все это. Способ эффективного хранения посевного с возможностью зашифровать его. Больше ничего. но я думаю, что нужно больше, чтобы быть в состоянии эффективно воссоздать кошелек. 1. Импорт частного ключа в кошелек довольно дорого, не зная, ключевой момент времени создания (что бы ограничить отсканированные блоки после этого), следовательно, предложения с ключом @ созданием Я сожалею, английский не мой первый язык, так что я, возможно, упустили из виду, что вы предлагали добавить поле времени. Виноват. Это выполнимо, хотя 64bit довольно мелкозернистая, учитывая, что блоки генерируются примерно каждые 10 минут, и операции не имеют меток времени, что-то вроде поля 32-битного бы просто отлично, может быть, можно пойти еще меньше. 2. Один только семя не достаточно, чтобы воссоздать бумажник, так как сканирование для всех возможных иерархий непозволительно дорого. Это правда. Тем не менее, это не то, что это предложение пытается решить. Кроме того, расширенный закрытый ключ не решает эту проблему либо. Edit: Если мы позволим overscanning немного, скажет неделю стоит блоков (не следует принимать слишком долго), то вы были бы в состоянии добраться до 3265 года, если вы сохранили 2 байта на сумму недель после блока генеза. Если вы позволили overscanning на месяц, вы получите в 7470 году с 2 байта метки времени. |
|
|
|
|
21 июля 2013, 6:31:58 AM
|
# 8 |
|
Сообщения: 836
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Вы либо перешли на более высокий уровень коррекции ошибок или ваш QR инструмент кодирования создает неоптимальный кодировку, так как я получаю это за ключ BIP32:
http://imgur.com/YsnmI5N 32 бита Unix марка станет проблемой http://en.wikipedia.org/wiki/Year_2038_problem, миллисекунды, безусловно, является излишним, но ИМХО 64bit в миллисекундах новый стандарт для Unix времени. Я знаю, что ваше предложение не пытается решить кошелек сериализацию, а жаль, так как эта проблема не решена. |
|
|
|
|
21 июля 2013, 6:46:45 AM
|
# 9 |
|
Сообщения: 116
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Вы либо перешли на более высокий уровень коррекции ошибок или ваш QR инструмент кодирования создает неоптимальный кодировку, так как я получаю это за ключ BIP32: http://imgur.com/YsnmI5N Я просто схватил первый онлайн QR-кодировщик, который пришел в гугле. 32 бита Unix марка станет проблемой http://en.wikipedia.org/wiki/Year_2038_problem, миллисекунды, безусловно, является излишним, но ИМХО 64bit в миллисекундах новый стандарт для Unix времени. Вы читали мой выбор? Я думаю, что это, вероятно, достаточно для хранения недель (или месяцев) с момента генезиса, а не полной временной метки. Я знаю, что ваше предложение не пытается решить кошелек сериализацию, а жаль, так как эта проблема не решена. Это просто слишком много данных, я думаю, что это проблема, лучше оставить конкретные реализации бумажника. |
|
|
|
|
21 июля 2013, 6:59:32 AM
|
# 10 |
|
Сообщения: 836
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Вы либо перешли на более высокий уровень коррекции ошибок или ваш QR инструмент кодирования создает неоптимальный кодировку, так как я получаю это за ключ BIP32: http://imgur.com/YsnmI5N Я просто схватил первый онлайн QR-кодировщик, который пришел в гугле. 32 бита Unix марка станет проблемой http://en.wikipedia.org/wiki/Year_2038_problem, миллисекунды, безусловно, является излишним, но ИМХО 64bit в миллисекундах новый стандарт для Unix времени. Вы читали мой выбор? Я думаю, что это, вероятно, достаточно для хранения недель (или месяцев) с момента генезиса, а не полной временной метки. Я знаю, что ваше предложение не пытается решить кошелек сериализацию, а жаль, так как эта проблема не решена. Это просто слишком много данных, я думаю, что это проблема, лучше оставить конкретные реализации бумажника. Стандарты лучше построены на других стандартах, поэтому я бы не стал изобретать новый формат времени. Количество деревьев, вы экономите с теми байтами ничтожна. Я уверен, что иерархия используется, может быть закодирована очень эффективно, так как вам нужно хранить только индексное дерево используется. Тем не менее, ваше предложение является посредником шаг между ключом и кошелек сериализации, и это моя оригинальная точка. Нам не нужен новый ключ сериализации, но нам нужен бумажник сериализации. |
|
|
|
|
21 июля 2013, 7:20:48 AM
|
# 11 |
|
Сообщения: 116
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Нам не нужен новый ключ сериализации, Мы? Я уверен, что иерархия используется, может быть закодирована очень эффективно, так как вам нужно хранить только индексное дерево используется. Я открыт для предложений. |
|
|
|
|
21 июля 2013, 8:54:16 AM
|
# 12 |
|
Сообщения: 836
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Нам не нужен новый ключ сериализации, Мы? Я уверен, что иерархия используется, может быть закодирована очень эффективно, так как вам нужно хранить только индексное дерево используется. Я открыт для предложений. Это становится немым. Вы обратились за комментариями, но не может справиться с ними. Я должен был сказать, я и не должен был дразнили "Мы" как если бы это было бы квалифицировать содержание моего комментария. |
|
|
|
|
21 июля 2013, 9:08:24 AM
|
# 13 |
|
Сообщения: 116
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Нам не нужен новый ключ сериализации, Мы? Я уверен, что иерархия используется, может быть закодирована очень эффективно, так как вам нужно хранить только индексное дерево используется. Я открыт для предложений. Это становится немым. Вы обратились за комментариями, но не может справиться с ними. Я должен был сказать, я и не должен был дразнили "Мы" как если бы это было бы квалифицировать содержание моего комментария. Я могу справиться комментарии просто отлично. У нас были хорошие дискуссии о временных метках, например. Я просто считаю, это немного странно, что вы так пренебрежительно об этом предложении до точки использования «мы», как будто вы говорите для всего сообщества. Но хорошо, давайте игнорировать это. Это информативное BIP, так что вы можете игнорировать его. Это очевидно из нескольких ваших комментариев, что вы ищете решение, которое может сериализовать весь иерархический кошелек, но я ясно дал понять, что это предложение не распространяется на что. Но, как было сказано ранее, я открыт для предложений о том, как можно было бы эффективно сериализации иерархическую структуру бумажника, даже если это немного не по теме. |
|
|
|
|
21 июля 2013, 10:57:17 AM
|
# 14 |
|
Сообщения: 836
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Но, как было сказано ранее, я открыт для предложений о том, как можно было бы эффективно сериализации иерархическую структуру бумажника, даже если это немного не по теме. Каждый ключ идентифицируется посредством переменной длины последовательности целых чисел. Эти последовательности могут быть эффективно сжаты, так как они образуют дерево (повторяющиеся префиксы). Я заинтересован в этой теме, но не имеют времени, чтобы поработать над этим сейчас. |
|
|
|
|
22 июля 2013, 9:31:56 PM
|
# 15 |
|
Сообщения: 116
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Добавлено дата создания поля для предложения.
|
|
|
|
|
23 июля 2013, 12:09:24 AM
|
# 16 |
|
Сообщений: 19
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Я думаю, что стандартный формат для зашифрованной резервной копии ключевого материала (не иерархия) полезен.
Сердце любого пароля на основе шифрования является KDF - в этом случае, если вы выбрали Scrypt с п = 2 ^ 14, г = 8, р = 8. Просто быстрый тест на моем рабочем столе показывает, что это работает около 25 Iters / сек, с использованием примерно 12 МБ оперативной памяти для каждого потока, который может быть "достаточно медленно", Но трудно сказать окончательно. По сравнению с N = 16, г = 16, p = 16, который работает на частоте около 2 ITER / сек, используя 100 МБ ОЗУ для каждого потока ... или даже п = 18, г = 16, р = 16, который работает на частоте 0,5 / сек, используя 500 Мб оперативной памяти для каждого потока. Поскольку мы говорим о создании резервной копии 128 бит, я думаю, что это разумно предположить, конечный пользователь может либо просто запомнить 128-битные мнемоники (например BIP39), и тогда они не нужен пароль (или резервная копия) на все, или же они будут использовать пароль с наиболее вероятно, значительно меньше, чем 128-бит энтропии. Компромисс использования более строгих параметров «» Scrypt это некоторые устройства не могут быть пригодны для работы даже одной итерации. Проблема заключается в том, если вы нацелить ваши настройки, чтобы сделать эти устройства можно использовать, вы выбрасывая много пользы «Scrypt» - сделать грубую силу атаки дорого в широком спектре устройств, включая GPU и ASIC. Несколько возможных вариантов: 1) Ничего не делать - Держите 14/8/8 как стандартные жестко закодированных настройки для KDF, как это "достаточно медленно" 2) Увеличение трудности - Тогда мы должны решить, что "правильно" настройки, в том числе то, что максимальное требование RAM должно быть 3) обеспечить некоторые средства, используя различные трудности, так как нет ни одного один размер подходит для всех В конце концов # 3 сведутся к какому-то образом, кодирующей KDF / трудность - Есть несколько способов сделать это ... 3a) Добавить один или два байт KDF перечисление - 00 может означать "Scrypt / 14-8-8", 01 = "Scrypt / 16-16-16", 02 = "Scrypt / 18-16-16"И т.д. Это имеет то преимущество, что позволяет нам сохранить формат и использовать другие, чем Scrypt KDFs при желании. Возможно, включает в себя значение по умолчанию "Scrypt / 14-8-8" если эти байты не присутствовали. 3b) Жесткий код предположение о том, что KDF является Scrypt, и дают 2 или 3 байт кодирование параметров Scrypt, которые были использованы. Возможно включать значение по умолчанию 14-8-8, если эти байты не присутствовали. |
|
|
|
|
23 июля 2013, 12:35:22 AM
|
# 17 |
|
Сообщения: 116
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Как насчет: 3в) Базовые настройки на длину семян? Есть в настоящее время 3 семян длина: 128bit, 256bit и 512bit. 128bit семян: 14,8,8 256bit семян: 16,16,16 512bit семян: 18,16,16 Кроме того, я мог бы добавить больше длины семян в предложении, как и 192bit 384bit. |
|
|
|
|
23 июля 2013, 4:56:08 AM
|
# 18 |
|
Сообщений: 19
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Интересная идея, но я не знаю, почему сила KDF должна быть связана с длиной семян?
128-битные семена подходят с учетом общей конструкции BIP32; вы можете сделать его больше, но это на самом деле не купить вам что-нибудь. Если 128-бит не хватает, гораздо более важные вещи, вероятно, сломана. Сильнее KDF, с другой стороны, это все о сдерживании атаки грубой силы. Это может быть вполне разумным для того, чтобы занять 60 секунд или дольше, чтобы запустить KDF, когда я восстановить мой HD бумажник из холодного хранения. В конечном счете фактор трудностью для KDF будет меняться с течением времени, чтобы реагировать на достижения в области аппаратного и программного обеспечения, так что это определенно "запланированное устаревание" выбрать фиксированную трудность. Другими словами, все предложение становится все менее и менее безопасным с течением времени (проще грубой силы), если пользователи или исполнители не могут масштабироваться до трудности. Это менее ясно, насколько хорошо «Scrypt» сама по себе будет масштабироваться с течением времени, но, по крайней мере, "должен" иметь возможность масштабирования вверх, запрещая любую фундаментальную слабость обнаруживаются в его конструкции. Так обнажая некоторую степень контроля параметров Scrypt должно означать предложение по-прежнему может защитить от грубой силы нападения, а также 5 лет с этого момента, как это делает сегодня. Для чего это стоит, я прочитал, что LTC использует Scrypt с 10-1-1 и сейчас сеть делает 24GH / с. Моя последняя мысль скорость KDF также изменяется в зависимости от использования. Если я шифрование / дешифрование семян каждый раз, когда я разблокировать свой смартфон и открыть мой бумажник приложение, очевидно, что это будет необходимо работать намного быстрее, чем если бы я резервное копирование мой "сбережения холодный бумажник" от настольного приложения, которое я только планирую делать вклады в течение ближайших 10 лет. Таким образом, различные приложения могут выставить совершенно разные тайминги до конечного потребителя (я не говорю, что конечный пользователь будет / должен знать достаточно, чтобы выбрать сами тайминги). Кто-нибудь знает, как быстро 14-8-8 даже работает на более старый Android или на Raspberry Pi? Для всех я знаю, хотя я хотел бы что-то медленнее, чем 14-8-8 на моем рабочем столе, то же самое может быть полностью непригодным для мобильных устройств. |
|
|
|
|
23 июля 2013, 6:10:03 AM
|
# 19 |
|
Сообщения: 1400
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
У меня возникли проблемы, видя какое-либо значение вообще шифрования кошелька.
Учитывая количество вычислительной мощности доступных для злоумышленников (ботнетов, горнодобывающие GPU ферм и т.д.), вам нужно использовать параметры Scrypt так обременительны (несколько дней на обычном компьютере), что будет значительный шанс из одной битовой ошибки возникающие при расчетах. |
|
|
|
|
23 июля 2013, 7:18:40 AM
|
# 20 |
|
Сообщения: 116
цитировать ответ |
Re: Предложение: Base58 закодированные HD Wallet корневой ключ с возможностью шифрования
Интересная идея, но я не знаю, почему сила KDF должна быть связана с длиной семян? Идея заключалась в том, если вы выбираете низкую энтропию семени, то вы не слишком беспокоиться о безопасности. Конечно, вы не хотите, чтобы ваш кошелек взломан, но есть ценность в маленьком семени и легкие Scrypt параметры. Если вы собираетесь на 512 битное семени, то вы, вероятно, не слишком обеспокоены его принимать немного, когда вы импортируете семя. Таким образом, в основном 1: 1 соотношение между длиной семян и Scrypt трудом. Он также спасает меня от того, чтобы добавить еще одно поле для хранения параметров шифрования. Просто чтобы быть ясно, я не исключаю, добавив дополнительные байты, это просто, что мне нужно немного более убедительно. 128-битные семена подходят с учетом общей конструкции BIP32; вы можете сделать его больше, но это на самом деле не купить вам что-нибудь. Если 128-бит не хватает, гораздо более важные вещи, вероятно, сломана. Как уже упоминалось в BIP32, увеличение энтропии имеет влияние на него: котировка Генерировать семена S от выбранной длины (по крайней мере 128 бит, но 256 рекомендуется) Из (P) RNG. Сильнее KDF, с другой стороны, это все о сдерживании атаки грубой силы. Это может быть вполне разумным для того, чтобы занять 60 секунд или дольше, чтобы запустить KDF, когда я восстановить мой HD бумажник из холодного хранения. Настройки в настоящее время в предложении происходят из BIP38. Вот дискуссионная тема. Я рекомендую прочитать его, так как пришли туда одни и те же вопросы: Дело в том, чтобы забрать из него: котировка Как он это прямо сейчас, это займет около секунды, чтобы расшифровать на моей машине, если вы знаете пароль. Это сделало бы его так, чтобы это могло работать на телефоне в JavaScript на эту трудность, если пароль известен. То же машина бы полгода, чтобы взломать 5 символов одного случая. Убедитесь, что верхний ниже и вы 12 лет. Очевидно, что у него было двадцать машин и не использует неразделанный скомпилированный код. Для WAHT он предлагает текущая длина хэширования достаточно. Если я все вычисления этого права сделать это буквенно-цифровой верхний нижний и та же вещь занимает 29 лет на моем одном компьютере. Так что это при условии, верхний, нижний, буквенно-цифровые, 5 символов. Помните, что вы не обязательно должны увеличить параметры Scrypt, чтобы получить более высокий уровень безопасности. Длина вашей ключевой фразы, имеет тот же эффект. В конечном счете фактор трудностью для KDF будет меняться с течением времени, чтобы реагировать на достижения в области аппаратного и программного обеспечения, так что это определенно "запланированное устаревание" выбрать фиксированную трудность. Другими словами, все предложение становится все менее и менее безопасным с течением времени (проще грубой силы), если пользователи или исполнители не могут масштабироваться до трудности. Это менее ясно, насколько хорошо «Scrypt» сама по себе будет масштабироваться с течением времени, но, по крайней мере, "должен" иметь возможность масштабирования вверх, запрещая любую фундаментальную слабость обнаруживаются в его конструкции. Так обнажая некоторую степень контроля параметров Scrypt должно означать предложение по-прежнему может защитить от грубой силы нападения, а также 5 лет с этого момента, как это делает сегодня. Конечно, это становится легче грубой силой, но из числа приведенных выше, вы по-прежнему необходимо значительное количество времени, чтобы грубой силы ключевой фразы 5 символов. В конце концов, все сводится к двум вещам. 1: Когда это достаточно безопасно для вас? 2: Как это влияет на использование по умолчанию случая (ключ импорта пользователя, вводит пароль, должно ждать). Сейчас это около 1 вторых, может быть меньше на вашей машине, но для меня это 1 сек. Моя последняя мысль скорость KDF также изменяется в зависимости от использования. Если я шифрование / дешифрование семян каждый раз, когда я разблокировать свой смартфон и открыть мой бумажник приложение, очевидно, что это будет необходимо работать намного быстрее, чем если бы я резервное копирование мой "сбережения холодный бумажник" от настольного приложения, которое я только планирую делать вклады в течение ближайших 10 лет. Таким образом, различные приложения могут выставить совершенно разные тайминги до конечного потребителя (я не говорю, что конечный пользователь будет / должен знать достаточно, чтобы выбрать сами тайминги). Кошелек на телефоне не должен хранить семена в таком же формате, как это было предложено здесь. Он мог бы использовать совершенно другую схему шифрования для внутреннего хранения. Во всяком случае, это интересный аргумент, и я буду смотреть на завтра, чтобы увидеть, что добавив дополнительные настройки байт будут делать, но я хотел бы услышать некоторые другие люди весят по этому вопросу. |
|
|
|
Как заработать Биткоины?
Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包
bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru
3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW
Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包
bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru
3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW
Регистрация для новых участников, на данный момент не доступна. Просим извинения за временные неудобства.