OpenSSL 3.1.0 ya fue liberado y estas son sus novedades

OpenSSL

Openssl es una api que proporciona un entorno adecuado para encriptar los datos enviados

Después de un año y medio de desarrollo y diversas versiones correctivas en la versión anterior, se dio a conocer el lanzamiento de la nueva versión de la biblioteca “OpenSSL 3.1.0” con la implementación de los protocolos SSL/TLS y varios algoritmos de encriptación.

El soporte para esta nueva versión de OpenSSL 3.1 continuará hasta marzo de 2025, mientras que la compatibilidad con las versiones heredadas de OpenSSL 3.0 y 1.1.1 continuará hasta septiembre de 2026 y septiembre de 2023, respectivamente.

Para quienes desconocen de OpenSSL deben saber que este es un proyecto de software libre basado en SSLeay, el cual consiste en un robusto paquete de herramientas de administración y bibliotecas relacionadas con la criptografía, que suministran funciones criptográficas a otros paquetes como OpenSSH y navegadores web (para acceso seguro a sitios HTTPS).

Estas herramientas ayudan al sistema a implementar el Secure Sockets Layer (SSL), así como otros protocolos relacionados con la seguridad, como el Transport Layer Security (TLS). OpenSSL también permite crear certificados digitales que pueden aplicarse a un servidor, por ejemplo Apache.

OpenSSL se emplea en la validación cifrada de clientes de correo, transacciones basadas en web para pagos con tarjetas de crédito y en muchos casos en sistemas que requieran seguridad para la información que se expondrá en la red “datos confidenciales”.

Principales novedades de OpenSSL 3.1.0

En esta nueva versión que se presenta de OpenSSL 3.1.0, se destaca que el módulo FIPS implementa soporte para algoritmos criptográficos que cumplen con el estándar de seguridad FIPS 140-3, ademas de que se ha iniciado el proceso de certificación de módulos para obtener la certificación de cumplimiento FIPS 140-3.

Se menciona que hasta que se complete la certificación después de actualizar OpenSSL a la rama 3.1, los usuarios pueden continuar usando un módulo FIPS certificado para FIPS 140-2. De los cambios en la nueva versión del módulo, se destaca la inclusión de los algoritmos Triple DES ECB, Triple DES CBC y EdDSA, que aún no han sido probados para el cumplimiento de los requisitos de FIPS. También en la nueva versión, se han realizado optimizaciones para mejorar el rendimiento y se ha hecho una transición para ejecutar pruebas internas con cada carga de módulo, y no solo después de la instalación.

Otro de los cambios que se destaca, es que se realizo un cambio en la longitud salt predeterminada para las firmas PKCS#1 RSASSA-PSS al tamaño máximo que es más pequeño o igual a la longitud del resumen para cumplir con
FIPS 186-4. Esto se implementa mediante una nueva opción `OSSL_PKEY_RSA_PSS_SALT_LEN_AUTO_DIGEST_MAX` («auto-digestmax») para el parámetro `rsa_pss_saltlen`, que ahora es el predeterminado.

Ademas de ello, el código OSSL_LIB_CTX se reelaborado, la nueva opción está libre de bloqueos innecesarios y permite lograr un mayor rendimiento.

Tambien se destaca el rendimiento mejorado de los marcos de codificador y decodificador, asi como tambien una optimización de rendimiento realizada relacionada con el uso de estructuras internas (tablas hash) y almacenamiento en caché y tambien una velocidad mejorada de generación de claves RSA en modo FIPS.

Los algoritmos AES-GCM, ChaCha20, SM3, SM4 y SM4-GCM tienen optimizaciones de ensamblador específicas para diferentes arquitecturas de procesador. Por ejemplo, el código AES-GCM se acelera mediante las instrucciones AVX512 vAES y vPCLMULQDQ.

Se ha agregado soporte para el algoritmo KMAC (Código de autenticación de mensajes KECCAK) a KBKDF (Función de derivación de clave basada en clave), ademas de que sé han adaptado varias funciones «OBJ_*» para su uso en código de subprocesos múltiples.

Se agregó la capacidad de usar la instrucción RNDR y los registros RNDRRS disponibles en los procesadores basados ​​en la arquitectura AArch64 para generar números pseudoaleatorios.

Por otra parte, se menciona que la macro `DEFINE_LHASH_OF` ahora está obsoleta en favor de la macro `DEFINE_LHASH_OF_EX`, que omite la función específica del tipo correspondiente para definiciones de estas funciones, independientemente de si se define `OPENSSL_NO_DEPRECATED_3_1`. Es por ello que los usuarios de `DEFINE_LHASH_OF` pueden comenzar a recibir advertencias de obsolescencia para estos funciones independientemente de si las están utilizando. Se recomienda que los usuarios hacen la transición a la nueva macro, `DEFINE_LHASH_OF_EX`.

