¿Cuál sería una profundidad de subclave racional para usar de modo que mi dirección no sea factible de localizar a través de una búsqueda sistemática?

Usando pycoin.

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

¿A cuántos niveles de profundidad en el árbol tendría que ir (usando solo un dígito) antes de que un atacante no pueda encontrarlo usando una búsqueda sistemática?

Veinte niveles de profundidad pensé que sería adecuado:

10**20 = 100000000000000000000

Sé que hay formas más efectivas de ocultar su dirección, pero estoy interesado en este caso de uso particular.

Gracias.

Respuestas (2)

Es un poco extraño usar dígitos individuales para toda la ruta HD, ya que la especificación BIP32 le permite seleccionar números hasta 2^31 (no endurecidos). La derivación de clave BIP32 utiliza en gran medida SHA512. El ASICS actual para SHA256 puede calcular alrededor de 10 billones de SHA256 por segundo, es decir, alrededor de 160 quintillones de operaciones hash en aproximadamente 6 meses. Suponiendo que se pueda construir un ASIC con aproximadamente el mismo poder de hash, necesitaría profundizar unos 20 niveles para obligar a una máquina como esa a encontrar su dirección en aproximadamente 6 meses. Por supuesto, más máquinas significan un craqueo más rápido.

Una solución mucho más simple sería usar todo el espacio de cada nivel en lugar de solo 10. 3 niveles serían suficientes (~ 10 ^ 28)

20 niveles de un solo dígito es alrededor de log(10^20)/log(2) = alrededor de 66 bits de entropía. Eso me parece demasiado bajo.
Probablemente se le den futuras optimizaciones. Mis cálculos se basan en el hardware actual y que SHA512 es lo suficientemente aleatorio.
La red Bitcoin en su conjunto genera más de 2^66 hashes por minuto. Claro, el hashing no es una operación EC y el hardware de hash existente no se puede usar para ello. Pero no te estás protegiendo contra un atacante conocido. Quiere estar seguro de que nadie actualmente o en un futuro mediano tiene la capacidad de descifrar sus claves. Dado que las operaciones de esta magnitud ya ocurren cada minuto, realmente debería buscar un margen de seguridad mucho mayor. 2^128 suele ser la recomendación mínima en estos días.
Estoy de acuerdo. Y ciertamente, si el atacante tuviera el equipo completo de la red bitcoin, eso no sería seguro. Dije "más máquinas significan un craqueo más rápido". Esto no pretendía ser una respuesta a prueba de futuro, solo una estimación basada en las tasas de hash actuales y un crack razonablemente rentable.

Si necesita derivar una clave aleatoria de otra (en lugar de una que se puede encontrar a través de una búsqueda iterativa), no use BIP32.

Si desea una derivación normal (permitiendo que las claves públicas se deriven sin conocer la clave privada principal), use el esquema de pago por contrato: privkey = parent_privkey + H(parent_pubkey || id) pubkey = parent_pubkey + H(parent_pubkey || id) * G

Si desea una derivación más dura, simplemente use la clave principal como fuente de entropía adicional: privkey = H(parent_privkey || id) pubkey = H(parent_privkey || id) * G

(donde id es al menos 16 bytes de aleatoriedad)

BIP32 se puede usar si realmente lo necesita, para este caso de uso, pero es innecesariamente complicado. Sugeriría no menos de 5 niveles de enteros de 31 bits (4 serían menos de 128 bits de entropía) o no menos de 39 niveles para subcaminos de un solo dígito (129,55 bits de entropía).

Aparentemente, si usé una foto tuya como entropía para generar una clave aleatoria, sería más aleatorio que si hubiera usado cualquier otra imagen;)
¿Cuál sería una profundidad de subclave racional para usar de modo que mi dirección no sea factible de localizar a través de una búsqueda sistemática?
RespuestasAquíPolítica de privacidad1y, 0v