En cualquier texto de seguridad informática que miremos por ahí leeremos el consejo de ‘no desarrollar nuestra propia criptografía’. En So you want to roll your own crypto? hay ideas interesantes sobre el tema.

Parte de una pregunta que no es despreciable: ¿cómo vamos a aprender (de nuestros errores) si no podemos hacer nuestra propia criptografía?

How are people supposed to learn (from mistakes) if they don’t roll their own crypto?

Y la respuesta también es secncilla: hazlo, pero no utilices lo que hagas en producción.

The short answer is do roll your own crypto, but don’t use it in production until it’s vetted by professionals. The long answer below might take a few years to hash out.

Equivocarse es un proceso inevitable para conseguir aprender (y aquí hablamos en sentido amplio) aunque también podemos aprender de los errores de otros. Cursos, retos, …

I found that the cheapest way to learn from mistakes is to learn from other people’s mistakes. I recommend taking Cryptography I, doing CTFs, and solving crypto challenges. This won’t take long, and very quickly you’d be pretty dangerous because you’d be able to find many crypto bugs.

Sin embargo, todo esto puede ser insuficiente. Leer código es una buena forma de aprender, pero en criptografía esto no es tan sencillo. El código no es obvio, tiene detalles sutiles y la mala criptografía produce muchas veces resultados indistinguibles de la buena.

They say you can become a better programmer by reading good code. Unfortunately, I’ve learned the hard way that this rule usually does not work in crypto, …

Tampoco hay un buen sustituto de aprender los fundamentos. Sin embargo, después de conocerlos a lo mejor tampoco es un buen momento para desarrollar nuevos sistemas criptográficos, porque el campo es amplio y cada una de sus partes tiene sus propias características.

The funny thing is that after spending years studying these resources, you still don’t have a free pass to roll all the crypto in the world. You’d realize and appreciate that crypto is a deep and vast field of study with a very long food chain. Sitting on top are cryptanalysts who…

Y tampoco hay que olvidar las interacciones entre ellas. Esto significa que incluso utilizando los protocolos desarrollados por otros nos podemos equivocar (y lo haremos).

Así que la conclusión es que deberemos estar seguros de que comprendemos bien lo que tenemos entre manos, y estudiar para eliminar nuestras limitaciones.

So if you want to roll your own crypto, make sure you understand where you are in the crypto food chain and what are the reasons preventing you from moving up. Study and eliminate said reasons. Good luck and have fun!

El correo electrónico es una de las aplicaciones más viejas de internet. Además es una de las pocas que se ha mantenido verdaderamente descentralizada: es cierto que hay una cierta tendencia al uso de los proveedores habituales, pero sigue habiendo muchos servidores de correo ‘independientes’ y con los que todo el mundo tiene que poder interactuar.

Esto provoca que haya algunos problemas de seguridad (y el spam, claro). En Decades-Old Email Flaws Could Let Attackers Mask Their Identities hablan del tema, centrándose en algunos de los sistemas que se han añadido para hacer que el correo sea más seguro y confiable. En particular, el marco de política de envíos, el correo identificado mediante claves de dominios y la autentificación basada en dominios.

The study looked at the big three protocols used in email sender authentication—Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM), and Domain-Based Message Authentication, Reporting and Conformance (DMARC)—and found 18 instances of what the researchers call “evasion exploits.”

Nos dicen que el problema no está en los protocolos, sino en cómo los implantan diferentes servicios.

The vulnerabilities don’t stem from the protocols themselves but from how different email services and client applications implement them. Attackers could use these loopholes to make spear-phishing attacks even harder to detect.

Hay ataques dentro del servidor, basados en inconsistencias sobre como un servicio obtiene los datos de las cabeceras para autentificar a un usuario.

The first set, called “intra-server” attacks, prey on inconsistencies in how a given email service pulls data from headers to authenticate a sender.

El segundo se basa en manipular inconsistencias similares, pero entre el servidor que recibe el mensaje y la aplicación que usamos para leerlo.

The second category focuses on manipulating similar inconsistencies, but between the mail server that receives your message and the app that actually displays it to you.

Finalmente, las ‘respuestas ambiguas’ por problemas en cómo se manejan algunas cabeceras de autentificación.

The researchers call the third category “ambiguous replay,” because it includes different methods of hijacking and repurposing (or replaying) a legitimate email an attacker has received. These attacks take advantage of a known quality of the cryptographic authentication mechanism DKIM where you can receive an email that has already been authenticated, craft a new message where all of the headers and the body are the same as they were in the original email, and essentially resend it, preserving its authentication.

Todos estos problemas abren la puerta a poder enviar sin demasiados problemas toda clase de basura, en muchos casos porque los proveedores se mueven buscando la compatibilidad, más que el rigor. Sin darse cuenta de la existencia de esos casos límite, que serán explotados por alguien para seguir abusando de los sistemas de correo.