Finalmente, si estás interesado en poder conocer más al respecto sobre este nuevo lanzamiento, puedes consultar los detalles en el siguiente enlace.

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

Fedora 38 beta ya fue liberado y llega con los esperados spins de Budgie, Sway, Phosh y mas

Fedora 38 beta

Ya está disponible para pruebas la versión Beta de Fedora 38

Se dio a conocer la liberación de la versión de prueba beta de lo que será la próxima versión de “Fedora Linux 38”, siendo este lanzamiento beta la transición a la etapa final de prueba, en la que solo se permiten correcciones de errores críticos.

De los cambios más significativos en Fedora 38 se destaca la primera etapa de la transición al proceso de arranque modernizado. En el, las diferencias con el arranque clásico se reducen a utilizar en lugar de la imagen initrd generada en el sistema local al instalar el paquete del kernel, la imagen unificada del kernel UKI (Imagen unificada del kernel) generada en la infraestructura de distribución y certificada por la firma digital de la distribución.

UKI combina un controlador para arrancar el kernel desde UEFI (stub de arranque UEFI), una imagen del kernel de Linux y un entorno de sistema initrd cargado en la memoria en un archivo. Al llamar a la imagen UKI desde UEFI, es posible verificar la integridad y validez de la firma digital no solo del kernel, sino también del contenido del initrd, cuya validación es importante porque en este entorno se extraen claves para descifrar el FS en la primera etapa.

Otro de los cambios que se destaca en Fedora 38 es el que administrador de paquetes RPM, para analizar claves y firmas digitales, utiliza el paquete Sequoia, que ofrece una implementación de OpenPGP en el lenguaje Rust.

Anteriormente, RPM usaba su propio código de análisis OpenPGP, que tenía problemas y limitaciones sin resolver. Se agregó el paquete rpm-sequoia como una dependencia directa de RPM, en el que la compatibilidad con algoritmos criptográficos se basa en la biblioteca Nettle C (se prevé que brinde la capacidad de usar OpenSSL).

Ademas de ello, tambien se destaca que se ha implementado la primera etapa de un nuevo administrador de paquetes Microdnf, el cual está reemplazando al DNF actualmente utilizado. Microdnf se ha actualizado significativamente y ahora es compatible con todas las características principales de DNF, pero al mismo tiempo se caracteriza por su alto rendimiento y tamaño compacto. La diferencia clave de Microdnf y DNF, es usar C en lugar de Python para el desarrollo, lo que le permite deshacerse de una gran cantidad de dependencias.

Por la parte de los escritorios de Fedora 38 en la versión workstation se ha actualizado a Gnome 44, que se espera que se lance el 22 de marzo. Lo nuevo en GNOME 44 es una nueva implementación de pantalla de bloqueo y una sección de “aplicaciones en segundo plano” en el menú de estado.

En cuanto a los Spins, la edición de Xfce se ha actualizado a la versión 4.18, mientras que en la edición con LXQt este recibirá una compilación para la arquitectura AArch64.

En las compilaciones con el escritorio KDE, el asistente de configuración inicial se eliminó de la distribución, ya que la mayoría de sus funciones no se usan en KDE Spin y Kinoite, y el instalador de Anaconda configura las configuraciones iniciales durante la etapa de instalación.

Tampoco hay que olvidar que Fedora 38 estará recibiendo la compilación de Fedora Budgie Spin con el shell gráfico Budgie, asi como tambien la compilación de Fedora Sway Spin con el entorno personalizado de Sway creado con el protocolo Wayland y totalmente compatible con el administrador de ventanas en mosaico i3 e i3bar.

Hablando de Wayland, en esta nueva versión de Fedora 38 podremos encontrar que el administrador de pantalla SDDM tiene una interfaz de inicio de sesión predeterminada con Wayland. El cambio permite migrar el administrador de inicio de sesión a Wayland en compilaciones con el escritorio KDE.

Por último y no menos importante, tambien estaremos encontrando la formación de compilaciones para dispositivos móviles, que se suministra con el shell Phosh, que se basa en las tecnologías GNOME y la biblioteca GTK, utiliza el servidor compuesto Phoc que se ejecuta sobre Wayland, así como su propio teclado en pantalla squeekboard . Purism desarrolló originalmente el entorno como un análogo de GNOME Shell para el teléfono inteligente Librem 5, pero luego se convirtió en parte de los proyectos no oficiales de GNOME y ahora también se usa en postmarketOS, Mobian y algunos firmware para dispositivos Pine64.

Finalmente, cabe mencionar que esta versión de prueba nos estará mostrando muchas cosas más de las publicadas aquí, es por ello que, si quieres conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

El lanzamiento está previsto para el 18 de abril.

from Linux Adictos https://ift.tt/6cwiOmS
via IFTTT