Какой должна быть рациональная глубина подключа, чтобы мой адрес нельзя было найти с помощью систематического поиска?

Использование пикоина.

ku <ext_pri_key> -s 1/4/6/2/8/4/2/5.......

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

Двадцать уровней в глубину, как мне показалось, будет достаточно:

10**20 = 100000000000000000000

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

Спасибо.

Ответы (2)

Немного странно использовать одиночные цифры для всего пути HD, поскольку спецификация BIP32 позволяет вам выбирать числа до 2 ^ 31 (незащищенные). Для получения ключа BIP32 в основном используется SHA512. Текущие ASICS для SHA256 могут вычислять около 10 триллионов SHA256 в секунду, то есть около 160 квинтиллионов хеш-операций примерно за 6 месяцев. Предполагая, что ASIC может быть построен примерно с такой же мощностью хэширования, вам потребуется пройти около 20 уровней, чтобы заставить такую ​​​​машину найти ваш адрес примерно за 6 месяцев. Конечно, чем больше машин, тем быстрее взлом.

Гораздо более простым решением было бы использовать все пространство каждого уровня, а не только 10. Тогда 3 уровня было бы достаточно (~ 10 ^ 28).

20 однозначных уровней составляют около log(10^20)/log(2) = около 66 бит энтропии. Мне это кажется слишком низким.
Это, вероятно, учитывая будущие оптимизации. Мои расчеты основаны на текущем оборудовании и на том, что SHA512 достаточно случайный.
Сеть Биткойн в целом выполняет более 2^66 хэшей в минуту. Конечно, хэширование не является операцией EC, и существующее оборудование для хеширования не может быть использовано для него. Но вы не защищаете от известного злоумышленника. Вы хотите быть уверены, что ни в настоящее время, ни в ближайшем будущем никто не сможет взломать ваши ключи. Учитывая, что операции такого масштаба уже происходят каждую минуту, вам действительно следует искать гораздо больший запас прочности. 2 ^ 128 обычно является минимальной рекомендацией в наши дни.
Я согласен. И, конечно же, если бы у злоумышленника было оборудование всей биткойн-сети, это не было бы безопасным. Я сказал: «Чем больше машин, тем быстрее взлом». Это не должно было быть ответом на будущее, а просто оценкой, основанной на текущих скоростях хэширования и достаточно экономичном взломе.

Если вам нужно получить случайный ключ из другого (а не тот, который можно найти с помощью итеративного поиска), не используйте BIP32.

Если вы хотите нормальный вывод (позволяющий получать открытые ключи без знания родительского закрытого ключа), используйте схему оплаты по контракту: privkey = parent_privkey + H(parent_pubkey || id) pubkey = parent_pubkey + H(parent_pubkey || id) * G

Если вам нужен более сложный вывод, просто используйте родительский ключ в качестве дополнительного источника энтропии: privkey = H(parent_privkey || id) pubkey = H(parent_privkey || id) * G

(где id не менее 16 байт случайности)

BIP32 можно использовать, если он вам действительно нужен, для этого варианта использования, но он излишне сложен. Я бы предложил не менее 5 уровней 31-битных целых чисел (4 будет меньше 128 бит энтропии) или не менее 39 уровней для однозначных подконтуров (129,55 бит энтропии).

Очевидно, если бы я использовал ваше изображение в качестве энтропии для генерации случайного ключа, это было бы более случайным, чем если бы я использовал любое другое изображение;)