Bonjour Je suis pas cryptologue donc j'ai peut etre une vision simpliste des choses, cependant il me semble que si les votes sont mémorisés uniquement pour la modification ultérieur du vote, cad qu'on on veut juste stocker l ancien vote pour lors de la modification d'un vote éliminer l'ancien de la synthèse des votes et ajouter le nouveau vote : i.e. synthèse=synthèse-ancien_vote+nouveau_vote
il y a une solution simple. Si les hypothèses précédents sont fausses alors désolé pour le bruit, vous pouvez arreter de lire ici. Solution : Le server stocke trace l'ancien vote sous la forme suivante : 1) un hash (fonction non reversible) du vote en clair 2) le vote crypté avec une clé qu'il ne connait pas et connue uniquement par le client qui vote. Lorsque le client vote : il envoie un vote en clair + le vote crypté par ses soins et le serveur hashe le vote en clair et en garde une trace pour vérification. et le serveur stocke le vote crypté, que seul le client est capable de decrypter (le serveur ne connais pas la clé). Le client au choix : oublie son vote (le plus sage) ou le stocke. Lorsque le client revote : s'il ne se souvient plus de son ancien vote, il peut demander au serveur la version cryptée de celui-ci et en déduire la version en claire. il envoie alors avec son nouveau vote, et son ancien vote. Le serveur peut verifier la conformité de l'ancien vote à l'aide du hash qu'il a mémorisé précedemment. Si l'ancien vote est erroné il rejette la modification du vote sinon il procéde à la modification demandée. Pour résumé : L'info de vote est partagé entre le client et le serveur, le client stocke une clé, le serveur stocke des données cryptées qu'il ne peut décrypter, en revanche il peut verifier que l'ancien vote en clair qu'on lui présente est bien le bon grace au hash mémorisé. Le seul désavantage est que par principe les votes ne sont pas accessibles sans l'aide du active client, qui doit donc se souvenir de sa clé et décrypté , sinon il ne peut jamais revenir sur son vote. Par exemple en cas de changement d'algorithme de vote on ne peut retraiter les anciennes questions sans que le client se reconnecte et accepte de décoder tous ses anciens votes et de les resoumettres. Si la clé est oublié (volontairement ou non), il a juste à changer de clé et pourra voter et revoter sur de nouvelles questions mais pas sur les anciennes pour lequel son vote restera définitf. Ce schéma marche avec n'importe quoi d'autre que des votes, et nécessite en l'aide du client (c'est lui qui décrypte) pour accéder au donnée de la base, et on peut vérifier que le client ne racconte pas de crack grâce au hash (que seul le serveur connait). Si ce schéma interresse quelqu'un, je suis ok pour en discuter les détails notamment comment s'assurer que la fonction de hash n'est en pratique pas inversible. parce que si le vote à un nombre de possibilité restreint on peut essayer tous les vote possible et voir si le hash correspond, il y a aussi des solutions triviale pour contrer ce type d'attaque. Bon je répéte que la crypto c'est pas mon domaine, donc si un crypto rigole en lisant mon texte qu'il hésite pas à me faire remarquer mes erreurs. Bonne journée Frederic Lehobey wrote: >Bonjour, > >On Wed, May 17, 2006 at 03:02:34PM +0200, Vincent Becker wrote: > > > >>J'ai une deuxième question que je mets dans un deuxième message parce >>qu'elle n'a rein à voir avec la précédente :-) >> >> > > Bonne idée. Messages courts. Réponses faciles. :-) > > > >>J'aurais voulu savoir quel est le moteur de base de donnée utilisé par >>DemExp et si celui-ci peut être lu autrement que par le client. En >> >> > > Il n'y en a pas. C'est stocké dans du fichier XML (voir le code >source -- qui est documenté -- pour plus de détails) pour l'instant. > > > >>effet, comme le programme se souvient des votes de chacun, cela veut >>dire qu'il construit une base d'opinions rattachées aux personnes ce >>qui, à large échelle et dans de mauvaises mains, pourrait conduire à >>d'énormes problèmes. >> >> > > Oui. Actuellement, seul l'administrateur (David -- et éventuellement >les administrateurs du RAS --) a la possibilité technique de lire la >base. Mais si le site du RAS est piraté, la base est stockée en clair. > > > >>Quelle est la politique de sécurisation des données de DemExp à ce sujet? >> >> > > Alors que nous sommes très conscients de ces problèmes et vigilants >sur leur résolution, il n'y a pas encore de politique propre de >sécurisation. D'où le « Vote is not secured » ! Le serveur actuel, >conformément à nos « plans » est un *prototype* ayant pour but de >valider la faisabilité techniques des idées derrière l'expérience >démocratique. > > Avec ce prototype (qui prend son temps à mûrir...) nous souhaitons >attirer (une fois que des fonctionnalités prévues dans le plan initial >comme la délégation et l'internationalisation seront présentes) des >contributeurs pour mettre en place proprement la crypto et le >reste. Nous sommes vraiment encore en phase de qualification / >développement du prototype (qui tient déjà la route par rapport à des >projets plus ou moins équivalents). > > Depuis 3 ans nous avons déjà essayé d'intéresser des cryptographes à >nos problématiques (intéressantes mais spécifiques), sans succès >jusque-là (beaucoup de personnes dans le monde du logiciel libre ont >entendu parler de demexp par les conférences passées de David ou >autres contacts directs, elles ne nous ont pas forcément rejoints pour >autant). > > Bref nous sommes vraiment ouverts à toutes contributions. > >Expérimentalement, >Frédéric Lehobey > > -- Liste de discussion demexp-fr. Pour se désinscrire, cliquer sur le lien ci-après. mailto:[EMAIL PROTECTED]
