¿Cómo verificar el número con Bob sin que Eve lo sepa?


49

Debe verificar que su amigo, Bob, tenga su número de teléfono correcto, pero no puede preguntarle directamente. Debe escribir la pregunta en una tarjeta y dársela a Eve, quien se la llevará a Bob y le devolverá la respuesta. ¿Qué debe escribir en la tarjeta, además de la pregunta, para asegurarse de que Bob pueda codificar el mensaje para que Eve no pueda leer su número de teléfono?

Nota: Esta pregunta está en una lista de "preguntas de la entrevista de google". Como resultado, hay toneladas de versiones de esta pregunta en la web, y muchas de ellas no tienen respuestas claras o correctas.

Nota 2: La respuesta sarcástica a esta pregunta es que Bob debe escribir "llámame". Sí, eso es muy inteligente, 'fuera de la caja' y todo, pero no utiliza ninguna técnica de ese campo de CS donde llamamos a nuestro héroe "Bob" y su adversario de espionaje "Eva".

Actualización:
puntos de bonificación para un algoritmo que usted y Bob podrían completar razonablemente a mano.

Actualización 2:
Tenga en cuenta que Bob no tiene que enviarle ningún mensaje arbitrario, pero solo confirme que tiene su número de teléfono correcto sin que Eve pueda decodificarlo, lo que puede o no conducir a soluciones más simples.


1
Pero "llámame" no tiene ningún sentido, todavía no tiene tu número de teléfono correcto o al menos no estás seguro de si lo tiene, así que no creo que sea muy inteligente.
Gigili

1
@Gigili si recibe una llamada de él, entonces él tiene su número, si no recibe una llamada, entonces no.
Joe

1
Correcto. ¡Todavía pienso que no es inteligente!
Gigili

Otra respuesta irónica puede ser el cifrado César . Incluso si Eve intenta todas las compensaciones posibles, no tiene ninguna razón para elegir una secuencia de dígitos en lugar de otra (salvo tratar de llamarlos a todos).
Raphael

2
@Raphael ¿No hay solo 10 posibles cifrados César sobre dígitos?
Joe

Respuestas:


27

Primero debemos suponer que Eva es solo pasiva. Con esto, quiero decir que sinceramente le envía la tarjeta a Bob, y lo que sea que ella le devuelva a Alice es la respuesta de Bob. Si Eve puede alterar los datos en una o ambas direcciones (y su acción permanece sin ser detectada), entonces todo vale.

(Para honrar las tradiciones de larga data, las dos partes honestas involucradas en la conversación se llaman Alice y Bob. En su texto, usted dijo "usted". Mi verdadero nombre no es "Alice", pero responderé como si escribiera que Alice quiere verificar el número de teléfono de Bob.)

La respuesta simple (pero débil) es usar una función hash. Alice escribe en la tarjeta: "devuélveme el hash SHA-256 de tu número de teléfono". SHA-256 es una función hash criptográfica que se considera segura, en lo que respecta a las funciones hash. Calcularlo a mano sería tedioso pero aún factible (eso es alrededor de 2500 operaciones de 32 bits, donde cada operación es una adición, un desplazamiento o rotación de palabras, o una combinación de bits a nivel de bits; Bob debería poder hacerlo en un día o entonces).

Ahora, ¿qué hay de débil en eso? SHA-256, al ser una función hash criptográfica, es resistente a las "preimágenes": esto significa que dada una salida hash, es muy difícil recuperar una entrada correspondiente (ese es el problema que enfrenta Eve). Sin embargo, "muy difícil" significa "el método más fácil es la fuerza bruta: probar posibles entradas hasta que se encuentre una coincidencia". El problema es que la fuerza bruta es fácil aquí: no hay tantos números de teléfono posibles (en América del Norte, eso es 10 dígitos, es decir, solo 10 mil millones). Bob quiere hacer las cosas a mano, pero no podemos suponer que Eva es tan limitada. Una PC básica puede probar algunos millones de hashes SHA-256 por segundo, por lo que Eve se realizará en menos de una hora (menos de 5 minutos si usa una GPU).

