#27 Es falso desde la primer viñeta. La clave fundamental de cifrado e id del votante pasa primero por los servidores de Agora, luego se enviań al cliente. Por lo tanto Agora tiene todos los datos para generar votos válidos. Es una burrada lo que se hizo.
Y ya puse cuál es el método en el apunte cuál es el método habitual para evitar esto, lo pongo aquí (cc #28) así dejáis de repetir tonterías de cuñados (nunca nunca nunca puede decirse que es seguro un sistema si la parte que almacena los votos y os cuenta tiene la clave del usuario que genera el cifrado):
----
Para solucionar el problema de la identificación se usan métodos bien conocidos, como los protocolos JCJ, Civitas y mejorados. En general estos protocolos son muy aptos para voto electrónico remoto pero tienen problemas de coste computacional elevado, por ejemplo en JCJ es O(votos_válidos² + votos_fraudulentos²), por lo que no son aptos para votaciones masivas.
En estos protocolos al votante V se le asigna una clave aleatoria c desde el servidor de Podemos (usando canal seguro), al mismo tiempo se genera una una cadena s = cifrado(c + cadena aleatoria), la clave pública de cifrado es la de las autoridades de escrutinio. La cadena s es la que se pasa a AgoraVoting (por canal seguro) y serviría para validar votos (además de solucionar los problemas de coacción y voto secreto), el único que conoce la clave c es el votante. AgoraVoting no la conoce, sólo s, por lo que no puede generar o cambiar votos. Tampoco podría saber el valor del voto ya que al servidor sólo le llegan un par de entradas cifradas con las claves públicas de las autoridades de escrutinio(acompañadas de dos non-interactive zero-knowledge proof).
Estos protocolos tienen buenas propiedades para evitar la “intimidación”. El votante puede emitir los votos que quiera (sólo hace falta almacenar el orden), y puede verificar su voto durante y después del período de votación. Este tipo de mecanismo es fundamental en los sistemas de voto electrónico no asistido (i.e. remoto por internet), no entiendo cómo se ha fallado en esta parte crítica. Supongo que fue para hacer sencilla la integración con Podemos (requiere envío de dos claves, una al cliente y otra al servidor de AgoraVoting, y debía funcionar tanto desde web como desde la app -que abre el navegador al ir a votar-).
#13 Yo creo que indirectamente sí que pagamos el software, ya que las empresas lo pagan, y luego sus productos los compramos nosotros. En el fondo, todos los gastos revierten en el precio final.
#3 Sí, la criptografía de clave pública es más lenta, pero en este caso no estamos hablando de un cifrado en flujo donde un sistema de clave pública puede morirse sino del intercambio de un número, cosa que hacen millones de sistema cada día sin despeinarse cada vez que establecen una conexión SSL segura, desde los más potentes hasta los más sencillos.
Y a cambio de esa ganancia en velocidad reduces la complejidad, divides los primos en dos listas separadas y conocidas, y además pierdes la característica de no repudio, el que envía el mensaje puede simplemente decir que el no lo hizo y quedarse tan ancho porque no tienes ninguna forma de probar que lo hizo, en cambio si te manda un número cifrado con su clave privada no va a tener narices de decir que no lo hizo.
Y ya puse cuál es el método en el apunte cuál es el método habitual para evitar esto, lo pongo aquí (cc #28) así dejáis de repetir tonterías de cuñados (nunca nunca nunca puede decirse que es seguro un sistema si la parte que almacena los votos y os cuenta tiene la clave del usuario que genera el cifrado):
----
Para solucionar el problema de la identificación se usan métodos bien conocidos, como los protocolos JCJ, Civitas y mejorados. En general estos protocolos son muy aptos para voto electrónico remoto pero tienen problemas de coste computacional elevado, por ejemplo en JCJ es O(votos_válidos² + votos_fraudulentos²), por lo que no son aptos para votaciones masivas.
En estos protocolos al votante V se le asigna una clave aleatoria c desde el servidor de Podemos (usando canal seguro), al mismo tiempo se genera una una cadena s = cifrado(c + cadena aleatoria), la clave pública de cifrado es la de las autoridades de escrutinio. La cadena s es la que se pasa a AgoraVoting (por canal seguro) y serviría para validar votos (además de solucionar los problemas de coacción y voto secreto), el único que conoce la clave c es el votante. AgoraVoting no la conoce, sólo s, por lo que no puede generar o cambiar votos. Tampoco podría saber el valor del voto ya que al servidor sólo le llegan un par de entradas cifradas con las claves públicas de las autoridades de escrutinio(acompañadas de dos non-interactive zero-knowledge proof).
Estos protocolos tienen buenas propiedades para evitar la “intimidación”. El votante puede emitir los votos que quiera (sólo hace falta almacenar el orden), y puede verificar su voto durante y después del período de votación. Este tipo de mecanismo es fundamental en los sistemas de voto electrónico no asistido (i.e. remoto por internet), no entiendo cómo se ha fallado en esta parte crítica. Supongo que fue para hacer sencilla la integración con Podemos (requiere envío de dos claves, una al cliente y otra al servidor de AgoraVoting, y debía funcionar tanto desde web como desde la app -que abre el navegador al ir a votar-).