El LSB no sobrevive a un reencode: qué aguanta de verdad una marca de agua

Un mensaje escondido en los bits menos significativos de una foto no sobrevive a que esa foto pase por un chat. No es una sospecha, es una medición: el primer reencode lo borra por completo y lo que queda no es un dato dañado, es ruido. La prueba es reproducible con pip sobre una fotografía de 1600×1063, un payload de 32 bytes y diez intentos independientes por canal, con recuperación exacta como criterio. Nada de "casi".

Lo primero que hace cualquier plataforma al enviar una imagen es redimensionar y recomprimir en JPEG, y eso no se negocia desde el móvil porque ocurre en el servidor. El autor no mandó fotos por WhatsApp ni por WeChat: montó un banco de pruebas que aproxima cada plataforma con un resize y un reencode a una calidad concreta —WhatsApp ≤1600 px a calidad 72, Instagram ≤1080 a 80, Telegram a 89, WeChat borde corto a 1080 y 80— y etiqueta cada canal con el prefijo sim. La etiqueta no es un descargo de responsabilidad: un simulador sirve para aislar qué transformación rompe qué, y no para afirmar que algo sobrevive a una app real.

Un 50% de BER no es un payload dañado, es su ausencia

El LSB aguanta sin canal con un PSNR de 94,4 dB, prácticamente invisible. En cuanto hay recompresión, el BER se planta entre el 49% y el 51% en todos los canales, incluido el más suave: JPEG a calidad 90 sin redimensionar, 51,29%. Un BER cerca del 50% significa que el decodificador está leyendo ruido y acierta la mitad de los bits por azar, así que no hay código corrector que arregle nada, porque no queda nada que corregir. El motivo es estructural: el payload se escribió justo en los bits que la compresión con pérdida existe para tirar. JPEG pasa la imagen a coeficientes DCT, los cuantiza y la reconstruye, y la reconstrucción reescribe los bits bajos de casi todos los píxeles.

La marca estructural aguanta la recompresión, pero no un resize

La segunda técnica esconde los datos en los valores singulares de bloques DCT de una subbanda wavelet, propiedades que sobreviven a la recuantización. Su PSNR baja a 39,1 dB —bastante menos invisible— y falla de otra forma: con calidad 50 el BER es del 8,67% y con la simulación de WhatsApp del 3,20%, alrededor del 97% de bits correctos, pero cero recuperaciones exactas porque el listón es el listón. Ese es el tipo de daño que un código corrector sí sabe reparar.

El redimensionado, en cambio, la mata igual que mataba al LSB: 51,68% de BER con un resize a 1080 y 50,12% con la simulación de Instagram. Que una marca sobreviva a un JPEG de calidad 50 y no a un reescalado geométrico sin pérdida es lo más incómodo del resultado.

Con un Reed-Solomon RS(32,8) —8 bytes de mensaje y 24 de paridad, hasta 12 bytes corruptos reparables— la recompresión típica deja de ser un problema: la simulación de WhatsApp pasa de 0/10 a 10/10, Telegram queda en 10/10, WeChat sube de 3/10 a 10/10 y encadenar WeChat y WhatsApp también da 10/10. El límite aparece en calidades muy bajas: a 70 quedan 9/10, a 60 baja a 5/10 y a 50 no recupera ninguna. El precio de todo esto es que el payload útil cae de 32 bytes a 8, y el resize sigue en 0/10 con corrección y sin ella.

Para quien esconda datos en una imagen, el enemigo no es la compresión, es el escalado, y el margen de maniobra se mide en bytes de carga útil. El banco de pruebas está pensado para reutilizarse y el propio autor insiste en el mismo punto: estos números describen transformaciones, no plataformas. Dar por bueno que un mensaje viaja escondido por WhatsApp o por WeChat exige enviarlo de verdad a un dispositivo de verdad, y eso es otro experimento con otra superficie de fallo.