Hoy una entrada ligera y que no va a llamar la atención de nadie que venga por aquí habitualmente, salvo por la visualización. En Most Common Passwords justamente eso.

Para ver, jugar, y -tal vez- concienciarnos un poco más.

El diablo está en los detalles y la realidad se empeña en mostrárnoslo (poco a poco, eso sí) continuamente. En este caso, The definitive guide to “Modulo Bias and how to avoid it”! habla de lo que llaman sesgo del módulo (modulo bias), y sus consecuencias.

Como sabemos, nos dice, las operaciones modulares se utilizan ampliamente en criptografía, y también en informática en general.

The modulo operation is used a lot in Cryptography, since we are usually dealing with number theory and algebraic structures that rely on the modulo operation at their core. But it is also used more broadly in Computer Science. It is typically represented in code by the symbol % and it is a binary operator that will take two integers as input and give one integer as output.

Pero el sesgo aparece cuando elegimos un número aleatorio y queremos obtener valores en un determinado rango. La causa es que típicamente utilizaremos un generador que proporciona números en otro rango diferente, y nosotros haremos la conversión. Pero si la cantidad de números de uno y otro rango no son compatibles (la grande es múltiplo de la pequeña), nos vamos a llevar un disgusto si medimos las frecuencias de los números generados: los primeros (el exceso de ese múltiplo) va a estar ligeramente sobre-representados.

The problem is basically the same as when you’re cutting a rope into smaller pieces of a given size: the last piece will most likely not be of the same size as the others, except if the initial length of your rope was perfectly divided by the length of the pieces.

No parece un problema muy grave, nos dice, pero quién sabe por dónde pueden evolucionar las técnicas de criptoanálisis.

It is true in general that biases are “just” reducing the actual entropy of a randomly generated value and thus are not as dangerous as for the above schemes, but future cryptanalytic breakthroughs might exploit them. As such we definitively prefer to have uniformly distributed random values, plus they also usually allow us to really rely on the mathematical proofs of security, when we have one.

¿Se puede remediar?

Existen varias formas, la primera sería descartar los valores que no pertenecen a nuestro rango a la hora de obtener números aleatorios.

Rejection sampling consists in sampling a random value and rejecting all values that do not fall into the right range.

El problema de este método es que si la diferencia entre rangos es muy grande podemos añadir un coste extra a la obtención de valores. Se puede aliviar un poco truncando el número al tamaño adecuado, pero no resuelve el problema completamente.

Otra posibilidad es seguir usando el módulo, pero teniendo en cuenta las limitaciones señaladas: esencialmente se puede utilizar el módulo para un conjunto de valores ‘equilibrado’; esto es, los números del final, que son los que nos provocarían las desigualdades pueden ser rechazados cuando salgan y calcular el módulo para el resto.

As we discussed earlier, if you are generating a value between 0 and 106, using one byte of randomness, then you can combine both rejection sampling and modulo reduction

Siguen pudiendo aparecer problemas, sobre todo si el exceso de números con respecto a la operación modular es grande.

Me gustó mucho leerlo, y no era consciente del problema, la verdad.

Esta es una batalla perdida: yo mismo utilizo clientes de correo que lo interpretan y envío mensajes en HTML. Sin embargo, es bueno recordarlo, y de vez en cuando alguien lo hace. En Kobold letters. Why HTML emails are a risk to your organization nos recordaban algunos aspectos relevantes.

Es un problema desde el punto de vista técnico, tanto de interpretación del mensaje, como desde el punto de vista de la seguridad, nos dice:

Anyone who has had to deal with HTML emails on a technical level has probably reached the point where they wanted to quit their job or just set fire to all the mail clients due to their inconsistent implementations. But HTML emails are not just a source of frustration, they can also be a serious security risk.

En esta caso hablan de las llamadas Kobold letters que, esencialmente, tienen diferente aspecto cuando se reciben por primera vez; y cambian cuando son reenvíadas (forward).

The email your manager received and forwarded to you was something completely innocent, such as a potential customer asking a few questions. All that email was supposed to achieve was being forwarded to you. However, the moment the email appeared in your inbox, it changed.