Este es un problema genérico: si Bob es determinista (es decir, para un mensaje dado de Alice, siempre devolverá la misma respuesta), Eve puede simularlo. Es decir, Eve sabe todo sobre Bob, excepto el número de teléfono, por lo que prácticamente maneja 10 mil millones de Bobs, que difieren solo por su número de teléfono supuesto; y ella espera que uno de los Bobs virtuales devuelva lo que el verdadero Bob haya devuelto. La falla afecta a muchos tipos de soluciones "inteligentes" que implican nonces aleatorios y cifrado simétrico y todo lo demás. Es una falla fuerte, y su raíz radica en la gran diferencia en el poder de cómputo entre Eve y Bob (ahora, si Bob también tuviera una computadora tan grande como la de Eve, entonces podría usar una cámara lentafunción hash mediante el uso de muchas iteraciones; de eso se trata más o menos el hashing de contraseñas, con el número de teléfono en lugar de la contraseña; ver bcrypt y también esta respuesta ).

Por lo tanto, una solución no débil debe involucrar algo de aleatoriedad por parte de Bob: Bob debe lanzar una moneda o lanzar dados repetidamente e inyectar los valores en sus cálculos. Además, Eve no debe ser capaz de desentrañar lo que hizo Bob, pero Alice debe poder hacerlo, por lo que parte de la información se transmite con confianza de Bob a Alice. Esto se denomina cifrado asimétrico o, al menos, acuerdo de clave asimétrica. El algoritmo más simple de esa clase para calcular, pero aún razonablemente seguro, es RSA con el relleno PKCS # 1 v1.5 . RSA puede usar como exponente público. Entonces el protocolo va así:e=3

  • Alice genera un gran número entero , donde y son enteros prime de tamaño similar, de manera que el tamaño de es suficiente para garantizar la seguridad (es decir, al menos 1024 bits, a partir de 2012). Además, Alice debe hacer arreglos para que y no sean múltiplos de 3.p q n p - 1 q - 1n=pqpqnp1q1

  • Alice escribe en la tarjeta.n

  • Bob primeras almohadillas de su número de teléfono en una secuencia de bytes, siempre que , tal como se describe por PKCS # 1 (que significa: 00 02 xx xx xx ... 00 bb bb bb .., donde 'BB' son los bytes que codifican diez el número de teléfono y el 'xx' son valores de bytes aleatorios distintos de cero, para una longitud total de 128 bytes si es un entero de 1024 bits).nnn

  • Bob interpreta su secuencia de bytes como un valor entero grande (codificación big-endian) y calcula (entonces eso es un par de multiplicaciones con enteros muy grandes, luego una división, el resultado es el resto de la división). Eso todavía se puede hacer a mano (pero, nuevamente, probablemente tomará la mayor parte del día). El resultado es lo que Bob le envía a Alice.m 3 m o d nmm3 mod n

  • Alice usa su conocimiento de y para recuperar de enviado por Bob. La página de Wikipedia sobre RSA tiene algunas explicaciones razonablemente claras sobre ese proceso. Una vez que Alice tiene , puede quitar el relleno (los 'xx' no son cero, por lo que el primer byte 'bb' puede ubicarse sin ambigüedades) y luego tiene el número de teléfono, que puede comparar con el que tenía.q m m 3 m o d n mpqmm3 mod nm

El cálculo de Alice requerirá una computadora (lo que hace una computadora es siempre elemental y factible a mano, pero una computadora es endiabladamente rápida, por lo que el "factible" puede tomar demasiado tiempo en la práctica; el descifrado RSA a mano tomaría muchos semanas).

(En realidad, podríamos tener un cómputo manual más rápido usando el cifrado McEliece , pero luego la clave pública, lo que Alice escribe en la tarjeta, sería enorme, y una tarjeta simplemente no lo haría; Eve tendría que transportar un libro completo de dígitos)


1
Solo un comentario rápido, otra debilidad en el primer protocolo (Alice dice "envíame un hash del número de teléfono") es que es vulnerable a un ataque de repetición. Si estaba implementando esto en el mundo real, Alice debería enviar una cadena aleatoria (llamada "nonce") que se mezcla con el número de teléfono.
Seudónimo

1
Dijiste que "todo vale" si Eve puede modificar el mensaje, pero esto no es necesariamente una causa perdida. Al usar RSA, también podemos proteger el mensaje contra ataques MITM. Envíe una pregunta: "¿Tiene mi número de teléfono?", Más su clave pública, más una firma de (mensaje + su número de teléfono) firmada con su clave privada. Si Eve intenta modificar el mensaje (cambiar la clave pública a la suya), no podrá generar una firma válida ya que no conoce su número de teléfono.
stevendesu

