![BtcAndres's tweet photo. De cómo Telegram se rio del mundo (bueno, no había muchos usuarios en su momento, según leerás más adelante) con su cRiPtOgRaFíA. Si tuviste la mala suerte de activar los mensajes súper secretos súper cifrados con última tecnología y creías que estabas seguro, este artículo es para ti.
Recordando: "Esto era un bug, pero seamos sinceros, era simplemente una puerta trasera". No se hagan. NO SE HAGAN. “Los no practicantes podrían pensar que esta es una defensa razonable en profundidad, cinturones y tirantes, pero en la ingeniería criptográfica agregar complejidad para defenderse contra escenarios que conducen al compromiso de todos modos es simplemente inútil.”
Esta es la historia de un error que se descubrió y solucionó en el protocolo criptográfico creado por ellos mismos (¿qué pasó con aquel dicho que decía que no inventaras tu propia criptografía? Pues qué crees que pasó… Sí podía salir mal, pues salió bien mal) de Telegram hace unos diez años. El error no tuvo ninguna prensa, y nadie parece saberlo, probablemente porque solo se publicó en ruso (cuyo link a las mega salsas te voy a publicar en el tweet, mucho más abajo de este).
Hasta el día de hoy, es el bicho más visto como una puerta trasera que he visto (duda y acertarás, querido lector).
Telegram es una popular aplicación de chat que utiliza su propio... extraño protocolo para cifrar los chats, llamado MTProto. El protocolo se utiliza tanto para cifrar todos los mensajes al servidor de Telegram como para cifrar los "chats secretos" de extremo a extremo de opción 1:1. En texto, no puedo hacer justicia a las expresiones faciales de los criptógrafos cuando mencionas el protocolo de Telegram, así que créeme que es raro.
Aquí explico: Los mensajes directos no están cifrados de extremo a extremo de forma predeterminada. Los usuarios pueden habilitar lo que Telegram llama "chats secretos", pero deben hacerlo para cada conversación que deseen cifrar. Esta opción nunca está activada de forma predeterminada y no se puede activar para mensajes directos grupales ni canales. Ahora, si tuviste la mala suerte de activar los mensajes súper secretos súper cifrados con última tecnología y creías que estabas seguro, de eso va este artículo. Seguimos.
El consenso actual parece ser que la última versión no se rompe de manera conocida que sea lo suficientemente grave o relevante como para afectar a los usuarios finales, asumiendo que la implementación es correcta. Eso es casi tan seguro como dejar cables expuestos alrededor de su casa porque no están vivos o colocados lo suficientemente altos como para que nadie los toque.
Sin embargo, la versión original estaba completamente rota, de la manera más desconcertante.
Las sesiones de chat de Telegram de extremo a extremo utilizan Diffie-Hellman de campo finito para establecer una clave compartida entre los dos participantes. La negociación ocurre a través de mensajes transmitidos por el servidor de Telegram. Diffie-Hellman es un bloque de construcción fundamental de muchos criptosistemas, y permite a dos partes establecer un secreto compartido que ningún escucha no puede derivar. Sin embargo, es solo una parte de un intercambio de claves seguro, porque un atacante capaz de interceptar los mensajes podría simplemente establecer dos sesiones separadas con las dos partes, llevando a cabo un ataque de persona en el medio. Las partes necesitan alguna forma de verificar que derivaron el mismo secreto. En TLS, utilizan una firma de un certificado. En la mayoría de las aplicaciones de chat seguras, hay una huella digital ("Números de seguridad" en Signal) que las dos partes pueden comparar fuera de banda. Lo importante es que si las dos partes derivan el mismo secreto, pueden estar seguros de que nadie más tiene acceso a él.
El intercambio de claves de Telegram se describe en la sección "Generación de claves" de los documentos de la API de extremo a extremo de Telegram. Concretamente, Alice solicita los parámetros DH (p, g) de Telegram, los verifica minuciosamente, calcula un valor aleatorio a y envía g^a mod p a Telegram. Bob recibe (p, g, g^a mod p), calcula de manera similar b y g^b mod p y envía este último de vuelta (junto con un hash truncado de la clave derivada, por alguna razón).
Ahora, normalmente las dos partes calcularían la clave compartida como (g^a)^b mod p y (g^b)^a mod p. En cambio, la versión original de MTProto la calculaba como
donde nonce era un valor arbitrario, supuestamente aleatorio, enviado por el servidor junto con la contribución pública del par.
Esta fue una adición completamente no estándar e inútil, y todo lo que hizo fue dejar que el servidor realizara un ataque de persona en el medio no detectado. Vamos a ver cómo.
En un PitM normal, el servidor negocia dos sesiones separadas de Diffie-Hellman con Alice y Bob, que terminan con diferentes claves compartidas, que podrían detectar comparando las huellas dactilares.
Sin embargo, con la adición de nonce, el servidor podría "arreglar" la clave de Alice para que coincida con la de Bob manipulando el nonce de Alice. Las dos partes terminarían con la misma huella digital, y no podrían decir que ocurrió un ataque, pero el servidor (y nadie más) conocería la clave compartida, lo que le permitiría descifrar todos los mensajes.
¿Por qué digo que esta adición fue inútil? ¡Porque literalmente no tenía ningún propósito! De hecho, la vulnerabilidad se solucionó eliminando silenciosamente el paso nonce de los documentos.[ 4] Una revisión posterior de la API eliminó el parámetro nonce con la leyenda "Mejorar los chats secretos". Toda la referencia original de la API que se dijo sobre el nonce es "Secuencia de servidor aleatorio para el cálculo de la clave".
Nunca escuché una explicación plausible de por qué los diseñadores de MTProto hicieron todo lo posible para agregar una complejidad inútil a su protocolo, con el único resultado de hacer posible la interceptación indetectable.
En Twitter dan algunas luces (mucho más abajo te dejo el tweet mencionado) a una declaración oficial de Telegram sobre esto que ya no pude encontrar. Afirma que el nonce estaba allí para proteger a los clientes con generadores de números aleatorios débiles. Esto es lo que había enterrado en una nota al pie cuando no pude encontrar una cita para atribuir esa explicación a Telegram:
Esto no tiene sentido por varias razones: 1) es probable que los clientes con aleatoriedad débil estén tostados de todos modos, porque el bizarro no-un-MAC de Telegram se basa en la aleatoriedad en la carga útil para evitar un oráculo de descifrado fuera de línea (hay un hash de texto plano de la carga útil en el cable, ¡te dije que esto era extraño!) ; 2) la API también permite a los clientes solicitar bytes aleatorios del servidor a XOR con su recurso compartido secreto; y 3) defenderse contra la aleatoriedad débil confiando en una contribución del servidor se defiende contra todo menos el servidor, que es el atacante relevante en la configuración de extremo a extremo. (Dicho de otra manera, cualquiera que pueda interceptar mensajes cliente-servidor puede ver la aleatoriedad adicional, lo que lo hace discutible). Los no practicantes podrían pensar que esta es una defensa razonable en profundidad, cinturones y tirantes, pero en la ingeniería criptográfica agregar complejidad para defenderse contra escenarios que conducen al compromiso de todos modos es simplemente inútil.
De todos modos, ha pasado un tiempo, el mundo es un lugar diferente ahora, y tal vez la navaja de afeitar de Hanlon corta más de lo que pensaba. Creo que hay mejores razones para no usar Telegram hoy que este viejo error, pero sigue siendo en lo que pienso cada vez que la gente habla de "bugdoors"; inverosímil. ¡El listón está alto!](https://pbs.twimg.com/media/GWFambuWMAA3j8A.png)
![BtcAndres's tweet photo. De cómo Telegram se rio del mundo (bueno, no había muchos usuarios en su momento, según leerás más adelante) con su cRiPtOgRaFíA. Si tuviste la mala suerte de activar los mensajes súper secretos súper cifrados con última tecnología y creías que estabas seguro, este artículo es para ti.
Recordando: "Esto era un bug, pero seamos sinceros, era simplemente una puerta trasera". No se hagan. NO SE HAGAN. “Los no practicantes podrían pensar que esta es una defensa razonable en profundidad, cinturones y tirantes, pero en la ingeniería criptográfica agregar complejidad para defenderse contra escenarios que conducen al compromiso de todos modos es simplemente inútil.”
Esta es la historia de un error que se descubrió y solucionó en el protocolo criptográfico creado por ellos mismos (¿qué pasó con aquel dicho que decía que no inventaras tu propia criptografía? Pues qué crees que pasó… Sí podía salir mal, pues salió bien mal) de Telegram hace unos diez años. El error no tuvo ninguna prensa, y nadie parece saberlo, probablemente porque solo se publicó en ruso (cuyo link a las mega salsas te voy a publicar en el tweet, mucho más abajo de este).
Hasta el día de hoy, es el bicho más visto como una puerta trasera que he visto (duda y acertarás, querido lector).
Telegram es una popular aplicación de chat que utiliza su propio... extraño protocolo para cifrar los chats, llamado MTProto. El protocolo se utiliza tanto para cifrar todos los mensajes al servidor de Telegram como para cifrar los "chats secretos" de extremo a extremo de opción 1:1. En texto, no puedo hacer justicia a las expresiones faciales de los criptógrafos cuando mencionas el protocolo de Telegram, así que créeme que es raro.
Aquí explico: Los mensajes directos no están cifrados de extremo a extremo de forma predeterminada. Los usuarios pueden habilitar lo que Telegram llama "chats secretos", pero deben hacerlo para cada conversación que deseen cifrar. Esta opción nunca está activada de forma predeterminada y no se puede activar para mensajes directos grupales ni canales. Ahora, si tuviste la mala suerte de activar los mensajes súper secretos súper cifrados con última tecnología y creías que estabas seguro, de eso va este artículo. Seguimos.
El consenso actual parece ser que la última versión no se rompe de manera conocida que sea lo suficientemente grave o relevante como para afectar a los usuarios finales, asumiendo que la implementación es correcta. Eso es casi tan seguro como dejar cables expuestos alrededor de su casa porque no están vivos o colocados lo suficientemente altos como para que nadie los toque.
Sin embargo, la versión original estaba completamente rota, de la manera más desconcertante.
Las sesiones de chat de Telegram de extremo a extremo utilizan Diffie-Hellman de campo finito para establecer una clave compartida entre los dos participantes. La negociación ocurre a través de mensajes transmitidos por el servidor de Telegram. Diffie-Hellman es un bloque de construcción fundamental de muchos criptosistemas, y permite a dos partes establecer un secreto compartido que ningún escucha no puede derivar. Sin embargo, es solo una parte de un intercambio de claves seguro, porque un atacante capaz de interceptar los mensajes podría simplemente establecer dos sesiones separadas con las dos partes, llevando a cabo un ataque de persona en el medio. Las partes necesitan alguna forma de verificar que derivaron el mismo secreto. En TLS, utilizan una firma de un certificado. En la mayoría de las aplicaciones de chat seguras, hay una huella digital ("Números de seguridad" en Signal) que las dos partes pueden comparar fuera de banda. Lo importante es que si las dos partes derivan el mismo secreto, pueden estar seguros de que nadie más tiene acceso a él.
El intercambio de claves de Telegram se describe en la sección "Generación de claves" de los documentos de la API de extremo a extremo de Telegram. Concretamente, Alice solicita los parámetros DH (p, g) de Telegram, los verifica minuciosamente, calcula un valor aleatorio a y envía g^a mod p a Telegram. Bob recibe (p, g, g^a mod p), calcula de manera similar b y g^b mod p y envía este último de vuelta (junto con un hash truncado de la clave derivada, por alguna razón).
Ahora, normalmente las dos partes calcularían la clave compartida como (g^a)^b mod p y (g^b)^a mod p. En cambio, la versión original de MTProto la calculaba como
donde nonce era un valor arbitrario, supuestamente aleatorio, enviado por el servidor junto con la contribución pública del par.
Esta fue una adición completamente no estándar e inútil, y todo lo que hizo fue dejar que el servidor realizara un ataque de persona en el medio no detectado. Vamos a ver cómo.
En un PitM normal, el servidor negocia dos sesiones separadas de Diffie-Hellman con Alice y Bob, que terminan con diferentes claves compartidas, que podrían detectar comparando las huellas dactilares.
Sin embargo, con la adición de nonce, el servidor podría "arreglar" la clave de Alice para que coincida con la de Bob manipulando el nonce de Alice. Las dos partes terminarían con la misma huella digital, y no podrían decir que ocurrió un ataque, pero el servidor (y nadie más) conocería la clave compartida, lo que le permitiría descifrar todos los mensajes.
¿Por qué digo que esta adición fue inútil? ¡Porque literalmente no tenía ningún propósito! De hecho, la vulnerabilidad se solucionó eliminando silenciosamente el paso nonce de los documentos.[ 4] Una revisión posterior de la API eliminó el parámetro nonce con la leyenda "Mejorar los chats secretos". Toda la referencia original de la API que se dijo sobre el nonce es "Secuencia de servidor aleatorio para el cálculo de la clave".
Nunca escuché una explicación plausible de por qué los diseñadores de MTProto hicieron todo lo posible para agregar una complejidad inútil a su protocolo, con el único resultado de hacer posible la interceptación indetectable.
En Twitter dan algunas luces (mucho más abajo te dejo el tweet mencionado) a una declaración oficial de Telegram sobre esto que ya no pude encontrar. Afirma que el nonce estaba allí para proteger a los clientes con generadores de números aleatorios débiles. Esto es lo que había enterrado en una nota al pie cuando no pude encontrar una cita para atribuir esa explicación a Telegram:
Esto no tiene sentido por varias razones: 1) es probable que los clientes con aleatoriedad débil estén tostados de todos modos, porque el bizarro no-un-MAC de Telegram se basa en la aleatoriedad en la carga útil para evitar un oráculo de descifrado fuera de línea (hay un hash de texto plano de la carga útil en el cable, ¡te dije que esto era extraño!) ; 2) la API también permite a los clientes solicitar bytes aleatorios del servidor a XOR con su recurso compartido secreto; y 3) defenderse contra la aleatoriedad débil confiando en una contribución del servidor se defiende contra todo menos el servidor, que es el atacante relevante en la configuración de extremo a extremo. (Dicho de otra manera, cualquiera que pueda interceptar mensajes cliente-servidor puede ver la aleatoriedad adicional, lo que lo hace discutible). Los no practicantes podrían pensar que esta es una defensa razonable en profundidad, cinturones y tirantes, pero en la ingeniería criptográfica agregar complejidad para defenderse contra escenarios que conducen al compromiso de todos modos es simplemente inútil.
De todos modos, ha pasado un tiempo, el mundo es un lugar diferente ahora, y tal vez la navaja de afeitar de Hanlon corta más de lo que pensaba. Creo que hay mejores razones para no usar Telegram hoy que este viejo error, pero sigue siendo en lo que pienso cada vez que la gente habla de "bugdoors"; inverosímil. ¡El listón está alto!](https://pbs.twimg.com/media/GWFaaK7XoAAH4du.png)
Olivia
Online
Pablo
@ItzPira
Joined June 2015
294 Following
193 Followers
1K Posts
He must of been a fun guy to hang around with.
Viva el ingenio de la gente ❤️
This is the best use for of a drone I've ever seen 😭
Me despido hasta el mediodía.
No me canso de verlo, espero que Uds tampoco...
De cómo Telegram se rio del mundo (bueno, no había muchos usuarios en su momento, según leerás más adelante) con su cRiPtOgRaFíA. Si tuviste la mala suerte de activar los mensajes súper secretos súper cifrados con última tecnología y creías que estabas seguro, este artículo es para ti.
Recordando: "Esto era un bug, pero seamos sinceros, era simplemente una puerta trasera". No se hagan. NO SE HAGAN. “Los no practicantes podrían pensar que esta es una defensa razonable en profundidad, cinturones y tirantes, pero en la ingeniería criptográfica agregar complejidad para defenderse contra escenarios que conducen al compromiso de todos modos es simplemente inútil.”
Esta es la historia de un error que se descubrió y solucionó en el protocolo criptográfico creado por ellos mismos (¿qué pasó con aquel dicho que decía que no inventaras tu propia criptografía? Pues qué crees que pasó… Sí podía salir mal, pues salió bien mal) de Telegram hace unos diez años. El error no tuvo ninguna prensa, y nadie parece saberlo, probablemente porque solo se publicó en ruso (cuyo link a las mega salsas te voy a publicar en el tweet, mucho más abajo de este).
Hasta el día de hoy, es el bicho más visto como una puerta trasera que he visto (duda y acertarás, querido lector).
Telegram es una popular aplicación de chat que utiliza su propio... extraño protocolo para cifrar los chats, llamado MTProto. El protocolo se utiliza tanto para cifrar todos los mensajes al servidor de Telegram como para cifrar los "chats secretos" de extremo a extremo de opción 1:1. En texto, no puedo hacer justicia a las expresiones faciales de los criptógrafos cuando mencionas el protocolo de Telegram, así que créeme que es raro.
Aquí explico: Los mensajes directos no están cifrados de extremo a extremo de forma predeterminada. Los usuarios pueden habilitar lo que Telegram llama "chats secretos", pero deben hacerlo para cada conversación que deseen cifrar. Esta opción nunca está activada de forma predeterminada y no se puede activar para mensajes directos grupales ni canales. Ahora, si tuviste la mala suerte de activar los mensajes súper secretos súper cifrados con última tecnología y creías que estabas seguro, de eso va este artículo. Seguimos.
El consenso actual parece ser que la última versión no se rompe de manera conocida que sea lo suficientemente grave o relevante como para afectar a los usuarios finales, asumiendo que la implementación es correcta. Eso es casi tan seguro como dejar cables expuestos alrededor de su casa porque no están vivos o colocados lo suficientemente altos como para que nadie los toque.
Sin embargo, la versión original estaba completamente rota, de la manera más desconcertante.
Las sesiones de chat de Telegram de extremo a extremo utilizan Diffie-Hellman de campo finito para establecer una clave compartida entre los dos participantes. La negociación ocurre a través de mensajes transmitidos por el servidor de Telegram. Diffie-Hellman es un bloque de construcción fundamental de muchos criptosistemas, y permite a dos partes establecer un secreto compartido que ningún escucha no puede derivar. Sin embargo, es solo una parte de un intercambio de claves seguro, porque un atacante capaz de interceptar los mensajes podría simplemente establecer dos sesiones separadas con las dos partes, llevando a cabo un ataque de persona en el medio. Las partes necesitan alguna forma de verificar que derivaron el mismo secreto. En TLS, utilizan una firma de un certificado. En la mayoría de las aplicaciones de chat seguras, hay una huella digital ("Números de seguridad" en Signal) que las dos partes pueden comparar fuera de banda. Lo importante es que si las dos partes derivan el mismo secreto, pueden estar seguros de que nadie más tiene acceso a él.
El intercambio de claves de Telegram se describe en la sección "Generación de claves" de los documentos de la API de extremo a extremo de Telegram. Concretamente, Alice solicita los parámetros DH (p, g) de Telegram, los verifica minuciosamente, calcula un valor aleatorio a y envía g^a mod p a Telegram. Bob recibe (p, g, g^a mod p), calcula de manera similar b y g^b mod p y envía este último de vuelta (junto con un hash truncado de la clave derivada, por alguna razón).
Ahora, normalmente las dos partes calcularían la clave compartida como (g^a)^b mod p y (g^b)^a mod p. En cambio, la versión original de MTProto la calculaba como
donde nonce era un valor arbitrario, supuestamente aleatorio, enviado por el servidor junto con la contribución pública del par.
Esta fue una adición completamente no estándar e inútil, y todo lo que hizo fue dejar que el servidor realizara un ataque de persona en el medio no detectado. Vamos a ver cómo.
En un PitM normal, el servidor negocia dos sesiones separadas de Diffie-Hellman con Alice y Bob, que terminan con diferentes claves compartidas, que podrían detectar comparando las huellas dactilares.
Sin embargo, con la adición de nonce, el servidor podría "arreglar" la clave de Alice para que coincida con la de Bob manipulando el nonce de Alice. Las dos partes terminarían con la misma huella digital, y no podrían decir que ocurrió un ataque, pero el servidor (y nadie más) conocería la clave compartida, lo que le permitiría descifrar todos los mensajes.
¿Por qué digo que esta adición fue inútil? ¡Porque literalmente no tenía ningún propósito! De hecho, la vulnerabilidad se solucionó eliminando silenciosamente el paso nonce de los documentos.[ 4] Una revisión posterior de la API eliminó el parámetro nonce con la leyenda "Mejorar los chats secretos". Toda la referencia original de la API que se dijo sobre el nonce es "Secuencia de servidor aleatorio para el cálculo de la clave".
Nunca escuché una explicación plausible de por qué los diseñadores de MTProto hicieron todo lo posible para agregar una complejidad inútil a su protocolo, con el único resultado de hacer posible la interceptación indetectable.
En Twitter dan algunas luces (mucho más abajo te dejo el tweet mencionado) a una declaración oficial de Telegram sobre esto que ya no pude encontrar. Afirma que el nonce estaba allí para proteger a los clientes con generadores de números aleatorios débiles. Esto es lo que había enterrado en una nota al pie cuando no pude encontrar una cita para atribuir esa explicación a Telegram:
Esto no tiene sentido por varias razones: 1) es probable que los clientes con aleatoriedad débil estén tostados de todos modos, porque el bizarro no-un-MAC de Telegram se basa en la aleatoriedad en la carga útil para evitar un oráculo de descifrado fuera de línea (hay un hash de texto plano de la carga útil en el cable, ¡te dije que esto era extraño!) ; 2) la API también permite a los clientes solicitar bytes aleatorios del servidor a XOR con su recurso compartido secreto; y 3) defenderse contra la aleatoriedad débil confiando en una contribución del servidor se defiende contra todo menos el servidor, que es el atacante relevante en la configuración de extremo a extremo. (Dicho de otra manera, cualquiera que pueda interceptar mensajes cliente-servidor puede ver la aleatoriedad adicional, lo que lo hace discutible). Los no practicantes podrían pensar que esta es una defensa razonable en profundidad, cinturones y tirantes, pero en la ingeniería criptográfica agregar complejidad para defenderse contra escenarios que conducen al compromiso de todos modos es simplemente inútil.
De todos modos, ha pasado un tiempo, el mundo es un lugar diferente ahora, y tal vez la navaja de afeitar de Hanlon corta más de lo que pensaba. Creo que hay mejores razones para no usar Telegram hoy que este viejo error, pero sigue siendo en lo que pienso cada vez que la gente habla de "bugdoors"; inverosímil. ¡El listón está alto!
![BtcAndres's tweet photo. De cómo Telegram se rio del mundo (bueno, no había muchos usuarios en su momento, según leerás más adelante) con su cRiPtOgRaFíA. Si tuviste la mala suerte de activar los mensajes súper secretos súper cifrados con última tecnología y creías que estabas seguro, este artículo es para ti.
Recordando: "Esto era un bug, pero seamos sinceros, era simplemente una puerta trasera". No se hagan. NO SE HAGAN. “Los no practicantes podrían pensar que esta es una defensa razonable en profundidad, cinturones y tirantes, pero en la ingeniería criptográfica agregar complejidad para defenderse contra escenarios que conducen al compromiso de todos modos es simplemente inútil.”
Esta es la historia de un error que se descubrió y solucionó en el protocolo criptográfico creado por ellos mismos (¿qué pasó con aquel dicho que decía que no inventaras tu propia criptografía? Pues qué crees que pasó… Sí podía salir mal, pues salió bien mal) de Telegram hace unos diez años. El error no tuvo ninguna prensa, y nadie parece saberlo, probablemente porque solo se publicó en ruso (cuyo link a las mega salsas te voy a publicar en el tweet, mucho más abajo de este).
Hasta el día de hoy, es el bicho más visto como una puerta trasera que he visto (duda y acertarás, querido lector).
Telegram es una popular aplicación de chat que utiliza su propio... extraño protocolo para cifrar los chats, llamado MTProto. El protocolo se utiliza tanto para cifrar todos los mensajes al servidor de Telegram como para cifrar los "chats secretos" de extremo a extremo de opción 1:1. En texto, no puedo hacer justicia a las expresiones faciales de los criptógrafos cuando mencionas el protocolo de Telegram, así que créeme que es raro.
Aquí explico: Los mensajes directos no están cifrados de extremo a extremo de forma predeterminada. Los usuarios pueden habilitar lo que Telegram llama "chats secretos", pero deben hacerlo para cada conversación que deseen cifrar. Esta opción nunca está activada de forma predeterminada y no se puede activar para mensajes directos grupales ni canales. Ahora, si tuviste la mala suerte de activar los mensajes súper secretos súper cifrados con última tecnología y creías que estabas seguro, de eso va este artículo. Seguimos.
El consenso actual parece ser que la última versión no se rompe de manera conocida que sea lo suficientemente grave o relevante como para afectar a los usuarios finales, asumiendo que la implementación es correcta. Eso es casi tan seguro como dejar cables expuestos alrededor de su casa porque no están vivos o colocados lo suficientemente altos como para que nadie los toque.
Sin embargo, la versión original estaba completamente rota, de la manera más desconcertante.
Las sesiones de chat de Telegram de extremo a extremo utilizan Diffie-Hellman de campo finito para establecer una clave compartida entre los dos participantes. La negociación ocurre a través de mensajes transmitidos por el servidor de Telegram. Diffie-Hellman es un bloque de construcción fundamental de muchos criptosistemas, y permite a dos partes establecer un secreto compartido que ningún escucha no puede derivar. Sin embargo, es solo una parte de un intercambio de claves seguro, porque un atacante capaz de interceptar los mensajes podría simplemente establecer dos sesiones separadas con las dos partes, llevando a cabo un ataque de persona en el medio. Las partes necesitan alguna forma de verificar que derivaron el mismo secreto. En TLS, utilizan una firma de un certificado. En la mayoría de las aplicaciones de chat seguras, hay una huella digital ("Números de seguridad" en Signal) que las dos partes pueden comparar fuera de banda. Lo importante es que si las dos partes derivan el mismo secreto, pueden estar seguros de que nadie más tiene acceso a él.
El intercambio de claves de Telegram se describe en la sección "Generación de claves" de los documentos de la API de extremo a extremo de Telegram. Concretamente, Alice solicita los parámetros DH (p, g) de Telegram, los verifica minuciosamente, calcula un valor aleatorio a y envía g^a mod p a Telegram. Bob recibe (p, g, g^a mod p), calcula de manera similar b y g^b mod p y envía este último de vuelta (junto con un hash truncado de la clave derivada, por alguna razón).
Ahora, normalmente las dos partes calcularían la clave compartida como (g^a)^b mod p y (g^b)^a mod p. En cambio, la versión original de MTProto la calculaba como
donde nonce era un valor arbitrario, supuestamente aleatorio, enviado por el servidor junto con la contribución pública del par.
Esta fue una adición completamente no estándar e inútil, y todo lo que hizo fue dejar que el servidor realizara un ataque de persona en el medio no detectado. Vamos a ver cómo.
En un PitM normal, el servidor negocia dos sesiones separadas de Diffie-Hellman con Alice y Bob, que terminan con diferentes claves compartidas, que podrían detectar comparando las huellas dactilares.
Sin embargo, con la adición de nonce, el servidor podría "arreglar" la clave de Alice para que coincida con la de Bob manipulando el nonce de Alice. Las dos partes terminarían con la misma huella digital, y no podrían decir que ocurrió un ataque, pero el servidor (y nadie más) conocería la clave compartida, lo que le permitiría descifrar todos los mensajes.
¿Por qué digo que esta adición fue inútil? ¡Porque literalmente no tenía ningún propósito! De hecho, la vulnerabilidad se solucionó eliminando silenciosamente el paso nonce de los documentos.[ 4] Una revisión posterior de la API eliminó el parámetro nonce con la leyenda "Mejorar los chats secretos". Toda la referencia original de la API que se dijo sobre el nonce es "Secuencia de servidor aleatorio para el cálculo de la clave".
Nunca escuché una explicación plausible de por qué los diseñadores de MTProto hicieron todo lo posible para agregar una complejidad inútil a su protocolo, con el único resultado de hacer posible la interceptación indetectable.
En Twitter dan algunas luces (mucho más abajo te dejo el tweet mencionado) a una declaración oficial de Telegram sobre esto que ya no pude encontrar. Afirma que el nonce estaba allí para proteger a los clientes con generadores de números aleatorios débiles. Esto es lo que había enterrado en una nota al pie cuando no pude encontrar una cita para atribuir esa explicación a Telegram:
Esto no tiene sentido por varias razones: 1) es probable que los clientes con aleatoriedad débil estén tostados de todos modos, porque el bizarro no-un-MAC de Telegram se basa en la aleatoriedad en la carga útil para evitar un oráculo de descifrado fuera de línea (hay un hash de texto plano de la carga útil en el cable, ¡te dije que esto era extraño!) ; 2) la API también permite a los clientes solicitar bytes aleatorios del servidor a XOR con su recurso compartido secreto; y 3) defenderse contra la aleatoriedad débil confiando en una contribución del servidor se defiende contra todo menos el servidor, que es el atacante relevante en la configuración de extremo a extremo. (Dicho de otra manera, cualquiera que pueda interceptar mensajes cliente-servidor puede ver la aleatoriedad adicional, lo que lo hace discutible). Los no practicantes podrían pensar que esta es una defensa razonable en profundidad, cinturones y tirantes, pero en la ingeniería criptográfica agregar complejidad para defenderse contra escenarios que conducen al compromiso de todos modos es simplemente inútil.
De todos modos, ha pasado un tiempo, el mundo es un lugar diferente ahora, y tal vez la navaja de afeitar de Hanlon corta más de lo que pensaba. Creo que hay mejores razones para no usar Telegram hoy que este viejo error, pero sigue siendo en lo que pienso cada vez que la gente habla de "bugdoors"; inverosímil. ¡El listón está alto!](https://pbs.twimg.com/media/GWFavjsW4AAeOF1.png)
Un profesor de física
Un bar en Los Ángeles ofrece una manera distinta para ver los partidos. Sí, hay una pantalla gigante que simula estar sentado en el medio de la tribuna. Increíble.
Monkey’s fist knot
Making a secret door
https://t.co/pyr2FU2VAY
What a time to be alive. https://t.co/FjU4QQu3Bv
Filosofía de vida … 👏👏👏
This is why dad's are extremely necessary
This looks so beautiful to watch 😂😂
Watch people play ‘Pong’ on a rock wall with Augmented Climbing
He is wow!
COMUNICADO URGENTE:
Orden de detención ilegal contra mí y oleada de mentiras en todos los medios.
No vais a conseguir amordazarme jamás.
Para los que dicen que #bitcoin no se vende, en parte estoy de acuerdo, pero por favor mira este video antes de decir que “no se vende nunca” luego escribe tu opinión.
Mori de risa con esta nena y su abuela. 😆
El mejor cover que he visto neta.
Tenemos a la peor ministra en el peor momento.
Me examiné de Selectividad en 1982. El examen era a las nueve de la mañana. La noche antes, cenando, mi padre me dijo:
-Nene, mañana te juegas tu futuro. Pero no vayas a llamarme para despedirte, que no son horas de molestar y tu madre estará levantada desde antes del alba.
👇
Last Seen Users on Sotwe
DERYA İLE RESİM PAYLAŞIM
Seen from Italy
X sudan
Seen from Germany
Ronald Reis
Seen from Brazil
50+ชอบหีใหญ่ๆหมอยเยอะๆชอบเลียหี
Seen from Thailand
18+
Seen from Turkey
GinetteKal
Seen from United States
@Mascaradotadusp 
KING
Seen from Jordan
BACKSHOTS PARADISE 👅🍑🍆
Seen from India
DijitalOrtam
Seen from Turkey
Trends for you
Most Popular Users
Elon Musk
@elonmusk
241.7M followers
Barack Obama
@barackobama
119M followers
Cristiano Ronaldo
@cristiano
114.5M followers
Donald J. Trump
@realdonaldtrump
111.9M followers
Narendra Modi
@narendramodi
107.2M followers
Rihanna
@rihanna
98.7M followers
NASA
@nasa
92.4M followers
Justin Bieber
@justinbieber
91.8M followers
KATY PERRY
@katyperry
90M followers
Taylor Swift
@taylorswift13
84M followers
Lady Gaga
@ladygaga
75.4M followers
Virat Kohli
@imvkohli
73.4M followers
Kim Kardashian
@kimkardashian
70.9M followers
YouTube
@youtube
68.8M followers
Neymar Jr
@neymarjr
66.4M followers
Bill Gates
@billgates
65.2M followers
Selena Gomez
@selenagomez
63.1M followers
The Ellen Show
@theellenshow
62.3M followers
CNN
@cnn
61.8M followers
X
@x
60.7M followers