Comprobación privada de credenciales comprometidas mediante índices ofuscados y filtros de Bloom (3/4)

Artículo invitado de Iliya Garakh. Tercera entrega de la serie iniciada en Comprobación privada de credenciales comprometidas (1/4).

Toca situar el esquema en el mapa. En esta entrega cuantificamos su rendimiento (almacenamiento, cómputo, ancho de banda, falsos positivos) y lo comparamos punto a punto con los protocolos existentes: el modelo k-anonymity de HIBP, las construcciones basadas en OPRF (Google Password Checkup, Apple iCloud Keychain), la private set intersection y la opción de descarga local del corpus. Es donde se ve dónde encaja la propuesta y dónde no.


En la entrega anterior construimos el protocolo de índices ofuscados con ruido determinista: el cliente envía la unión de sus k índices reales y d índices de ruido derivados de un secreto local, y el servidor responde con los bits del filtro en cada posición. Ahora la pregunta es práctica: ¿qué coste impone esto en producción y cómo se compara con lo que ya existe?

6. Compromisos de diseño

Privacidad

En el ámbito de la observación pasiva de consultas, el esquema ofrece resistencia sólida: un servidor que registre y correlacione consultas no puede refinar su estimación de qué celdas interesan al cliente, incluso con consultas repetidas. Esto es genuinamente superior a cualquier variante con ruido aleatorio —como vimos en la entrega 2— y también, en este eje concreto, superior al modelo k-anonymity de HIBP, en el que el prefijo SHA-1 actúa como identificador persistente para todas las consultas sobre la misma contraseña.

La pregunta más difícil —qué ocurre frente a un servidor que enumera activamente contraseñas candidatas— es la limitación dominante del esquema y se trata en la entrega 4.

Almacenamiento (servidor)

Para 6 × 108 hashes comprometidos y p = 10−3, el filtro requiere ≈ 1 GB de memoria de acceso aleatorio. El despliegue en RAM es la única opción sensata; accesos aleatorios en disco son catastróficamente lentos.

Cómputo

  • Cliente:k + d evaluaciones de hash con clave más una permutación. Decenas de microsegundos en hardware de uso general.
  • Servidor:k + d accesos aleatorios al vector de bits del filtro. Cientos de microsegundos, dominados por la latencia de memoria.

Ambos están muy por debajo del RTT típico de red, por lo que la latencia de extremo a extremo está dominada por el tiempo de ida y vuelta en la mayoría de despliegues.

Ancho de banda

Una consulta de k + d ≈ 40 índices de 32 bits ocupa 160 bytes. La respuesta son k + d bits más cabeceras: menos de 100 bytes. El total, incluyendo la sobrecarga de TLS, cabe cómodamente en un kilobyte.

Falsos positivos

La tasa configurable p ∈ [10−4, 10−3] puede marcar como posiblemente comprometida una contraseña segura. Esto es aceptable para la comprobación de filtraciones (el usuario cambia innecesariamente una contraseña). No es aceptable en casos de uso que requieran pertenencia exacta (listas de control de acceso, listas blancas), donde debe emplearse una estructura diferente.

7. Comparación con los enfoques existentes

k-anonimato (HIBP / Cloudflare). El cliente envía los 20 primeros bits del prefijo de SHA-1(pw); el servidor devuelve ≈ 500 hashes candidatos con ese prefijo. Es operacionalmente elegante —una sola petición HTTPS GET—, pero la fuga es real: 20 bits por consulta, deterministas, observables por cualquier CDN y nodo intermedio. El análisis de Cable (2018) demostró que esta exposición mejora measurablemente las tasas de éxito de ataques de descifrado. El prefijo funciona además como identificador persistente de la contraseña para todos los clientes que la consulten.

OPRF (Google Password Checkup, Apple iCloud Keychain). El cliente ciega H(pw), el servidor aplica una PRF con clave sin conocer la entrada, el cliente deshace el cegado para obtener PRFk(H(pw)) y lo coteja contra una caché local. El servidor no aprende nada sobre pw. El coste son operaciones sobre curvas elípticas (típicamente dos multiplicaciones escalares), la complejidad del protocolo y la necesidad de mantener actualizada la caché local.

PSI (Private Set Intersection). PSI de propósito general basada en cifrado homomórfico o garbled circuits ofrece las garantías formales más sólidas, pero es dos o tres órdenes de magnitud más costosa y rara vez se despliega para este caso de uso.

Local / sin conexión. Descarga del corpus completo y comprobación local. Privacidad perfecta. Almacenamiento 11–25 GB comprimido, actualizaciones costosas, inviable en clientes móviles.

PropiedadHash directok-anonimatoOPRF / PSILocalÍndices ofuscados
Aprende equivalente en claroParcial (20 bits)NoN/ACondicional (§8)
Resistencia a correlaciónN/AParcialN/ASí (determinista)
Latencia clienteMuy bajaMuy bajaAlta (EC)Alta (E/S)Muy baja
Rendimiento servidorMuy altoMuy altoBajo–mod.N/AMuy alto
Sobrecarga de redMínimaBaja (∼kB)ModeradaMuy altaBaja (<1 kB)
Complejidad implementaciónTrivialSencillaAlta (EC)MediaModerada
Agilidad ante actualizacionesTrivialTrivialTrivialDeficienteModerada

El esquema de índices ofuscados se sitúa entre k-anonymity y OPRF en el eje de privacidad, con rendimiento próximo a k-anonymity. Su ventaja específica sobre k-anonymity es la resistencia a la correlación entre consultas repetidas; su desventaja frente a OPRF se describe en la siguiente entrega.


En la cuarta y última entrega nos enfrentamos a las limitaciones reales del esquema: el ataque de diccionario fuera de línea a partir de una única consulta, la gestión del secreto a largo plazo, qué ocurre frente a un servidor activo o malicioso, problemas abiertos y, sobre todo, cuándo es razonable desplegar esta construcción y cuándo no.

Speak Your Mind

*