15

Parece una aplicación clásica de Public Key Cryptosystem como RSA .

Usted envía su clave pública, BoB cifra su número de teléfono de su lista de contactos y se lo devuelve.


55
Dado a Bob y Eve, probablemente esa sea la idea clave. ¿Es práctico en este contexto (lápiz y papel)? Además, esperaba un poco más que un enlace a un artículo de Wikipedia con el indicador "este artículo necesita edición".
Joe

@ Joe: he editado para incluir otro enlace. Estoy bastante seguro de que has oído hablar de RSA. RSA es probablemente lo suficientemente práctico, ya que escribir dice que 1000 dígitos no deberían tomar mucho tiempo.
Aryabhata

14

Una de las cosas más básicas que puede hacer es un intercambio de claves Diffie-Hellman . No requiere que tenga claves configuradas antes de que comience la comunicación, ya que negocia una de manera que los oyentes no puedan derivar la clave por sí mismos. Vea el artículo completo de Wikipedia para más detalles.

Envías los parámetros de Bob DH, y ( es un número primo grande adecuado, y generalmente un número pequeño) y tu clave pública , donde es un número secreto grande (es su clave privada), así como las instrucciones para que Bob envíe lo siguiente:g p g g a m o d p apgpggamodpa

  • su clave pública , donde es un gran número secreto de su elección;bgbmodpb
  • lo que él cree es su número de teléfono, cifrado usando un algoritmo de cifrado simétrico con una clave derivada del secreto compartido .gabmodp

Eve puede ver y , pero efectivamente no puede calcular .g b m o d p g agamodpgbmodpgabmodp

Siempre que se implemente correctamente y tanto los comunicadores como el atacante tengan aproximadamente el mismo poder de cálculo a su disposición, esto es seguro.


2

Bob no tiene que enviar ningún mensaje que pueda descifrar. Solo tiene que demostrarte que tiene tu número de teléfono. Por lo tanto, Cryptographic Hash Functions (encriptación unidireccional) ofrece una alternativa a un criptosistema de clave pública. SHA-2 es actualmente un ejemplo popular de tal función.

En esta estrategia, nunca tendrá que descifrar el mensaje de Bob. Le dice a Bob qué función hash le gustaría que usara, por ejemplo, "Bob, usa SHA-2 para encriptar mi número de teléfono y que Eve me devuelva el resultado". Luego, usa el mismo algoritmo para cambiar su número de teléfono y verifica si obtiene el mismo algoritmo que obtuvo Bob. Es extremadamente improbable que dos números de teléfono diferentes den como resultado el mismo hash, por lo que puede determinar si Bob tiene o no su número de teléfono correcto.

Si usted, Bob y Eve no tienen computadoras disponibles para calcular la función hash (o realizar un ataque de fuerza bruta), es posible usar la función hash que sacrifica algo de seguridad contra los ataques de fuerza bruta, pero es mucho más fácil para usted y Bob calcular.


¡Estaba escribiendo la misma respuesta! Desafortunado. Lo publicaré de todos modos ya que pasé tiempo en él.
Gigili

@Gigili Esperaba que alguien escribiera esta respuesta, pero decidí hacerlo cuando vi que nadie estaba ofreciendo esta alternativa todavía ... Todavía estoy buscando una versión apta para lápiz y papel. Honestamente, no quisiera pedirle a mi amigo que haga RSA o SHA-2 a mano.
Joe

El problema es que cada algoritmo simple que se puede hacer a mano sería encriptado por Eve.
Gigili

@Gigili, ¿te refieres a "descifrado por Eve"? El problema es muy limitado. Parece que debería haber un hash unidireccional más simple de enteros de 7 dígitos que Eve no puede deshacer para recuperar el número original.
Joe

Vaya, quise decir descifrado obviamente.
Gigili

0

Una solución simple sería:

Tanto Alice como Bob están de acuerdo en el mismo color. y no hay problema si Eve lo sabe, lo llamaremos P. Digamos que es amarillo. Ahora, Alice y Bob eligen al azar un color privado, digamos "x". Alice elige rojo, y Bob elige azul. Ahora los mezclan con el P. Alice ahora tiene naranja y Bob tiene verde. Alice envía el color naranja a Bob, y Bob envía su color verde a Alice Eve ahora sabe sobre amarillo, naranja y verde, pero Alice también sabe su color privado rojo, y Bob sabe su color privado azul, que nadie más sabe. Tanto Alice como Bob toman sus colores privados originales y los agregan a los que acaban de intercambiar. Ahora, si mezclan sus colores privados originales, rojo y azul, en el color compartido, ambos terminan con el mismo color, marrón o rojo ladrillo.

