El proyecto OpenSSL ha lanzado la versión 3.5.0, una actualización destacada de su popular biblioteca criptográfica de código abierto, ampliamente utilizada para garantizar la seguridad en la transmisión de datos en aplicaciones y sitios web. Esta versión no solamente representa un paso adelante en ciberseguridad, sino también un movimiento estratégico para hacer frente a los desafíos que plantea la computación cuántica.

Publicada el 8 de abril de 2025, OpenSSL 3.5.0 trae consigo innovaciones clave como soporte para criptografía poscuántica, implementación del protocolo QUIC del lado servidor y ajustes importantes en configuraciones TLS, lo que convierte a esta versión en una de las más significativas en años recientes.

OpenSSL 3.5 presenta avances en criptografía poscuántica (PQC)

OpenSSL 3.5.0 estrena compatibilidad con algoritmos criptográficos diseñados para resistir ataques de futuros ordenadores cuánticos, alineándose con los estándares propuestos por el NIST (Instituto Nacional de Estándares y Tecnología de EE.UU.). Se han incorporado tres algoritmos fundamentales:

• ML-KEM (antes conocido como CRYSTALS-Kyber) para el intercambio de claves.
• ML-DSA (antes CRYSTALS-Dilithium), un algoritmo robusto de firma digital.
• SLH-DSA, basado en SPHINCS+, que ofrece una alternativa segura y sin estado a otras firmas digitales.

Estos métodos fueron aprobados como estándares FIPS (203, 204 y 205) en 2024 tras un extenso proceso de evaluación iniciado en 2016, en el que participaron varios expertos internacionales, incluidos investigadores alemanes. Para conocer más sobre los estándares de ciberseguridad, puedes consultar el impacto de Wolfsbane en la ciberseguridad moderna.

Soporte completo para QUIC del lado del servidor

Otra de las novedades destacadas es la integración de soporte para QUIC (Quick UDP Internet Connections) como servidor, de acuerdo al RFC 9000. Este protocolo de nueva generación, que promete conexiones más rápidas y seguras que TCP, ahora está completamente disponible en OpenSSL. Además:

• Se admite la compatibilidad con pilas externas de QUIC, ampliando las posibilidades de implementación.
• Se incorpora soporte para conexiones 0-RTT, lo que permite establecer comunicaciones sin necesidad de varios intercambios iniciales, agilizando notablemente el proceso.

Cambios en parámetros predeterminados y de seguridad

La versión 3.5.0 también redefine elementos que afectan al comportamiento por defecto de la biblioteca, lo que podría requerir ajustes por parte de los desarrolladores:

• El cifrado por defecto para las aplicaciones req, cms y smime ahora es aes-256-cbc, reemplazando al ya obsoleto des-ede3-cbc.
• Se ajusta la lista de grupos soportados en TLS para priorizar KEM híbridos poscuánticos, eliminando aquellos grupos con escasa o nula utilización.
• Los grupos de keyshares en TLS se han modificado; ahora se ofrecen X25519MLKEM768 junto con X25519 por defecto, fortaleciendo el intercambio de claves.
• Se deprecaron todas las funciones BIO_meth_get_*(), en un paso hacia la modernización de la API BIO.

Opciones de configuración y nuevas capacidades en OpenSSL 3.5

OpenSSL 3.5 incluye nuevas opciones que permiten un mayor control sobre el comportamiento de la biblioteca, especialmente en entornos regulados o donde la seguridad es crítica:

• no-tls-deprecated-ec: desactiva el soporte para curvas elípticas obsoletas definidas en el RFC 8422.
• enable-fips-jitter: permite al proveedor FIPS utilizar una fuente de entropía JITTER, mejorando la aleatoriedad en la generación de claves.
• Introducción de EVP_SKEY: permite manejar claves simétricas opacas, lo que incrementa la seguridad al abstraer el acceso directo a las claves.
• Soporte para generación de claves centralizadas en CMP, facilitando la gestión de certificados.
• Implementación de compatibilidad API para canalización en algoritmos de cifrado, optimizando operaciones criptográficas.

Errores conocidos y próximos pasos

Actualmente se ha identificado un error relacionado con la función SSL_accept cuando se utiliza sobre objetos retornados de SSL_accept_connection. En lugar de avanzar el handshake, como se espera, no tiene efecto. Los desarrolladores recomiendan utilizar SSL_do_handshake como solución temporal mientras se trabaja en una corrección que se espera para la versión 3.5.1.

Se ha confirmado que OpenSSL 3.5 es una versión LTS (Long-Term Support), con soporte garantizado hasta abril de 2030. La siguiente versión (3.6) ya está prevista para octubre de 2025.

Esta evolución de OpenSSL pone de relieve el esfuerzo continuado de la comunidad por garantizar una infraestructura segura de cara al futuro. Incorporar algoritmos resistentes a la computación cuántica, mejorar protocolos modernos como QUIC y modernizar configuraciones predeterminadas son señales claras de un compromiso con la adaptabilidad y la seguridad en un mundo digital cada vez más cambiante.

from Linux Adictos https://ift.tt/PY9FbBu
via IFTTT

En su día me resistí, pero al final caí y me hice con una Steam Deck. Si me lo pensé tanto fue porque en un principio pensaba que sólo jugaría con ella — o con él, pues es un ordenador –, pero para nada. Con el tiempo se ha convertido en mi centro multimedia, y esta última semana me ha permitido seguir trabajando cuando mi portátil principal ha sufrido un percance: el cargador ha dicho basta.

El problema fue uno de esos que mosquean: el cable de carga de mi ACER es fino, y en parte por no tener cuidado de más y en parte por esa finura, se fue pelando por un punto. El fin de semana pasado empezó a hacer ruido de chasquidos, un mal contacto que impedía la carga. En un principio no era imposible cargarlo, pero sí sin dejar el portátil totalmente parado. El más mínimo movimiento hacía que sonaran las chispas, y no merece la pena usar algo así. Además, poco después dejó de cargar por completo.

Opciones que tenía

Las opciones que tuve desde que pedí un cable de carga hasta que me llegó eran estas:

• No hacer nada, con lo que mi mensualidad se vería afectada.
• Usar la Rasbperry Pi 4. Era una posibilidad, pero es demasiado lenta para mi gusto.
• Usar el viejo portátil. Otra posibilidad, casi mejor que la Raspbery Pi, pero su pantalla tampoco hace buen contacto — ya sé que estaréis pensando que soy un manazas, y a veces sí lo soy. Y para usarla en mi tele, mejor otra cosa.

Steam Deck al rescate

Al final opté por usar la Steam Deck en un dock. Sólo tuve que mover una pequeña mesa para tener la pantalla más de frente. El resto fue coser y cantar. Además, gano potencia, que parece que no sea muy necesaria pero nunca está de mas.

No lo necesito en mi día a día, por lo que no tenía Vivaldi en la Steam Deck. Lo instalé para poder usar bien la pantalla dividida y le añadí algunos paneles, como el de Inoreader y X. La potencia de la Steam Deck me hizo no echar nada en falta, o casi: la mayor parte del tiempo que escribo para blogs lo hago desde un sofá. Para trabajar en la Steam Deck tengo que hacerlo en un escritorio improvisado.

Y es que la Steam Deck es en realidad «un ordenador que sirve para jugar en cualquier parte», pero también para todo lo demás. Gracias a ella he podido seguir trabajando y cada día me gusta más el bichejo.

from Linux Adictos https://ift.tt/NJpHAus
via IFTTT