Google esta desarrollando un nuevo formato de imagen WebP 2

Google ha publicado los trabajos relacionados con un nuevo formato de codificación de imágenes experimental llamado «WebP 2», el cual se está desarrollando como un reemplazo más eficiente del formato WebP.

Dado que el nuevo formato aún está en desarrollo y no se ha definido finalmente, por lo que aún no está listo para un uso generalizado (no se garantiza la compatibilidad con versiones anteriores en el codificador y descodificador, el código no se ha optimizado).

Sobre WebP 2

En WebP 2 describen nuevas funciones para su implementación, como HDR con representación de color de 10 bits, compresión más eficiente de la información de transparencia, soporte completo para la animación, decodificación incremental fácil (decodificación capa por capa con mayor detalle en cada etapa, lo que le permite generar miniaturas muy rápidamente para la vista previa), rápida implementación de software multiproceso, minimización de la degradación visual a bajas tasas de bits, modo de compresión sin pérdidas mejorado.

WebP 2 es el sucesor del formato de imagen WebP, actualmente en desarrollo. No está listo para uso general y el formato no está finalizado, por lo que los cambios en la biblioteca pueden romper la compatibilidad con imágenes codificadas con versiones anteriores. 

Este paquete contiene la biblioteca que se puede utilizar en otros programas para codificar o decodificar imágenes de Webp 2, así como herramientas de línea de comandos.

El propósito del nuevo formato es idéntico al del primer WebP: transmisión de imágenes a través de la red, optimización para resoluciones medias, uso en aplicaciones Web y móviles, con soporte para tareas comunes para estas tareas, como soporte para transparencia, animación y bocetos rápidos.

El códec experimental WebP 2 impulsa principalmente las características de WebP en términos de eficiencia de compresión. Las nuevas funciones (como la compatibilidad con 10b HDR) se mantienen al mínimo. Los ejes de experimentación son:

Compresión con pérdida más eficiente (~ 30% mejor que WebP, lo más cerca posible de AVIF)
Mejor degradación visual a muy baja tasa de bits
Compresión sin pérdidas mejorada
Compresión de transparencia mejorada
Soporte de animación
Vistas previas ultraligeras
Decodificación incremental ligera
Pequeño contenedor superior, diseñado específicamente para la Compresión de imágenes
Arquitectura completa de 10 bits (HDR10)
Fuerte enfoque en la implementación de software, completamente multiproceso
Los casos de uso siguen siendo en su mayoría los mismos que WebP: transferencia por cable, web más rápida, aplicaciones más pequeñas, mejor experiencia de usuario … WebP 2 se ajusta principalmente al contenido típico disponible en la Web y aplicaciones móviles: dimensiones de rango medio, transparencia , animaciones cortas, miniaturas.

Los principales esfuerzos en el desarrollo del nuevo formato tienen como objetivo aumentar la eficiencia de la compresión.

El primer WebP logra una reducción del tamaño del archivo del 25% al ​​34% en comparación con los archivos JPEG de calidad similar, y en el modo de compresión sin pérdida, logra una reducción del 26% en el tamaño del archivo resultante en comparación con el nivel máximo de compresión de PNG. WebP 2 tiene como objetivo lograr una mejora de la eficiencia de la compresión sin pérdidas del 30% con respecto al primer WebP y llevar el códec AVIF de compresión con pérdidas al 20%.

El prototipo bajo prueba todavía está pobremente optimizado y está muy por detrás de la implementación pulida de libwebp en términos de velocidad de codificación y decodificación. Por ejemplo, en el modo de compresión con pérdida, WebP 2 realiza la compresión cinco veces más lento que el primer WebP.

En comparación con libavif, el nuevo formato WebP que está desarrollando Google realiza la codificación dos veces más rápido, pero se retrasa 3 veces en la velocidad de decodificación. Al mismo tiempo, para cuando se publique la versión final de la biblioteca libwebp2, se planea lograr la paridad en la velocidad de decodificación.

Finalmente, para quienes estén interesados en conocer mas al respecto sobre la nota, pueden consultar la publicación original en el siguiente enlace.

Y en cuanto a los que estén interesados en conocer el código del proyecto, así como el avance de este, pueden consultarlo dirigiéndose al siguiente enlace.

from Linux Adictos https://ift.tt/2Uygtye
via IFTTT

SAD DNS: un ataque para sustituir datos falsos en la caché de DNS

Un grupo de investigadores de la Universidad de Tsinghua y la Universidad de California en Riverside han desarrollado un nuevo tipo de ataque que permite la sustitución de datos falsos en la caché del servidor DNS, que pueden usarse para falsificar la dirección IP de un dominio arbitrario y redirigir las llamadas al dominio al servidor del atacante.

