Si dos personas desean verificar que tienen la misma clave privada (por ejemplo, 256 bits), ¿cuál es el riesgo de compartir los primeros 8 caracteres en un canal potencialmente público?
¿Puede un atacante recuperar más información que solo esos personajes y / o cuánto más rápido podría un atacante descifrar la clave dados esos 8 caracteres?
El hecho de proporcionar cualquier parte de la clave privada la hace menos segura, al menos de forma marginal, simplemente porque proporciona a un atacante un espacio de clave potencial más pequeño para explorar.
No entiendo lo que quieres lograr. Lo único que deben hacer dos personas para verificar si tienen la misma información es intercambiar un hash.
Si está diseñando un protocolo y le preocupan los ataques de repetición, puede protegerse contra él realizando una respuesta de desafío usando un HMAC.
Editar :
Tal como se sugirió en los comentarios y se explicó en la perspicaz respuesta de DW, debo enfatizar que el impacto en La seguridad de su clave privada dependerá MUCHO del algoritmo que esté utilizando. En el peor de los casos, revelar solo una pequeña parte de la clave privada romperá completamente la seguridad de esa clave.
Revelar parte de la clave privada puede ser catastrófico, para algunos criptosistemas asimétricos (clave pública). El nivel exacto de riesgo depende exactamente de qué sistema criptográfico está utilizando. Algunos ejemplos:
Si está utilizando RSA con e = 3 para la clave pública, entonces revelar 1/4 de la clave privada (los 1/4 bits bajos de d) es suficiente para permitir que un atacante reconstruya la clave privada completa . Por ejemplo, si está utilizando un RSA de 2048 bits y revela los 512 bits menos significativos de la clave privada, entonces un atacante puede recuperar el resto de su clave privada. Este resultado se debe a Boneh, Durfee y Frankel. Hay otros resultados similares en la literatura (por ejemplo, sobre los bits más significativos, un subconjunto aleatorio de bits, etc.).
Con DSA, si se filtran algunos bits del nonce utilizado en cada firma (para una variedad de firmas), esto es suficiente para recuperar la clave privada. Por ejemplo, si puede observar 5 bits del código secreto que se usó en cada una de las 4000 firmas, eso es suficiente para recuperar una clave privada ECDSA de 384 bits. Esto no revela exactamente la clave privada (está revelando algún otro valor secreto generado durante la firma), pero es similar.
Me doy cuenta de que otras respuestas dicen que no hay problema. Esas respuestas podrían suponer que está utilizando un sistema de cifrado de clave simétrica. Para la mayoría de los sistemas criptográficos de clave simétrica, si revela una parte de la clave, pero una cantidad suficiente de la clave permanece sin revelar, es probable que aún estén seguros. Cuando se trata de criptosistemas asimétricos, las cosas son diferentes. Otras respuestas parecen suponer que la fuerza bruta (tratar exhaustivamente todas las claves privadas posibles) es el mejor ataque posible contra el criptosistema. Para muchos sistemas criptográficos asimétricos, esta suposición no es precisa.
¿Cuánto más rápido podría un atacante descifrar la clave dados esos 8 caracteres?
Es difícil responder sin saber de qué tipo de clave estamos hablando y con qué algoritmo se usa.
En el caso de cifrado simétrico donde la clave es completamente aleatoria (comprenda que cada bit tiene el mismo papel en la incertidumbre global de la clave), entonces depende principalmente de lo que representa "1 carácter" en términos de datos binarios.
En general, al revelar n bits , está reduciendo efectivamente el número de claves posibles en un factor de al menos 2^n .
1 character = (0 or 1) = 1 bit : 8 caracteres significa un factor de reducción de 2^8 = 256 . 1 character = 4 bits : 8 caracteres significa un factor de reducción de 2^32 = 4294967296 . 1 character = 6 bits : 8 caracteres significa un factor de reducción de 2^48 = 281474976710656 . Que, dependiendo de la cantidad de información revelada, puede (o no) usarse como palanca para romper su clave dependiendo de las posibles debilidades (actuales o futuras) de su algoritmo de cifrado.
También tenga en cuenta que en el caso de cifrado asimétrico donde la clave no es completamente aleatoria (por ejemplo, módulo de factor primario y exponente en RSA), revelar n bits en realidad puede revelar información mucho más útil y puede llevar a una pérdida de seguridad catastrófica.
Pero la verdadera pregunta es:
¿Por qué alguien tendría que hacer eso alguna vez?
No solo este método presenta un defecto de seguridad potencial, sino que no parece que la confiabilidad se ajuste a su propósito, ¿qué hay de los 248 bits restantes?
El método que describe es solo una función hash muy trivial que es completamente continua (muy mala para la verificación de integridad) y parcialmente reversible (muy mala para fines de seguridad).
Si realmente necesita hacer esto, use una función de hash criptográfica segura y ampliamente disponible como SHA-256 que generará un hash que es mucho más seguro (prácticamente irreversible y computacionalmente intensivo) y mucho más resistente a colisiones que "los primeros 8 caracteres".
Si está utilizando un cifrado asimétrico, nunca debería necesitar compartir ninguna parte (incluso un hash) de la clave privada, use la clave pública en su lugar .
Diría que va desde "no crítico, pero algo estúpido" a "desastroso", dependiendo de lo que significa "8 caracteres" y dependiendo de qué algoritmos se utilicen.
Si uno lee "8 caracteres" como lo que literalmente son, 64 bits, entonces reduce el tamaño de la clave en 64 bits (es algo menos drástico si se asume que "char" es un carácter codificado en base 64, entonces solo ser 48 bits).
Suponiendo que la "clave privada" en realidad se refiere a un algoritmo simétrico (¿poco probable?), es probable que sea tolerable, ya que 192 bits son mucho más allá de lo posible para la fuerza bruta. Pero, de nuevo, ¿por qué usar una clave de 256 bits en primer lugar?
Suponiendo que "clave privada, 256 bits" significa que utiliza una criptografía de curva elíptica de tipo (para cifrados simétricos, "privado" no tiene mucho sentido ya que todas las claves son privadas, y para RSA et al. 256 bits es demasiado pequeño para ser útil), baja su nivel de seguridad de poco menos de 128 bits (lo que es, actualmente, inviable) a algo menos de 96 bits. Que es ... bueno, no precisamente factible, pero casi. Teniendo en cuenta que la computación cuántica aún no está allí, pero en camino, "no del todo, pero casi" es un poco desastroso. Después de todo, lo que uno planea es el peor de los casos, no el mejor caso .
Es aún más desastroso, ya que hacer esto es absolutamente innecesario, 100%.
Si dos partes comparten una clave secreta, un método muy obvio para asegurarse de que sea la misma clave sería cifrar un patrón de bits aleatorio suficientemente largo (más largo que la salida de hash), dejar que el otro lado descifre el patrón de bits y enviar respalde un hash seguro (por ejemplo, SHA-256, SHA3, lo que sea) del patrón de bits.
Que la primera parte puede comparar trivialmente con el resultado de calcular el hash en el patrón aleatorio original.
En ningún momento se transmite la clave privada (o parte de ella), ni siquiera un hash de dicha clave (lo cual podría ser muy improbable, pero posiblemente, se invierta o proporcione un indicio hacia parte de ella), y desde allí son más bits de entrada aleatorios que bits de salida, es imposible determinar el patrón de bits original que se eliminó del valor hash, y usarlo para obtener un ángulo en el cifrado.
El atacante solo puede ver un patrón de bits aleatorio para el que necesita conocer la clave (desconocida) para obtener el original, y el hash de otro patrón de bits desconocido que podría ser uno de los muchos patrones de bits (sin ninguna forma de sabiendo cuál).
Otros ya han respondido por cuánto se filtra la información y, por lo tanto, cuánto se reduce la entropía para un atacante; y el punto principal que se debe comparar (públicamente) hashes también se ha señalado.
Sin embargo, esto es asumiendo que las dos personas que desean comparar las claves confían entre sí. Si no confían el uno en el otro, el problema es que si A envía hash (K) a B, B puede saber que A tiene el mismo, o un K diferente que B, pero que puede engañar y enviar el mismo hash, Hacer que A piense erróneamente que B también está en posesión de la misma clave.
Una solución a ese problema es que A envía el hash (K) a B, y espera que B envíe el hash (no K) a A, donde K no es el valor invertido de bit a bit de K. B solo puede enviar este hash a A si realmente posee K.
NOTA Lo siguiente asume una aceleración lineal (como la que se obtendría en un ataque de fuerza bruta): la aceleración puede ser EXPONENCIALMENTE MÁS, según el algoritmo.
Es muy difícil comprender números grandes, incluso me sorprendió cuando surgió la respuesta. Aquí hay una manera de pensarlo:
Si, sin ninguna información, llevaría 13.8 mil millones de años (la edad del universo hasta ahora) descifrar una clave, con la ayuda de 8 caracteres binarios, solo tomaría 0.023 segundos.
Esto es: 13.8 billones de años / 2 (bits_per_symbol * number_of_symbols) .
Usted dijo que el número de símbolos es "8 caracteres", y asumo que es binario, que tiene 8 bits por símbolo. así: 13.8 billones de años / 2 (8 * 8)
Si están uuencoded, o base64, tendrán 6 bits por símbolo, por lo que les tomará a todos 25 minutos trabajar con las combinaciones restantes.
Estas proporciones se aplican solo a la cantidad de bits que has revelado, y es independiente de la longitud de la clave (solo que la clave tardaría 13,8 mil millones de años en romperse).
El punto central de la criptografía de clave pública es que NUNCA NUNCA NECESITES compartir la clave privada. Cada clave privada debe existir solo en un lugar y nunca viajar a través de una red. El envío de claves va en contra del principio de criptografía de clave pública. NUNCA es necesario enviar claves privadas, de manera parcial o no.
Si desea que dos (o más) dispositivos diferentes puedan decodificar el mismo mensaje, haga que cada uno cree su propia clave privada, le envíe su clave pública (¡de forma segura!) y luego encripte el mensaje con ambas claves. Por lo general, con PKC, los mensajes largos se cifran utilizando un cifrado simétrico con una clave aleatoria, y luego la clave se cifra con PKC y se envía con el mensaje; puede cifrar fácilmente la clave aleatoria con varias claves públicas y enviarlas todas con el mismo mensaje.
Si todo lo que quieres hacer es mostrar que tienes la clave privada, puedes hacer lo siguiente:
Pídale a la persona con la que desea demostrar que proporcione un valor aleatorio (un "nonce"). Agregue su propio valor aleatorio, haga un hash y firme el hash. Envíe su valor aleatorio, y la firma, de vuelta.
Su contraparte tomará el nonce que enviaron, más su valor aleatorio, lo procesará y verificará la firma con su clave pública.
Al incluir un valor aleatorio del remitente, se demuestra que no seleccionó un valor que haya sido firmado previamente por el propietario real.
NO BAJO NINGUNA CIRCUNSTANCIA acepte algo enviado por otra persona y firme, sin ningún cambio. Pueden enviarle la huella digital de un documento que escribieron y usted estará firmando ese documento de manera efectiva.
Si Alice y Bob sospechan que comparten la misma clave privada, entonces ¿por qué no?
No soy un experto en criptografía. ¿Me estoy perdiendo algo?
Creo que lo anterior satisfará su pregunta sin exponer sus secretos. Eva tampoco sabrá la respuesta a la pregunta.
Lea otras preguntas en las etiquetas key-management