> D'o� l'importance de conserver les bulletins de votes �lectroniques,
> comme on conserve les bulletins de vote en papier, pour pouvoir
> les recompter.
> Une solution qui ne fait que compter les votes, en les oubliant
> apr�s, ne peut pas �tre satisfaisante � mon avis
> (car susceptible � des attaques de type DoS)

L'id�e que j'avais dans une analyse en cour et d'utiliser un identificateur de 
votant unique pour un vote. Cette id assure une tracabilit� du vote pendant 
le processus et permettrai m�me sous le contr�le d'une autorit� qq de faire 
saut� l'anonymat.

> Pour compter, on peut fortement augmenter la s�curit� en faisant
> comme dans les avions modernes, contr�l�s par ordinateurs:
> 2 ordinateurs diff�rents, avec des architectures diff�rentes
> et des syst�mes d'exploitation diff�rents, sur lesquels tournent
> des programmes diff�rents, con�us par des �quipes diff�rentes,
> avec des langages (et compilateurs) diff�rents...
> Et en cas de litige, un arbitrage est donn� par un troisi�me
> ordinateur, diff�rent bien s�r...

C'est ce que j'ai d�crit dans ma premi�re r�ponse en indiquant que l'on 
pouvait utilis� plusieurs cha�nes de traitements diff�rents pour la m�me 
information.

> Paranoia, oui. Mais qu'est-ce qui coute le plus cher ?
> Un nouveau programme sur un nouvel ordinateur, ou la
> cr�dibilit� du syst�me de vote ?

Pour la cr�dibilit� j'avais pens� � inclure dans les protocoles de test 
d'utiliser des pseudo votation avec le m�me syst�me ou le votant pourait 
contr�ler si son vote �tait bien comptabilis� au bonne endroit en fin de 
cha�ne. D'ailleur rien n'emp�che d'offrir cette option dans le vote r�el en 
diffusant une liste des id des votants ayant vot� oui ou non pour tel chois 
ou tel personne si le votant le d�sire.

> Je serais plus prudent. La probabilit� est surement ridicule
> quand on teste en quelques microsecondes, mais elle ne l'est
> peut-�tre plus autant quand un programme r�side en m�moire
> plusieurs heures (10^10 fois plus).
> Tous les utilisateurs de CCD avec des tr�s longs temps de poses
> (minutes ou heures) vous diront les probl�mes caus�s par les
> rayons cosmiques. Et quand on dit "rayons cosmiques", cela
> inclut la radioactivit�, artificielle ou naturelle. Y compris
> la radioactivit� r�siduelle des c�ramiques encapsulant les puces.

Cela doit pouvoir �tre quantifiable en attribuant des valeurs donn�es dans une 
partie de la m�moire et de contr�ler p�riodiquement afin de d�tecter un 
changement, bon avec de la ECC la probabilit� que deux 2 bits changes entre 
deux acc�s � un byte et certainement n�gligeable.

> Cela dit, c'est toujours une explication trop facile des experts
> face � cette erreur de vote.

C'est des rigolos.

> Mais de toute fa�on, la s�curit� du vote, comme la s�curit�
> en g�n�ral, est une chaine qui n'est pas plus forte que
> son maillon le plus faible.
> Et le maillon le plus faible sera toujours chez les citoyens:
> apr�s la g�n�ralisation du vote �lectronique,
> combien de temps faudra-t-il pour voir appara�tre un worm
> s'installant discr�tement en m�moire et hookant les messages
> Windows pour transformer les oui en non ou l'inverse le jour J ?
> Faudra-t-il tester la configuration d'o� le vote est �mis
> pour le valider ? Ou s'accomoder d'un pourcentage de votes
> pollu�s par des virus ?

C'est pour cela que j'ai propos� qu'une confirmation du vote se fasse par 
t�l�phone. Par ailleur rien n'emp�che de compliquer la vie des "worm" en 
utilisant des astuces comme l'utilisation de label de champs sous forme 
d'image, de nom de champs variables pour la m�me donn�e. On peu m�me propos� 
un programme de contr�le sp�cifique permettant de sniffer le r�seau et 
affichant le vote r�ellement envoy� au serveur web.

> Il me semble qu'on va vers des probl�mes pas tristes...

C'est sur mais il doit �tre possible d'arriver � une solution permettant 
d'assurer une fiabilit� permettant son exploitation. Le tout est de savoir si 
le coup et le mode d'utilisation ne serai pas dissuasif.

A+
Martial Guex

_______________________________________________
gull mailing list
[EMAIL PROTECTED]
http://lists.alphanet.ch/mailman/listinfo/gull

Répondre à