En seguridad informática suele hablarse de aletoriedad, aunque en los sitios habituales de divulgación no tanto. Por eso vamos recopilando aquí todas las noticias que encontramos sobre el tema que llaman nuestra atención. Con las teorías pasa lo mismo, solo hablamos de las que nos gustan, y el resto del tiempo las teorías son cosas molestas que nos llevan lejos del ‘mundo real’.

Hoy traemos Randomness theory could hold key to internet security

Se habla de criptografía, un esquema común de cifrado que se basa en la descomposición de números en factores primos y la creencia de que no existen métodoso eficientes para realizar esta descomposición.

It is believed that no efficient factoring algorithm exists for large numbers, Pass said, though researchers may not have found the right algorithms yet.

También se habla de la complejidad de Kolmogorov que permite medir la cantidad de aleatoriedad que incluye una cadena de números. La definición mide esa complejidad por el tamaño del programa más corto que puede generar la cadena.

Meanwhile, mathematicians in the 1960s identified what’s known as Kolmogorov Complexity, which refers to quantifying the amount of randomness or pattern of a string of numbers. The Kolmogorov Complexity of a string of numbers is defined as the length of the shortest computer program that can generate the string;

Para aligerar el problema (ese programa podría ser muy costoso) se introdujo el concepto de complejidad de Kolmogorov acotada en tiempo. Esto es, la longitud de un programa que puede generar la secuencia en una cierta cantidad de tiempo.

… researchers in the Soviet Union in the 1960s, as well as Hartmanis and others in the 1980s, developed the time-bounded Kolmogorov Complexity – the length of the shortest program that can output a string of numbers in a certain amount of time.

Las consecuencias de estos trabajos son que si pudiéramos encontrar un programa para resolver el problema de la complejidad de Kolmogorov acotada en tiempo para un número significativo de situaciones, podríamos romper todos los sistemas criptográficos. Si no, podemos estar seguros de que podemos encontrar buenas funciones de cifrado que sean seguras.

“If you can come up with an efficient algorithm to solve the time-bounded Kolmogorov complexity problem for a large fraction of things, then you can break all crypto, all encryption schemes, all digital signatures,” Pass said. “However, if no efficient algorithm exists to solve this problem, you can get a one-way function, and therefore you can get secure encryption and digital signatures and so forth.”

Y eso son cosas que hay que saber.

En seguridad informática los ataques pueden venir de las formas más insospechadas (incluso aunque estemos atentos). En este caso traigo Some email clients are vulnerable to attacks via ‘mailto’ links donde nos cuentan un fallo utilizando enlaces del tipo 'mailto' (esos enlaces, como sabemos, abren el cliente de correo con un destinatario preconfigurado).

Mailto refer to special types of links, usually supported by web browsers or email clients. These are links that, when clicked, they open a new email compose/reply window rather than a new web page (website).

Como suele suceder, el estándar permite un montón de opciones, algunas incluso desaconsejadas por el mismo.

However, even the standard itself warns software engineers against supporting all parameters, recommending that apps only support a few “safe” options.

Uno de ellos es el de añadir adjuntos ('attach') que permiten que el destinatario esté precargado y, además, que el correo ya contenga un fichero adjunto.

In particular, researchers looked at the mailto “attach” or “attachment” parameters that allow mailto links to open new email compose/reply windows with a file already attached.

Y, claro, como siempre decimos en las charlas divulgativas, lo que es fácil y rápido se consigue que de manera fácil y rápida alguien pueda fastidiarnos (por ejemplo, añadiendo nuestro fichero de claves, algún fichero de configuración….)

If the user composing the email does not spot the file attachment, attackers could receive sensitive files from the user’s system, such as encryption (PGP) keys, SSH keys, config files, cryptocurrency wallet files, password stores, or important business documents – as long as they’re stored at file paths known by an attacker.

También hablan de otro fallos de seguridad destinados a evitar las tecnologías de cifrado como, sustituir las claves, guardar información sensible en texto plano en sitios controlados por el atacante y divulgar las claves.

Cuidado.

No siempre podemos elegir la tecnología que utilizamos o la que tenemos que gestionar. En Security analysis of legacy programming environments reveals critical flaws lo enmarcarn en el tema de la Industria 4.0, donde este caso puede ser frecuete y ofrecen recomendaciones.

We don’t want to simply point out these challenges, but once again take the lead in securing Industry 4.0 by offering concrete guidance for design, coding, verification, and on-going maintenance, along with tools to scan and block malicious and vulnerable code.”

La lista incluye: tratar la maquinaria como si fueran computadoras, autentificar las comunicaciones (cada comunicación), implantar políticas de control de acceso, realizar validación de los datos de entrada, sanear los datos, gestionar adecuadamente los errores (sin exponer detalles que pueden ser delicados) y, claro, desarrollar y practicar protocolos de configuración y despliegue adecuados.

The essential checklist for writing secure task programs includes the following:

Treat industrial machines as computers and task programs as powerful code

Authenticate every communication

Implement access control policies

Always perform input validation

Always perform output sanitization

Implement proper error handling without exposing details

Put proper configuration and deployment procedures in places

Nada muy nuevo para cualquier persona interesada en la seguridad, pero vale la pena recordarlo.