TRANSPARENCIA Y PROTECCIÓN DE DATOS
Cifrado y seguridad
Tu intención de voto y tu provincia se guardan cifradas con AES-256-GCM. Esta página explica cómo funciona esa protección, qué datos abarca y qué garantías ofrece.
Lo esencial, en palabras sencillas
El cifrado transforma tu selección en un bloque que no se puede interpretar sin la clave correspondiente. La conexión HTTPS protege la comunicación entre tu navegador y la web. Al guardar tu intención de voto, la aplicación cifra conjuntamente la opción elegida y la provincia antes de escribirlas en la base de datos.
La clave se mantiene fuera de la carpeta pública de la web y separada de la base de datos. Por eso, disponer únicamente de una copia de los campos cifrados no basta para leerlos. El servidor sí utiliza la clave para mostrarte tu última respuesta y calcular los resultados agregados.
El cifrado no hace anónima tu respuesta ni impide por sí solo el acceso de quien administra el servidor y sus claves. Conservamos una vinculación interna con tu cuenta para mantener una intención vigente por participante, permitir actualizarla y atender su retirada.
Qué significa «100% cifrado» en esta web
La expresión se refiere al contenido de la intención de voto guardada: la opción política —o la opción en blanco— y la provincia se incluyen en el bloque cifrado. No significa que todos los datos de la plataforma estén cifrados del mismo modo, que el sistema sea invulnerable o que nadie pueda descifrar las respuestas.
| Datos | Tratamiento en la aplicación |
|---|---|
| Opción declarada y provincia | Se guardan juntas en un bloque cifrado con AES-256-GCM. |
| Correo de la cuenta | Se cifra mediante AES-256-GCM con una clave derivada para una finalidad diferente. |
| Búsqueda por DNI + email | Utiliza identificadores HMAC-SHA-256 calculados con una clave del servidor. No son datos anónimos. |
| Identificador interno y metadatos | Las fechas, la revisión, el método de identificación y la evidencia del consentimiento quedan fuera del bloque cifrado de la respuesta. |
| Mensajes de contacto | Se tramitan por correo y tienen su propia información de privacidad. No se protegen mediante el bloque de cifrado de las intenciones de voto. |
Antes de completar el acceso, una selección puede mantenerse temporalmente en la sesión del servidor para continuar el proceso. Ese estado de sesión no es el bloque cifrado de la respuesta ya registrada. No publicamos respuestas individuales, identificadores ni claves.
Del formulario a los resultados
- Envío protegido. El navegador envía la selección mediante HTTPS. La aplicación comprueba la sesión, el consentimiento y que la opción sea válida para la provincia.
- Cifrado antes de guardar. Se prepara el contenido de la respuesta, se genera un valor aleatorio nuevo y se aplica AES-256-GCM. La base de datos recibe el bloque cifrado, su valor aleatorio y su etiqueta de autenticación.
- Consulta y recuento. El servidor descifra las respuestas vigentes que necesita procesar para mostrar la tuya o calcular los recuentos y sus filtros. Este procesamiento sucede en el servidor.
- Publicación agregada. La gráfica muestra cantidades y porcentajes. Los filtros no ofrecen una lista de participantes. Con muestras pequeñas, los resultados y sus variaciones pueden permitir inferencias; agregar datos no elimina por sí solo ese riesgo.
Detalle técnico
Algoritmo, valores aleatorios y comprobación de integridad
La aplicación utiliza las funciones de OpenSSL de PHP con el algoritmo aes-256-gcm. Cada respuesta incluye un contenido JSON versionado con el código de provincia, el identificador del partido cuando corresponde y el tipo de opción.
Para cada cifrado se generan 12 bytes aleatorios mediante random_bytes(12): un nonce de 96 bits. El resultado se almacena junto a una etiqueta de autenticación de 16 bytes. El contexto adicional autenticado identifica el formato de respuesta de la aplicación.
Al descifrar, la etiqueta permite detectar cambios en el bloque cifrado que no hayan sido producidos con la clave correspondiente. Si la comprobación falla, la aplicación rechaza el bloque. Esta propiedad no equivale a una firma pública de la persona ni a una prueba independiente del recuento.
Claves y separación de finalidades
La clave raíz se genera con 32 bytes aleatorios y se guarda en un archivo privado con permisos restrictivos. Mediante HMAC-SHA-256 se derivan claves para distintas finalidades, entre ellas el cifrado del correo, el cifrado de la respuesta y los identificadores de búsqueda.
Estas claves derivadas dependen de la misma clave raíz: separan usos, pero no constituyen custodias independientes. La aplicación necesita poder leer el secreto para funcionar. El control del servidor y de ese secreto permitiría descifrar los datos, por lo que la seguridad también depende de los accesos, el mantenimiento y la custodia del entorno.
Una copia de la base de datos mantiene cifrados estos campos. No afirmamos por ello que estén cifrados todos los discos, registros, sesiones o soportes de copia. Una copia que reúna datos y claves permitiría recuperar su contenido.
Actualización, retirada y conservación
La aplicación utiliza una relación interna entre la cuenta y la participación. Una nueva selección sustituye la intención vigente de ese participante; el recuento consulta respuestas vigentes. Puedes retirar la respuesta mediante las opciones de tu cuenta o solicitar ayuda por el formulario de contacto.
Los plazos configurados y las condiciones para conservar o eliminar los datos se explican en la política de privacidad. El cifrado no sustituye las obligaciones de conservación, supresión ni ejercicio de derechos.
Garantías y límites reales
El servidor puede descifrar las respuestas. El diseño actual no es un sistema en el que las claves estén exclusivamente en manos de los participantes ni un sistema de recuento sin descifrado. El personal con control administrativo y acceso a las claves puede técnicamente acceder al contenido.
El cifrado no demuestra por sí solo que un resultado sea correcto. La etiqueta GCM no impide que alguien con acceso suficiente borre registros, sustituya un bloque completo por otro válido o genere datos nuevos con la clave. Tampoco protege por sí sola todos los metadatos. La verificación pública de un recuento requiere mecanismos adicionales que esta implementación no ofrece.
Esta explicación no es una certificación ni una auditoría independiente. Identifica el funcionamiento del código y los límites de sus garantías. No publicamos claves ni respuestas para demostrar el cifrado: eso perjudicaría su protección. El uso de un algoritmo estandarizado tampoco implica que el organismo que lo publica haya certificado Sondeo General.
Referencias y contacto
Puedes consultar la especificación de GCM del NIST, la documentación de cifrado de OpenSSL en PHP y nuestra información de privacidad.
Si tienes dudas técnicas o quieres comunicar un posible problema de seguridad, utiliza el formulario de contacto. Describe lo necesario para que podamos revisarlo y evita enviar datos de otras personas, claves o información de acceso.