En lugar de mezclar colores, puede usar modo que p sea un número primo grande, y g es una raíz primitiva de p porque si hace para cualquier x, el resultado (un número entre cero y p - 1) es igualmente probable que sea cualquiera de esos, por eso hay una raíz primitiva. si p es un número primo 2n + 1, de modo que n también es primo, entonces sabe que 2 es una raíz primitiva de p (lo que significa que no tiene que molestarse en calcular la raíz primitiva, que es un poco difícil) por lo tanto, secreto compartido = para Bob, y para Alice.gx(modp)gx(modp)Ax(modp)By(modp)


Creo que puedes escribir algo como esto en la tarjeta:

El número es múltiplo de 3,5 y 7 (por ejemplo).

Hay ( es el número de dígitos) posibilidades y esa idea invalidará algunas pocas posibilidades para el que tiene una idea al respecto. Entonces el descifrado por Eva no sucederá.(10)nn


Esta es una narración de la imagen encontrada en el artículo de Wikipedia del intercambio de claves Diffie-Hellmann . Al menos deberías mencionar tu fuente.
Raphael

@Raphael: No lo sabía, alguien me lo explicó y pensé que era una buena idea.
Gigili

0

Solo pídale a Bob que multiplique el número por 2 o 3 o cualquier otra cosa y que xor ese número con el número mismo. Es factible a mano y reversible si se conoce el número. Sin sha, rsa o md5. Solo matemáticas simples.


3
Esta respuesta es incorrecta. Simple, factible a mano y totalmente inseguro. Simplemente no funciona. Eve puede recuperar mucha información sobre el número de teléfono de esto.
DW

0

Envíele a Bob una palabra encriptada encriptada con su número de teléfono; si él te devuelve la palabra clave, sabes que tiene el número correcto.

La debilidad es que Eve puede simular a Bob, así que solo prueba cada número de teléfono hasta que obtenga el que le da la palabra clave cuando Bob regresó.

Por lo tanto, haga que Bob agregue un número aleatorio muy grande a la palabra de código y luego encripte antes de enviárselo. Esto hace que el espacio de búsqueda de Eves sea tan grande como desee.


Esto no parece correcto. Si Bob tiene el número incorrecto, primero lo descifrará y obtendrá una palabra de código incorrecta. Después de eso, agrega un número aleatorio a la palabra de código y lo cifra con la clave incorrecta. Cuando se recibe el mensaje y se descifra con la clave correcta, el primer segmento del mensaje recuperado puede ser la palabra de código correcta aunque el número que Bob tiene sea incorrecto.
InformadoA

@randomA Solo necesita hacer la (s) palabra (s) de código lo suficientemente larga como para que la probabilidad de que eso ocurra sea tan pequeña que no le importe.
Ian Ringrose

Lo que dijiste es cierto, pero la solución elegida también es muy buena en este tema. Solo estaría en desacuerdo con la solución elegida por parte de "por lo que parte de la información se transmite con confianza de Bob a Alice". Si uno usa un mensaje de relleno que es lo suficientemente grande y no contiene ningún símbolo utilizado para representar el número de teléfono, entonces Bob puede ingresar el número de teléfono al azar y Alice puede recuperar fácilmente el número de teléfono del mensaje descifrado sin conocer los pasos aleatorios que Bob tomó ( no se necesita información confidencial en este caso).
InformadoA

-1

Escribiré unos 10 números de teléfono en la tarjeta y entre ellos me aseguraré de que Mi número aparezca junto al número de Bob y mencionaré "Hola Bob, mi número está al lado de tu número, verifica" :)


1
suponiendo que sé el número de Bob y Eve no: P
everlasto

-1

Creo que la pregunta es mucho más simple de lo que todos piensan. Estamos obligados a verificar que el número que Bob tiene es correcto (o como podría ser, incorrecto). Como estamos "verificando" si el número es correcto, se puede suponer que Bob ya tiene su número. Por lo tanto, no es necesario enviarle a Bob su número en algún código. Mi respuesta sería: "Querido Bob, por favor llama a mi número. Gracias, Alice".


