Mes: noviembre 2020

Todas las aplicaciones dicen ser seguras, pero la mitad de la tarea es conocer los algoritmos que dicen tener y la otra mitad sera comprobarlos. En este caso haremos solo la mitad. conocer los algoritmos y la secuencia de generación de llaves y proceso de cifrado.

Generación de claves

Las claves se generan utilizando el protocolo Diffie-Hellman.

Consideremos el siguiente escenario: al usuario A le gustaría iniciar una comunicación cifrada de extremo a extremo con el usuario B.

Enviar una solicitud
El usuario A ejecuta messages.getDhConfig para obtener los parámetros Diffie-Hellman: un primer p y un elemento de orden superior g.

La ejecución de este método antes de cada nuevo procedimiento de generación de claves es de vital importancia. Tiene sentido almacenar en caché los valores de los parámetros junto con la versión para evitar tener que recibir todos los valores cada vez. Si la versión almacenada en el cliente aún está actualizada, el servidor devolverá el constructor messages.dhConfigNotModified.

Se espera que el cliente verifique si p es un primo seguro de 2048 bits (lo que significa que tanto p como (p-1) / 2 son primos, y que 22047 <p <22048), y que g genera un subgrupo cíclico de orden primo ( p-1) / 2, es decir, es un residuo cuadrático mod p. Dado que g es siempre igual a 2, 3, 4, 5, 6 o 7, esto se hace fácilmente usando la ley de reciprocidad cuadrática, lo que produce una condición simple en p mod 4g, a saber, p mod 8 = 7 para g = 2; p mod 3 = 2 para g = 3; sin condición adicional para g = 4; p mod 5 = 1 o 4 para g = 5; p mod 24 = 19 o 23 para g = 6; y p mod 7 = 3, 5 o 6 para g = 7. Después de que el cliente haya verificado g y p, tiene sentido almacenar en caché el resultado para evitar repetir cálculos largos en el futuro. Esta caché puede compartirse con una que se utilice para la generación de claves de autorización.

Si el cliente tiene un generador de números aleatorios inadecuado, tiene sentido pasar el parámetro random_length (random_length> 0) para que el servidor genere su propia secuencia aleatoria aleatoria de la longitud apropiada.
Importante: el uso de la secuencia aleatoria del servidor en su forma original puede no ser seguro. Debe combinarse con una secuencia de cliente, por ejemplo, generando un número aleatorio de cliente de la misma longitud (client_random) y usando final_random: = random XOR client_random.

El cliente A calcula un número a de 2048 bits (usando suficiente entropía o el valor aleatorio del servidor; ver arriba) y ejecuta messages.requestEncryption después de pasar g_a: = pow (g, a) mod dh_prime.

El usuario B recibe la actualización updateEncryption para todas las claves de autorización asociadas (todos los dispositivos autorizados) con el constructor de chat encriptadoChatRequested. Se le debe mostrar al usuario información básica sobre el Usuario A y se le debe solicitar que acepte o rechace la solicitud.

Ambos clientes deben comprobar que g, g_a y g_b son mayores que uno y menores que p-1. También recomendamos comprobar que g_a y g_b estén entre 2 ^ {2048-64} yp - 2 ^ {2048-64}.

Aceptar una solicitud
Una vez que el usuario B confirma la creación de un chat secreto con A en la interfaz del cliente, el cliente B también recibe los parámetros de configuración actualizados para el método Diffie-Hellman. A partir de entonces, genera un número aleatorio de 2048 bits, b, utilizando reglas similares a las de a.

Habiendo recibido g_a de la actualización con encryptedChatRequested, puede generar inmediatamente la clave compartida final: key = (pow (g_a, b) mod dh_prime). Si la longitud de la clave es <256 bytes, agregue varios bytes cero a la izquierda como relleno, de modo que la clave tenga exactamente 256 bytes de longitud. Su huella dactilar, key_fingerprint, es igual a los últimos 64 bits de SHA1 (clave).

Nota 1: en este caso particular, SHA1 se usa aquí incluso para chats secretos MTProto 2.0.

Nota 2: esta huella dactilar se utiliza como una verificación de cordura para el procedimiento de intercambio de claves para detectar errores al desarrollar el software del cliente; no está conectada a la visualización de claves utilizada en los clientes como medio de autenticación externa en chats secretos. Las visualizaciones de claves en los clientes se generan utilizando los primeros 128 bits de SHA1 (clave inicial) seguidos de los primeros 160 bits de SHA256 (clave utilizada cuando el chat secreto se actualizó a la capa 46).

El cliente B ejecuta messages.acceptEncryption después de pasarlo g_b: = pow (g, b) mod dh_prime y key_fingerprint.

Para todos los dispositivos autorizados del Cliente B, excepto el actual, las actualizaciones de updateEncryption se envían con el constructor encryptedChatDiscarded. A partir de entonces, el único dispositivo que podrá acceder al chat secreto es el Dispositivo B, que realizó la llamada a messages.acceptEncryption.

El usuario A recibirá una actualización updateEncryption con el constructor encryptedChat, para la clave de autorización que inició el chat.

Con g_b de la actualización, el Cliente A también puede calcular la clave de clave compartida = (pow (g_b, a) mod dh_prime). Si la longitud de la clave es <256 bytes, agregue varios bytes cero a la izquierda como relleno, de modo que la clave tenga exactamente 256 bytes de longitud. Si la huella digital de la clave recibida es idéntica a la que se pasó a encryptedChat, los mensajes entrantes se pueden enviar y procesar. De lo contrario, debe ejecutarse messages.discardEncryption y notificarse al usuario.

Secreto directo perfecto
Para mantener seguras las comunicaciones pasadas, los clientes oficiales de Telegram iniciarán la re-clave una vez que se haya utilizado una clave para descifrar y cifrar más de 100 mensajes, o se haya utilizado durante más de una semana, siempre que la clave se haya utilizado para cifrar al menos un mensaje. A continuación, las llaves antiguas se guardan en un disco

fuente oficial: https://core.telegram.org/api/end-to-end