Esto se debe a la posibilidad de utilizar las hojas de estilo en cascada (CSS) y los cambios que se producen al reenviar un mensaje, que permiten activar reglas diferentes, que muestran alguna parte del mensaje que el receptor original no podía ver.

This attack is possible because most email clients allow CSS to be used to style HTML emails. When an email is forwarded, the position of the original email in the DOM usually changes, allowing for CSS rules to be selectively applied only when an email has been forwarded.

Desde el punto de vista del usuario no hay mucho que podamos hacer (algunos clientes permiten ver HTML básico, sin estilo, o podemos desactivarlo completamente, pero entonces habrá correos que no podremos leer completamente). Según nos cuentan en la historia, los diversos clientes toman medidas contra esto, dentro de sus posibilidades.

El protocolo HTTP (Hypertext Transfer Protocol) es el que proporciona las bases fundamentales para la web. A mi me parece bastante interesante saber cómo funciona (aunque sea a nivel generalista) para comprender un poco mejor la web y por eso me gustó leer HTTP/2 and HTTP/3 explained.

Conviene recordar que la web, tal y como la conocemos se basa en un lenguaje para escribir documentos (HTML), un protocolo de transmisión (HTTP) y en una arquitectura cliente (el navegador) servidor (el que nos proporciona la información cuando nos conectamos).

El protocolo ha pasado por varias versiones, desde la HTTP/0.9, que fue el primer borrador hasta el más moderno, la versión 3 del protocolo (que apareció en 2012) que todavía no es de uso mayoritario (ver, por ejemplo, el dato de Examining HTTP/3 usage one year on, que tiene datos del año pasado).

Hacia el final nos recuerdan que HTTP/3 nació para dar mejor servicio a las conexiones menos estables, como los teléfonos móviles.

HTTP/3 was designed for unstable connections, such as cellphone and satellite networks. To counter network instabilities, QUIC has a great degree of independence between the data streams and good resilience if packets are lost.

Así como las mejores prestaciones de la versión 2 del protocolo cuando las conexiones son estables.

On reliable and stable connections, HTTP/2 many times offers better performance than HTTP/3.

Hace unos meses podíamos leer Staying ahead of threat actors in the age of AI que me gustó porque nos da algunas pistas de algunos de los aspectos peligrosos de la inteligencia artificial, desde el punto de vista de la seguridad informática.

Proporcionan una lista de diversas organizaciones que aparecen frecuentemente en diversos ataques y los usos que han observado de la inteligencia artificial para estos fines. No entraremos en esos detalles (aunque puede ser interesante echar un ojo) sino que nos centraremos en el final del artículo, donde se hace un resumen.

• Reconocimiento (LLM-informed reconnaissance): esto es, obtener información sobre tecnologías y vulnerabilidades.
• Mejora de los programas (LLM-enhanced scripting techniques): se pueden utilizar los modelos de lenguaje grandes para generar programas o mejorar los que ya tenemos.
• Desarrollo asistido de programas (LLM-aided development:): parecido al anterior, pero ya integrado en el ciclo de vida de nuestros desarrollos.
• Ingeniería social mejorada (LLM-supported social engineering): se puede usar para mejorar las traducciones y los mensajes que se utilizan para manipular a los objetivos.
• Investigación de vulnerabilidades asistida (LLM-assisted vulnerability research): utilizar estos sistemas para comprender mejor las vulnerabilidades en los programas y en los sistemas.
• Optimización del desarrollo de payloads (LLM-optimized payload crafting): seguimos con ideas parecidas, cuando necesitamos generar o mejorar algún trozo de código que utilizaremos en un ataque.
• Evasión mejorada de los sistemas de detección de anomalías (LLM-enhanced anomaly detection evasion): ayuda para tratar de hacer pasar nuestros ataques dentro de la actividad normal de nuestro objetivo.
• Saltar las características de seguridad (LLM-directed security feature bypass): ayuda en la búsqueda de formas de evitar los mecanismos de seguridad (doble factor, CAPTCHAS, …)
• Recomendaciones en el desarrollo de recursos (LLM-advised resource development:): no sólo desarrollo de herramientas, sino también modificación e incluso planificación estratégica.

Interesante.