En agosto de 2021, Apple anunció que iba a escanear cada foto de tu iPhone antes de subirla a iCloud. En septiembre del mismo año, después de dos semanas de tormenta, retiró la propuesta. En diciembre de 2022 la declaró oficialmente muerta. En 2022, la Comisión Europea propuso un reglamento que obliga a WhatsApp, Signal y Telegram a hacer exactamente lo mismo que Apple retiró. Ese reglamento —conocido como Chat Control— sigue vivo en el Consejo Europeo ahora mismo.
Los dos intentos dependen del mismo algoritmo: un hash perceptual de 64 bits que se implementa en 40 líneas de Python. No exagero. Ni es una metáfora. Son 40 líneas, y al terminar este artículo tendrás una versión ejecutable en tu máquina.
La mayoría del debate público —en España y fuera— sucede sin que los participantes entiendan cómo funciona el mecanismo. La regulación se discute en términos políticos («privacidad contra seguridad infantil») mientras el núcleo técnico permanece como caja negra. Este post es el antídoto. Si al terminar quieres tomar postura, podrás hacerlo con base técnica. Si no quieres, al menos sabrás qué se te está pidiendo.
El problema: SHA-256 no sabe que dos fotos son la misma
El primer impulso de cualquier desarrollador es resolver este problema con SHA-256. Si dos imágenes producen el mismo hash, son la misma imagen. Simple, rápido, criptográficamente sólido.
No sirve.
import hashlib
def sha256(path):
with open(path, "rb") as f:
return hashlib.sha256(f.read()).hexdigest()
# Misma foto, dos compresiones distintas
sha256("foto.jpg") # "a7f3..."
sha256("foto_reencoded.jpg") # "9c2e..." (totalmente distinto)
Cambia un solo bit —un reencoding JPEG de calidad 95 a 90, un cambio de formato WebP a JPEG, un ajuste imperceptible de brillo— y SHA-256 produce un hash completamente distinto. Los datos son claros: la similitud criptográfica es intolerante por diseño. Es una propiedad, no un bug.
Para detectar «la misma foto aunque difiera en compresión» hace falta un algoritmo tolerante. Hace falta un hash perceptual: una firma de 64 bits que sobreviva a cambios que no alteran lo que la imagen representa.
aHash: promedio de brillo
El primero en ser útil se llama Average Hash o aHash. La idea es brutalmente simple:
import numpy as np
from PIL import Image
def average_hash(path, size=8):
img = Image.open(path).convert("L").resize((size, size))
arr = np.asarray(img, dtype=np.float32)
mean = arr.mean()
bits = (arr.flatten() > mean).astype(int)
return "".join(str(b) for b in bits)
def hamming(a, b):
return sum(x != y for x, y in zip(a, b))
Reduces la imagen a 8×8 píxeles en escala de grises, calculas la media de brillo, y cada píxel se convierte en 1 si supera la media o 0 si no. Resultado: 64 bits que representan la distribución global de brillo.
Dos imágenes «iguales» producen hashes con distancia de Hamming baja (≤ 5 bits de diferencia). Dos imágenes distintas producen hashes con distancia grande (40+ bits). Funciona con foto redimensionada, recortada ligeramente, reencodeada. Pero se rompe si alguien ajusta el contraste o el brillo global. Es el primer paso.
dHash: gradientes relativos
El siguiente paso, publicado por Neal Krawetz en 2011, se llama Difference Hash o dHash:
def difference_hash(path, size=8):
img = Image.open(path).convert("L").resize((size + 1, size))
arr = np.asarray(img, dtype=np.float32)
diff = arr[:, 1:] > arr[:, :-1]
return "".join("1" if v else "0" for v in diff.flatten())
En vez de medir brillos absolutos, mide gradientes horizontales relativos: cada píxel es 1 si es más claro que el píxel a su derecha. Si toda la imagen se oscurece un 30%, los gradientes relativos se mantienen. dHash aguanta cambios de contraste, de gamma, de color grading —escenarios donde aHash se rompía.
Cuarenta líneas de Python, dos semanas de biblioteca si cuentas PIL, y ya tienes la herramienta que está en el centro de la regulación europea más debatida del año.
De 40 líneas a infraestructura global
Lo que hiciste con average_hash y difference_hash es, con refinamientos, lo que procesa buena parte de las imágenes que circulan por internet.
Microsoft PhotoDNA (2009). Desarrollado por Hany Farid (Dartmouth) en colaboración con Microsoft Research para la detección de material de abuso sexual infantil (CSAM). Es una variante sofisticada del mismo principio: reducir la imagen a una firma corta, robusta a reencoding, que permite matching por distancia. La implementación exacta es propietaria, pero las ideas vienen de la misma familia algorítmica. Microsoft afirma que PhotoDNA procesa miles de millones de imágenes al mes para las principales plataformas.
Meta PDQ (2019). Variante open-source desarrollada internamente en Meta (antes Facebook) y publicada como parte de ThreatExchange en GitHub. A diferencia de PhotoDNA, puedes leer el código, ejecutarlo, entenderlo. La elección de publicarlo era deliberada: Meta argumenta que la seguridad no debe depender del secreto del algoritmo, sino de la dificultad de atacar el sistema completo.
YouTube Content ID (2007). Usa hashes perceptuales adaptados a vídeo: trocea cada upload en fingerprints por frame y los compara contra una base de contenido con derechos registrados. Detecta reuploads, mashups que incluyen escenas enteras, clips de películas embebidos. No es SHA: tolera reencoding, recorte de logos, pequeñas rotaciones.
Google Photos, Apple Photos, Amazon Photos. Cuando tu móvil te dice «esta foto ya la tienes en iCloud desde el iPad», no está comparando bytes. Usa variantes de hash perceptual sobre embeddings CNN para detectar «misma foto» a pesar de compresiones distintas, formatos distintos, recortes leves.
Apple NeuralHash (2021). La propuesta que retiraron. NeuralHash no era un pHash clásico: era una red neuronal convolucional entrenada para producir el mismo embedding ante transformaciones invariantes (rotación, crop, compresión). El output se colapsaba a 96 bits por Locality-Sensitive Hashing. Técnicamente más sofisticado que PhotoDNA. Conceptualmente, el mismo principio: fingerprint corto, robusto, comparable por distancia.
El patrón es consistente: el mismo algoritmo, bajo nombres distintos, con refinamientos distintos, se ha convertido en infraestructura silenciosa de la web. La mayoría de usuarios no sabe que existe. La mayoría de desarrolladores ha oído hablar de él sin haberlo implementado. Y ahora el Parlamento Europeo está a punto de legislar sobre su despliegue obligatorio en comunicaciones cifradas.
Las líneas de fractura
Si el algoritmo fuera infalible, el debate sería trivial. No lo es. Tiene cuatro problemas estructurales que el lector debe conocer antes de formar opinión.
Falsos positivos
Dos imágenes completamente distintas pueden producir hashes idénticos. En un hash de 64 bits hay 2^64 = 18 trillones de hashes posibles, pero el espacio de imágenes «razonables» (las que un humano produciría, no ruido aleatorio) es mucho menor y tiene regularidades estadísticas. Las colisiones accidentales son raras pero no inexistentes.
En 2021, dentro de la tormenta de Apple, usuarios documentaron colisiones accidentales de NeuralHash con imágenes cotidianas: un perro y una escultura abstracta. La tasa real era baja, pero existía. Apple afirmaba «1 falso positivo por billón de cuentas por año». Investigadores pusieron el número en entredicho demostrando que, con modificaciones triviales, la tasa subía órdenes de magnitud.
Falsos negativos
Rota una imagen 10 grados, recorta el 20% del borde derecho, o aplica un flip horizontal, y la mayoría de hashes perceptuales pierden la pista. Los más sofisticados (pHash con DCT, NeuralHash con invariancias entrenadas) aguantan más, pero todos tienen un umbral donde fallan.
Esto significa que un usuario motivado puede saltarse el sistema con herramientas que vienen pre-instaladas en cualquier móvil: rotar la imagen, comprimir a calidad baja, añadir un borde de 10 píxeles. La base de hashes no reconocerá la imagen alterada, y el contenido ilícito pasará inadvertido.
Colisiones adversariales
Este es el problema más serio y el menos discutido en prensa generalista. Desde el 18 de agosto de 2021 —menos de dos semanas después del anuncio de Apple— un investigador bajo el pseudónimo Asuhariet Ygvar publicó en GitHub una ingeniería inversa completa de NeuralHash extraída de los binarios de iOS. A los pocos días se publicaron colisiones craftables: dos imágenes completamente distintas con exactamente el mismo hash, generadas deliberadamente.
En 2021, el equipo de Jonathan Prokos, Matthew Green y colaboradores de Johns Hopkins formalizó el ataque en el paper «Squint Hard Enough: Attacking Perceptual Hashing with Adversarial Machine Learning» (USENIX Security). Demostraron que, para cualquier hash perceptual conocido, es posible generar:
- Colisiones arbitrarias: dos imágenes cualquiera con el mismo hash.
- Pre-imágenes dirigidas: dada una imagen objetivo, generar otra visualmente distinta que produzca su hash.
Las implicaciones operativas son severas. Un atacante puede enviarte una imagen inocente cuyo hash coincida con un hash de CSAM conocido. Tu móvil dispara la alerta. Un humano revisa, ve el contenido real (inocente), y el sistema se reinicia. Pero el atacante puede automatizar esto contra miles de objetivos: cualquier sistema que dependa de agregar alertas en umbral (el diseño de Apple) queda expuesto a bombardeo malicioso. Esto no es un fallo de ingeniería de Apple. Es una propiedad estructural de la familia de algoritmos perceptuales.
Quién controla la base de hashes
El tercer problema es político. La base de hashes contra la que se compara está controlada por NCMEC (National Center for Missing & Exploited Children), una organización privada estadounidense. Los hashes se federan con proveedores en Europa y otros países, pero la autoridad de qué se añade y qué se retira reside en EE.UU.
Esto crea un single point of truth global con consecuencias poco discutidas. ¿Qué pasa si NCMEC decide añadir hashes que no corresponden estrictamente a CSAM? ¿Qué pasa si un gobierno —el de EE.UU. o cualquier otro que presione a las plataformas que consumen la base— exige que se añadan hashes de imágenes asociadas a disidencia política, contenido LGBTQ, filtraciones periodísticas? El algoritmo no distingue. Detecta lo que le digas que detecte.
El debate: Apple 2021 y la UE 2026
Este es el contexto político que da urgencia al asunto técnico.
5 de agosto de 2021. Apple anuncia tres funciones de «protección infantil» en iOS 15. Una de ellas: escaneo on-device de cada foto antes de subirla a iCloud Photos, usando NeuralHash contra la base de NCMEC. Umbral de 30 matches para alertar, revisión humana, reporte a autoridades.
En las dos semanas siguientes la reacción fue demoledora. Matthew Green (Johns Hopkins) y Ross Anderson (Cambridge) lideraron la crítica académica con el paper «Bugs in Our Pockets: The Risks of Client-Side Scanning» (2021), firmado por 14 investigadores en criptografía y seguridad. El argumento central: la infraestructura de escaneo on-device es la puerta de atrás, no la base de hashes contra la que compara. Una vez construida, los gobiernos pueden exigir que se use para otras cosas. Apple estaría en posición débil para negarse.
Se publicaron colisiones NeuralHash en días. Se publicó una carta abierta firmada por más de 90 organizaciones (EFF, ACLU, Access Now, Freedom of the Press Foundation) pidiendo la retirada. Apple intentó defender el sistema en press call el 13 de agosto, pero los fallos técnicos demostrados públicamente fueron letales para la narrativa.
El 3 de septiembre de 2021, Apple anunció «retraso». En diciembre de 2021 eliminó silenciosamente las referencias a CSAM Detection de su web. En diciembre de 2022 la función quedó oficialmente muerta, sustituida por Advanced Data Protection (cifrado E2E opcional para iCloud Photos) —literalmente lo opuesto.
11 de mayo de 2022. La Comisaria Europea Ylva Johansson presenta la propuesta de Regulation to prevent and combat child sexual abuse (CSAR), popularizada como «Chat Control». La propuesta obliga a proveedores de servicios de comunicación (WhatsApp, Signal, Telegram, iMessage) a detectar CSAM en las comunicaciones de sus usuarios mediante órdenes judiciales de detección. Las técnicas permitidas incluyen el client-side scanning con hashes perceptuales sobre mensajes cifrados.
El paralelismo con lo que Apple retiró es exacto. Los críticos —incluyendo los mismos académicos que firmaron contra Apple— lo señalan explícitamente. Entre 2022 y 2025 la propuesta ha pasado por revisiones del Parlamento Europeo (que ha suavizado los elementos más agresivos), negociaciones en el Consejo (dividido, con Alemania, Países Bajos y Polonia entre los más críticos), y reintroducciones periódicas bajo sucesivas presidencias.
En 2026 el dossier sigue vivo. Las votaciones se aplazan, las versiones se matizan, pero la dirección estratégica no ha cambiado: la UE quiere escaneo on-device como herramienta estándar. El debate está a un paso de cristalizar en regulación vinculante para 450 millones de europeos.
Qué puedes hacer
Los datos son claros: entender cómo funciona el algoritmo es requisito para participar en el debate con base. No opinión. Aritmética política.
Acciones concretas, en orden de coste creciente:
- Corre el código de este post. Copia
average_hashydifference_hash, aplícalo a dos fotos tuyas, mide distancias. Observa cómo el brillo rompe aHash y dHash lo aguanta. Cuarenta líneas, treinta minutos. - Lee el whitepaper de PDQ en el repositorio
facebook/ThreatExchangeen GitHub. Es código real, documentado, en producción. Entender la evolución de pHash a PDQ en un par de horas te da el nivel técnico para leer cualquier artículo de prensa sobre el tema con espíritu crítico. - Lee «Bugs in Our Pockets» (Anderson et al., 2021, arXiv:2110.07450). Es el documento de referencia contra el client-side scanning, firmado por la mayor parte de la comunidad criptográfica seria. Cuarenta páginas, denso, pero es el argumento académico que define el debate.
- Sigue las votaciones de la CSA Regulation en el Parlamento Europeo y el Consejo. Herramientas públicas como chatcontrol.eu (de Patrick Breyer, eurodiputado Pirata) agregan el estado del dossier.
Lo que no debes hacer: opinar sin haber visto el algoritmo funcionar. No por purismo técnico. Por honestidad. El algoritmo que está en el centro del debate cabe en 40 líneas de un lenguaje que domina cualquier desarrollador. Si no lo has leído, tu opinión sobre la regulación que depende de él es, como mucho, una ecogenic del tuit de otro.
La pregunta no es si la UE va a regular las comunicaciones cifradas. Es si quienes opinamos sobre cómo lo hace vamos a hacerlo con base o sin ella.
Referencias
- Krawetz, Neal. «Looking Up Images». HackerFactor Blog, 2011. La introducción clásica a pHash y dHash.
- Meta. «PDQ — Perceptual Hashing for Image Similarity». GitHub:
facebook/ThreatExchange, 2019. - Prokos, J.; Fendley, N.; Green, M.; Jois, T. M.; Cao, Y. «Squint Hard Enough: Attacking Perceptual Hashing with Adversarial Machine Learning». USENIX Security Symposium, 2023 (arXiv:2112.09283).
- Abelson, H.; Anderson, R.; Bellovin, S. M.; et al. «Bugs in Our Pockets: The Risks of Client-Side Scanning». arXiv:2110.07450, 2021.
- Apple. «CSAM Detection Technical Summary», agosto 2021. Archivado; ya no publicado oficialmente.
- Ygvar, A. «AppleNeuralHash2ONNX». GitHub, agosto 2021. Ingeniería inversa y generador de colisiones.
- European Commission. «Proposal for a Regulation laying down rules to prevent and combat child sexual abuse», COM(2022) 209 final, 11 de mayo de 2022.
- NCMEC. CyberTipline Reports, estadísticas anuales.
Read this article in English.