El ataque evita la protección agregada a los servidores DNS para bloquear el método clásico de envenenamiento de la caché de DNS propuesto en 2008 por Dan Kaminsky.

El método de Kaminsky manipula el tamaño insignificante del campo de identificación de la consulta de DNS, que es solo de 16 bits. Para encontrar el identificador correcto necesario para suplantar el nombre de host, basta con enviar unas 7.000 solicitudes y simular unas 140.000 respuestas falsas.

El ataque se reduce a enviar una gran cantidad de paquetes falsos vinculados a IP al resolutor de DNS con diferentes identificadores de transacciones de DNS. Para evitar que la primera respuesta se almacene en caché, en cada respuesta falsa se especifica un nombre de dominio ligeramente modificado.

Para protegerse contra este tipo de ataque, los fabricantes de servidores DNS implementaron una distribución aleatoria de los números de los puertos de la red de origen desde los que se envían las solicitudes de resolución, lo que compensó el tamaño del identificador insuficientemente grande (para enviar una respuesta ficticia, además de seleccionar un identificador de 16 bits, se hizo necesario seleccionar uno de 64 mil puertos, que aumentó el número de opciones para la selección a 2 ^ 32).

El ataque SAD DNS simplifica drásticamente la identificación de puertos al aprovechar la actividad filtrada en los puertos de red. El problema se manifiesta en todos los sistemas operativos (Linux, Windows, macOS y FreeBSD) y cuando se utilizan diferentes servidores DNS (BIND, Unbound, dnsmasq).

Se afirma que el 34% de todos los solucionadores abiertos son atacados, así como 12 de los 14 principales servicios DNS probados, incluidos los servicios 8.8.8.8 (Google), 9.9.9.9 (Quad9) y 1.1.1.1 (CloudFlare), así como 4 de 6 enrutadores probados de fabricantes reconocidos.

El problema se debe a la peculiaridad de la formación de paquetes de respuesta ICMP, que permite determinar el acceso a puertos de red activos y no utilizados a través de UDP. Esta función permite escanear muy rápidamente los puertos UDP abiertos y omitir de manera efectiva la protección basada en una selección aleatoria de puertos de red de origen, lo que reduce el número de opciones de fuerza bruta a 2 ^ 16 + 2 ^ 16 en lugar de 2 ^ 32.

La fuente del problema es el mecanismo para limitar la intensidad del envío de paquetes ICMP en la pila de la red, que utiliza un valor de contador predecible, a partir del cual comienza la limitación de envío. Este contador es común para todo el tráfico, incluido el tráfico falso del atacante y el tráfico real. De forma predeterminada, en Linux, las respuestas ICMP están limitadas a 1000 paquetes por segundo. Para cada solicitud que llega a un puerto de red cerrado, la pila de red incrementa el contador en 1 y envía un paquete ICMP con datos del puerto inalcanzable.

Por lo tanto, si envía 1000 paquetes a diferentes puertos de red, todos los cuales están cerrados, el servidor restringirá el envío de respuestas ICMP durante un segundo y el atacante puede estar seguro de que no hay puertos abiertos entre los 1000 puertos buscados. Si se envía un paquete a un puerto abierto, el servidor no devolverá una respuesta ICMP y no cambiará el valor del contador, es decir, después de que se envíen 1000 paquetes, no se alcanzará el límite de tasa de respuesta.

Dado que los paquetes falsos se llevan a cabo desde una IP falsa, el atacante no puede recibir respuestas ICMP, pero gracias al contador total, después de cada 1000 paquetes falsos, puede enviar una solicitud a un puerto inexistente desde una IP real y evaluar la llegada de la respuesta; si la respuesta llegó, entonces en uno de los 1000 paquetes. Cada segundo, un atacante puede enviar 1000 paquetes falsos a diferentes puertos y determinar rápidamente en qué bloque se encuentra el puerto abierto, luego reducir la selección y determinar un puerto específico.

El kernel de Linux resuelve el problema con un parche que aleatoriza los parámetros para limitar la intensidad del envío de paquetes ICMP, lo que introduce ruido y minimiza la fuga de datos a través de canales laterales.

Fuente: https://www.saddns.net/

from Linux Adictos https://ift.tt/3kD5ONb
via IFTTT

Google Fit se renueva con nuevas métricas y nuevas herramientas para mejorar nuestra salud

Google Fit se renueva con nuevas métricas y nuevas herramientas para mejorar nuestra salud

Por segunda vez, Google vuelve a renovar su aplicación de salud y fitness. Google Fit para dispositivos móviles y relojes Wear OS se actualizará durante los próximos días con importantes mejoras.

La novedad principal del renovado Google Fit es que hace que sea todavía mucho más fácil comprobar si estamos cumpliendo con nuestros objetivos gracias a sus nuevas métricas.


Continue reading