¿Conocer la mitad de la clave privada proporciona información útil?

Tengo una clave privada y quiero almacenar una versión en papel de la misma. Me gustaría dividirlo en 2 partes iguales (los primeros 32 números y los últimos 32 números) y almacenarlos en 2 ubicaciones diferentes. Supongamos que estoy 100% seguro de que nadie puede acceder a ambas partes, pero es posible que alguien pueda robar una de ellas.

¿Cuánto estoy comprometido?

Para explicar la pregunta: entiendo que el atacante necesita adivinar solo 32 números hexadecimales en lugar de 64 para completar la clave privada. ¿Es eso mucho más fácil que adivinar 64? ¿Esto socava seriamente la seguridad de mi cuenta? ¿Y hay algo que me estoy perdiendo que lo hace aún más fácil que adivinar los 32 números restantes (por ejemplo: dados los primeros 32 números, solo es posible un posible subconjunto de los 32 números restantes debido a alguna restricción)?

Respuestas (2)

Para números de 64 dígitos hexadecimales, hay 16 ^ 64= 115792089237316195423570985008687907853269984665640564039457584007913129639936posibilidades.

Para números de 32 dígitos hexadecimales, hay 16 ^ 32= 340282366920938463463374607431768211456posibilidades.

Si alguien tiene la mitad de su clave privada, su seguridad se ha reducido en un factor de 340282366920938463463374607431768211456. Ese es un factor importante, pero la cantidad de posibilidades que necesitarían verificar para forzar su billetera sigue siendo gigante. Probablemente todavía no serían capaces de entrar.

Sin embargo, para evitar cualquier pérdida de seguridad si una pieza se ve comprometida, recomendaría un esquema diferente, por ejemplo:

Genere otro número hexadecimal aleatorio de 64 dígitos, diferente de su clave privada. XOR este nuevo número junto con su clave privada. Ahora, almacene el nuevo número aleatorio y el resultado de la operación XOR en las dos ubicaciones diferentes.

Para recuperar su clave privada, necesitaría ambas piezas y XOR juntas. De esta manera, su seguridad no se ve comprometida en absoluto si alguien tiene algunas pero no todas las piezas.

Puedes usar este mismo esquema con cualquier cantidad de piezas.

Solo asegúrate de hacerlo bien :-)

Estuve a punto de responder y proponer xor como lo hiciste. Así que confirmo que xoring es la mejor manera de hacerlo. Para agregar seguridad, también puede agregar algo aleatorio en su clave privada agregando algunos números aleatorios en lugares conocidos antes de xoring. Recuerde los lugares en otro lugar y luego tendrá una protección de 3 partes. Aleatorio, xor resultado y posiciones. Guarde cada parte varias veces en diferentes lugares. Nunca almacene 2 partes en el mismo lugar. Luego recuerda los lugares donde los guardaste...
Ty por la respuesta y la sugerencia adicional de usar XOR. ¿Tiene alguna solución similar para frases de contraseña donde usamos caracteres ASCII? (ejemplo: frases de contraseña bip44 válidas, donde el número y la longitud de las palabras pueden diferir)
Puedes xor cualquier cosa incluso ASCII. Después de todo, todo son bits. Puedes echar un vistazo a este sitio web: xor.pw
@AnotherUser también para tener una longitud constante, simplemente agregue espacios o ceros. Supongo que eso es lo que hacen en el sitio que vinculé. Intente xorear un ASCII como "hola" con un hexadecimal como 123456789 que es más largo y luego xor este resultado con 123456789 nuevamente y le devolverá su saludo.
el problema con este enfoque es que aplicar XOR en caracteres ascii generalmente da como resultado una salida de caracteres no estándar
Si desea generalizar esto en "ocultar X piezas y solo necesita recuperar XN para recuperar la clave", puede consultar Shamir's Secret Sharing (y el software que lo realiza). Esto le permitiría perder algunos de los papeles, a costa de un poco más de trabajo para recuperarlos.
@NicolasMassart También podría mantenerlo simple y simplemente hacer un segundo XOR. Es igual de seguro (de lo contrario, es solo seguridad a través de la oscuridad).
@corsiKa el objetivo es agregar "otra pieza para saber", pero sí, puedes hacer otra xor agregará otra pieza al rompecabezas.
@AnotherUser Codificarlo en Base32 sería un buen segundo paso después del XOR si la legibilidad es una preocupación. El esquema Base32 de Crockford es uno que estoy considerando para este propósito.

¿Cuánto estoy comprometido?

Más de lo que sugeriría el simple análisis.

La clave privada se utiliza como clave ECDSA. Resulta que, para una clave privada con n bits desconocidos, es posible recuperar la clave completa en 2**(n/2) veces.

Con n=256 (es decir, no conoce ninguno de los bits inicialmente), esto es 2**128, que generalmente se supone que es demasiado difícil para cualquiera.

Sin embargo, si le das al atacante la mitad de la clave (y así tienes n=128), bueno, esto significa que recuperar el resto de la clave es 2**64 veces; esto ciertamente no es trivial (y, por lo tanto, no tendría que preocuparse de que nadie lo resuelva en su computadora portátil), sin embargo, esto sería práctico para adversarios grandes y bien financiados.

Por lo tanto, ciertamente aceptaría la sugerencia de Jesse de hacer un xor en lugar de una simple concatenación; de esa manera, el atacante no aprende nada de una parte del secreto.

¿El atacante tiene que saber qué bits son desconocidos? Por ejemplo, si tengo 01una clave de 4 bits, ¿tengo que considerar 01xx, 0x1x, 0xx1, x01x, x0x1y xx01por separado, o el 2**(n/2)algoritmo de tiempo tiene en cuenta la posición desconocida?
@chepner: los algoritmos 2 ** (n/2) (al menos, los que conozco) asumen que conoce las posiciones de los bits conocidos. Además, creo que debo resaltar que esos algoritmos no funcionan contra claves generales (por ejemplo, claves AES); es porque es específicamente una clave ECDSA que lo hace posible (y el atacante puede usar algunas relaciones que ocurren porque la curva EC subyacente forma un grupo)