1
La pregunta ya excluye explícitamente esta respuesta trivial.
David Richerby

-2

intenta hacer una jugada trik como esta

solución1: si el número es 37, el mapa hash se vería así

01 07

15 12

25 20

31 36

49 43

53 50

60 62

72 72

85 82

91 94

y hacer lo mismo para 10 dígitos o incluso más solo para confundir: P

solución2: o construya un polinomio en el que su número se convierta en otro número único

solution3: escribe esto en la carta "amigo llámame"

solución4: escribe una función de tal manera que realice operaciones en cada dígito y devuelva 0, luego envía una solución verdadera o falsa5: si ambos extremos comparten una función hash común ... hace la vida muy fácil


No es nada obvio cómo su esquema codifica 37.
David Richerby

todo lo que necesitamos hacer es mapear ... 31 en negrita significa que 3 está en la posición 1 ... 72 significa que 7 está en la posición 2 ... perdón si no fue muy intuitivo de entender
Ajay Reddy

Esto debe explicarse en detalle en la respuesta. Pero, en serio, si ese es su esquema de codificación, no es exactamente seguro, ¿verdad?
David Richerby

-2

Creo que podemos hacer esto usando operaciones básicas en cuanto a bits o podemos personalizarlo para trabajos en papel y lápiz. Si el número de Alice es para ex: 663, entonces ella puede convertir el número usando esta metodología. Convierta cada dígito a una representación binaria equivalente, diga esto como A 663-> 110110011 que invierta los bits correspondientes para cada número individual, diga esto como B-> 011 011 110 Ahora haga A y B-> 010 010 010 Ahora envíe este número a Bob y pida que haga lo mismo si el resultado es el mismo, pídale que diga sí o no. En este caso, Eve no podrá decodificar el número y hay una probabilidad muy baja de que diferentes números terminen en esta misma representación. La única forma en que Eve podría adivinar es escribiendo todas las combinaciones posibles y luego probándolas todas, pero para tener en cuenta que podemos complicar más esto usando el desplazamiento hacia la izquierda o hacia la derecha y agregando bits ficticios.


Esto no funciona Primero, el bit del medio de cada grupo de 3 bits se deja intacto. Segundo, el primer y tercer bit de cada grupo del mensaje transmitido siempre será el mismo, y generalmente cero, lo que conducirá a muchos falsos positivos. Tercero, y fatalmente, tres bits solo pueden representar ocho valores, pero un dígito decimal puede tomar cualquiera de los diez valores. Cuarto, su última oración es esencialmente: "Ah, y si eso no funciona, intente algo más complejo". ¿Como?
David Richerby

-3

Por favor llámame (mi nombre es 1001001). Si no puede comunicarse conmigo, escriba el número de teléfono que tiene y pídale a Eve que me devuelva.

Explicación: si Bob obtuvo mi # correcto, puede comunicarse conmigo, entonces sé que es un # correcto; si Bob no obtuvo mi número correcto, Eve no puede leer mi número de teléfono (correcto) también. De esta manera, ya verifiqué que mi amigo, Bob, tiene mi número de teléfono correcto o no.


a everlasto: Eve puede contactar a Bob para que probablemente tenga su #. Por lo tanto, si pregunta "Hola Bob, mi número está al lado de su número, verifique", Eve lo conocerá.
Pobol Wong

1
La pregunta dice explícitamente que no puedes enviarle a Bob una tarjeta diciendo "llámame". Y Bob escribiendo el número incorrecto en la tarjeta si no podía pasar no agrega nada.
David Richerby

Escribí un programa de codificación / decodificación LZW antes. Puedo pedirle a Bob que lo use para enviarme el número codificado de mi teléfono y también puedo usarlo para codificar la parte correcta de mi teléfono.
Pobol Wong

a David Richerby: la pregunta solo menciona "no puedes preguntarle directamente", lo que significa que yo, 1001001, no puedo preguntarle a Bob directamente, pero debería poder pedirle que me llame con el número de teléfono que recibió.
Pobol Wong

Lee la pregunta con más cuidado. La "Nota 2" en la pregunta rechaza la solución de enviar una nota pidiéndole a Bob que lo llame porque no usa ninguna ciencia de la computación.
David Richerby
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.