Catégorie : dissimulation

Création d’objet et dissimulation des liens

Lors de la création d’un objet, quel qu’il soit, génère au minimum un lien de définition du hash de l’empreinte. Sauf que la création par défaut de liens peut perturber voir anéantir la dissimulation de la création de l’objet.

Certains liens peuvent être dissimulés au moment de la création ou à posteriori, mais le lien de l’empreinte doit rester visible sous peine de perturber la vérification des objets. Il est possible cependant d’anti-dater le champ date de ce lien pour lui retirer toute référence à une plage temporelle de création. Mais il restera et sera un marque d’association du créateur de l’objet si par ailleurs l’objet a un lien d’usage non dissimulé, y compris d’une autre entité.

Le lien d’annulation de suppression d’un objet est moins critique, si dissimulé il fonctionnera toujours.

Les autres liens définissants des propriétés de l’objet peuvent être aussi dissimulés sans problème.

Le code de la bibliothèque nebule en php intègre ces modifications pour les objets, les groupes et les conversations. Seules les entités ne sont pas concernées, leurs contenus ne pouvant être protégés, dissimuler les liens n’a pas de sens.

Penser à supprimer le lien de l’empreinte reviendrait à faire apparaître l’algorithme dans le lien… et donc à changer significativement la forme des liens et le fonctionnement de nebule.

Définition des groupes

La gestion des groupes est entièrement revue et corrigée dans la bibliothèque nebule en PHP orienté objet et dans les applications (sylabe, klicty, messae).
Une fois les applications mises à jour, les groupes existants disparaîtront.

Cet article invalide la définition de groupe telle que définit dans l’article Définition des groupes du 14/01/2016.

Cette implémentation des groupes sera aussi utilisée pour les conversations contenant des messages.

OG / Groupe

Le groupe est un objet définit comme tel, c’est à dire qu’il doit avoir un type mime nebule/objet/groupe.

Fondamentalement, le groupe est un ensemble de plusieurs objets. C’est à dire, c’est le regroupement d’au moins deux objets. Le lien peut donc à ce titre être vu comme la matérialisation d’un groupe. Mais la définition du groupe doit être plus restrictive afin que celui-ci soit utilisable. Pour cela, dans nebule, le groupe n’est reconnu comme tel uniquement si il est marqué de son type mime. Il est cependant possible d’instancier explicitement un objet comme groupe et de l’utiliser comme tel en cas de besoin.

Le groupe va permettre de regrouper, et donc d’associer et de retrouver, des objets. L’objet du groupe va avoir des liens vers d’autres objets afin de les définir comme membres du groupe.

Un groupe peut avoir des liens de membres vers des objets définis aussi comme groupes. Ces objets peuvent être vus comme des sous-groupes. La bibliothèque nebule ne prend en compte qu’un seul niveau de groupe, c’est à dire que les sous-groupes sont gérés simplement comme des objets.

Continuer la lecture de Définition des groupes

Référencement par défaut

Suite des articles Références d’images, Propriété d’un objet et référence par rapport à un objet et Objet de référence contre suivi du graphe des mises à jours.

La recherche par référence se fait par rapport à un contexte. Ce contexte est définit par le champ méta des liens.

Pour les images, le contexte est définit par un objet contenant ‘nebule/objet/image/reference‘, soit l’ID 1ca96e517fc6ccca45080244c594dd777dc5d3bde0f872f961c28a4e9749ba82.

Pour la bibliothèque nebule en php, le contexte est définit par un objet contenant ‘nebule/objet/interface/web/php/bibliotheque‘, soit l’ID 4297b53cfab1fc41f7820a47d1c21fbf7d0ab83a5ee4f94331c1e0ba1cbb99cf.

Pour les applications, le contexte est définit par un objet contenant ‘nebule/objet/interface/web/php/applications‘, soit l’ID e0150ff815bd5343034ff025624d20f723e2293842ab4eaedabda1ea5790e66b.

Etc…

Mais il n’y a pas que des usages dans des contextes techniques qui sont à prendre en compte. On peut permettre à l’utilisateur de gérer ses références. Pour cet usage un objet de référencement ‘nebule/reference‘ est dédié, soit l’objet 7339ea8fd26c67c3857ca94f9bac47d3841a3b75e799609720b8cc739732a161. La version publique actuelle de sylabe ne le reconnaît pas encore mais c’est le cas dans la version en cours de développement.

La reconnaissance des liens pour les références ne va pas être faite tout à fait de la même façon en fonction de l’usage. On doit être plus restrictif sur les références concernant les applications que pour celles de l’utilisateur. On va se base sur un calcul social de tri différent.

Et pour faciliter la gestion des références par l’utilisateur, un module dédié est en cours de développement. Il est dédié aux utilisateur donc il se base par défaut sur l’objet de référencement dédié aux utilisateurs mais peut très bien se baser sur d’autres objets de référencement.

Enfin, un lien de référence pourra être dissimulé.

Anonymisation/dissimulation des liens

Il y a déjà une série d’articles en 2012 sur la Liaison secrète (et suite), puis en 2014 sur l’Anonymisation de lien (et correction du registre de lien), et enfin en 2015 sur la Dissimulation de liens, multi-entités et anonymat et l’Exploitation de liens dissimulés.

On trouve dès 2015 un schéma d’implémentation d’un lien dissimulé (offusqué) et le mécanisme cryptographique utilisé :

20150627-nebule-schema-crypto-lien-c

Mais la mise en pratique ne suit pas alors que la bibliothèque nebule en php orienté objet est prête à reconnaître les liens dissimulés.

Parce qu’en pratique, il ne suffit pas juste de générer ces liens et de les lire, il faut aussi les stocker de manière à pouvoir les retrouver tout en gardant des performances acceptables lors du passage à l’échelle.

Comme l’anonymisation attendue nécessite la mise en place d’un minimum de déception vis-à-vis d’un adversaire, il n’est pas possible de stocker les liens dissimulés dans les liens des objets concernés. Cela casserait presque immédiatement la confidentialité du lien dissimulé parce que les objets ont souvent chacun des rôles propres et donc des places privilégiées dans les liens qui servent aux usages de ces objets.

Les deux seules informations que l’on ne peut dissimuler sans bloquer le transfert et l’exploitation des liens dissimulés, c’est l’entité signataire et l’entité destinataire (si différente). Donc le stockage ne peut se faire que de façon connexe à des deux entités. Si ce n’est pas le cas les liens ne pourront pas être retrouvés et utilisés lorsque nécessaire.

Prenons le cas d’une entité qui décide de dissimuler la grande majorité de son activité, elle va donc dissimuler tous les liens qu’elle génère (ou presque). Là où habituellement le stockage des liens aurait été réparti entre tous les objets concernés, du fait de la dissimulation ils vont tous se retrouver attachés à un même objet, l’entité signataire. Cela veut dire que pour extraire un lien de cette entité il va falloir parcourir tous les liens. Cela peut fortement impacter les performances de l’ensemble.
Et c’est aussi sans compter le problème de distribution des liens parce que l’on les distribue aujourd’hui que vers les objets source, cible et méta… et non sur les entités signataires. L’entité destinataire est dans ce cas naturellement desservie directement, est-ce un problème si l’entité signataire ne l’est pas ?
Une autre méthode pourrait consister à créer un objet de référence rattaché à l’entité et spécifiquement dédié à recevoir les liens dissimulés. Mais les liens dissimulés ne contenant pas cette objet de référence, on doit créer un processus plus complexe pour la distribution des liens tenant compte des entités signataires et destinataires.
On peut aussi mettre tous les liens chiffrés dans les liens d’un objet c puisque c’est le type de lien après dissimulation. Mais cela veut dire que tous les liens dissimulés de toutes les entités se retrouvent au même endroit. On ne fait que déplacer le problème de la longue liste des liens à parcourir.
Enfin on peut rester sur une des premières idées qui consiste à stocker des liens dissimulés non plus dans la partie du stockage dédié au liens mais directement dans un objet. Le défaut de cette méthode est qu’à chaque nouveau lien dissimulé généré, il faut refaire un nouvel objet avec une novelle empreinte… et donc un nouveau lien pour le retrouver.

On rejoint le problème de la persistance des données dans le temps, de leurs objets et liens associés. Une solution déjà proposée, mais non implémentée, consiste à organiser un nettoyage par l’oubli des objets et des liens dans le temps en fonction d’une pondération.

Pour commencer à expérimenter, les liens dissimulés seront stockés uniquement avec l’entité destinataire. Cela ne remet pas en cause la distribution actuelle des liens. On verra à l’expérience comment gérer un flux massif de liens et son impact sur les performances.

Messages et protection

Une protection des messages basés les objets et liens de nebule peut être mise en place. Cette protection ne vise pas à dissimiler la présence d’un message mais à dissimuler son contenu. La dissimulation de la présence d’un message, plutôt nommée offuscation, est un autre sujet à part entière.

Mais cette protection peut ne pas être efficiente et elle peut se retrouver mise à mal du fait du fonctionnement même des liens de chiffrement (type k). Le lien de chiffrement va associer l’empreinte du message en clair avec l’empreinte du message chiffré. Hors un message de petite taille va avoir une forte probabilité avec le temps d’être (re-)créé par ailleurs et donc de dévoiler le contenu d’un message protégé. Et même pour un message plus conséquent, si il est partiellement ou complètement redécoupé en sous-objets via des liens de subdivision (type s), peut voir une partie de son contenu protégé dévoilé. La subdivision peut être par ailleurs légitime dans le cas d’un pré-découpage par mots pour la recherche sur mots clés.
La protection doit donc être adaptée dans le cas de la messagerie.

L’ajout d’un sel avant chiffrement ne résout pas le problème puisqu’il ne masque pas le lien entre le texte clair et chiffré. Par contre il est peut-être possible de pré-saler l’objet à chiffre et ne le reconnaître que sur son empreinte pré-salée.
A travailler…

PFS sans connexion

La confidentialité persistante (Perfect Forward Secrecy – PFS pour les intimes) permet lors d’échanges entre personnes via un support protégé d’oublier le contenu des échanges précédents. Lorsqu’elle est bien implémentée, il est impossible de pouvoir reconstituer les échanges précédents d’une « conversation », y compris pour les personnes concernées.

Lors de la compromission du moyen de communication, seules les conversations en cours sont accessibles. Les précédentes conversations sont définitivement inaccessibles y compris pour un adversaire qui aurait enregistré tous les échanges chiffrés et obtiendrait par la force le compte d’un utilisateur.

La meilleur méthode pour arriver à ce résultat est d’utiliser un secret de session partagé entre les personnes qui communiques, négocié en début de conversation et volontairement oublié en fin de conversation. La négociation peut être faite notamment via un échange de type Diffie-Hellman (DH).

La PFS a donc principalement deux contraintes. Il faut échanger un secret temporaire avec ses correspondants. Et il faut que ce secret soient privés, c’est à dire stockés uniquement en interne sur les machines destinataires.

De par sa conception acentrée et potentiellement non directement inter-connecté, nebule ne permet pas la mise en place directe d’une forme de PFS. Fondamentalement, nebule permet de gérer de l’information et non des connexions. La non connexion directe entre les correspondants empêche une négociation préalable instantanée d’un secret partagé type DH. Ensuite, toute la protection de la partie privée des entités repose sur le chiffrement des objets et l’offuscation des liens, mais tous les liens et objets ainsi protégés sont partagés publiquement et donc enregistrables. Il n’est pas possible de se baser sur ces mécanismes de protection pour la PFS.

Il existe peut-être un moyen d’implémenter une PFS sûr dans nebule mais au prix d’un grand nombre d’objets à synchroniser, à voir…

Entité multi-rôles

D’un point de vue robustesse et sécurisation des clés cryptographiques, il est recommandé de séparer les rôles des différentes clés utilisées. Une clé crypto ne doit avoir qu’un seul usage, c’est à dire un seul rôle. Dans l’implémentation des entités dans nebule, les entités étant des clés cryptographiques avec de multiples rôles, il va falloir les scinder.

Les rôles les plus fréquents sont :

  1. L’authentification. C’est utilisé pour le déverrouillage des entités.
  2. La signature. Tous les liens sont signés.
  3. Le chiffrement. Il intervient dans la protection des objets et la dissimulation des liens.

Toutes les clés liées à des rôles peuvent être rattachées à une clé cryptographique asymétrique principale et reliées à celle-ci par des liens. Il est possible par la suite d’étendre sans problème les rôles comme par exemple les rôles d’autorités locales.

La segmentation des clés par rôles impose la gestion de multiples clés pour une entité, notamment lors de la synchronisation sur différents supports. Mais elle permet en cas de compromission d’une clé de limiter l’étendu des dégâts.

Définition des groupes

Dans le cadre de la recherche sur l’implémentation des groupes dans nebule, voir 1 2 3 4 5, deux nouveaux objets réservés ont été ajoutés :

  • nebule/objet/groupe
  • nebule/objet/groupe/ferme

Le groupe

Il a été décidé de rattacher explicitement le groupe aux objets, et donc aussi aux entités notamment. Mais la notion de groupe peut être vu comme plus globale.

Si on reprend par exemple l’objet réservé nebule/danger, les objets qui lui sont liés deviennent de fait un groupe des objets à éviter. Il suffit donc de lier un objet à un autre objet pour créer un groupe. Cependant cela n’est pas très pratique puisque l’on ne peut rechercher que des groupes pré-définis à l’avance et communément acceptés. Cela marche bien pour quelques groupes avec des fonctions biens précises et universellement reconnues, et pas plus.

Fondamentalement, le groupe est la définition d’un ensemble de plusieurs objets. C’est à dire, c’est le regroupement d’au moins deux objets. Le lien peut donc à ce titre être vu comme la matérialisation d’un groupe. Le groupe met en relation des objets vis-à-vis d’une référence. C’est la référence qui identifie le groupe. Dans le cas de notre objet réservé nebule/danger, c’est cet objet réservé qui est la référence du groupe. Par simplification, l’objet de référence peut être assimilé comme étant le groupe.

Tout objet peut ainsi devenir la référence d’un groupe. Cela n’est pas sans poser un gros problème pratique. Puisque tout objet peut être un groupe, comment fait-on pour s’y retrouver dans l’immensité des groupes disponibles ?
Pour simplifier le problème, nous allons considérer les liens comme étant des groupes directs ou explicites. Et nous allons considérer les relations de deux liens ou plus comme étant des groupes indirectes ou implicites. Ces groupes indirectes sont centrés sur un et un seul objet de référence. Si nous prenons par exemple comme référence l’objet réservé nebule/objet/type, nous avons un groupe indirecte qui va contenir tous les objets de même type mime.

Nous allons à partir de maintenant considérer comme groupe uniquement les groupes indirectes.

Mais cela fait encore beaucoup trop de possibilités en pratique pour que la notion de groupe n’ai un intérêt pour gérer les objets. Nous allons en plus restreindre la notion du groupe, et donc son exploitation dans nebule, à l’objet vers lequel un lien explicite est créé avec les objets. Ce lien explicite est un lien de type l avec comme objet meta l’objet réservé nebule/objet/groupe ou nebule/objet/groupe/ferme.

Groupe ouvert ou fermé

L’exploitation des objets d’un groupe nécessite de pouvoir lire et vérifier les liens qui unissent les objets au groupe. Ces liens peuvent être générés par différentes entités, le traitement social des liens déterminera pour une entité donnée quels sont les objets reconnus dans le groupe ou pas. Ce processus est avant tout un traitement pour reconnaitre ou non les objets d’un groupe ouvert.

Pour un groupe fermé, la reconnaissance des objets du groupe n’est plus déterminée par le traitement social des liens. Ne sont reconnus les objets comme appartenant au groupe fermé que ceux dont le lien est signé par l’entité qui a créé le groupe. Dans le cas d’un groupe fermé, les liens générés par une autre entité pour ajouter des objets au groupe ne sont pas pris en compte.

Si il est possible de créer un groupe ouvert avec un objet de référence donné, le même objet de référence peut aussi servir pour un groupe fermé. Dans ce cas, lors du traitement, le groupe ouvert et le groupe fermé apparaissent comme deux groupes distincts. Si plusieurs entités créent des groupes ouverts avec le même objet de référence, un seul groupe est affiché et regroupe tous les groupes ouverts. Si plusieurs entités créent des groupes fermés avec le même objet de référence, il faut exploiter et afficher tous les groupes fermés comme des groupes indépendants.

Un groupe fermé doit toujours être accompagné son l’entité créatrice lors de l’affichage.

Groupe public ou privé

La distinction entre un groupe public et un groupe privé, c’est la visibilité de celui-ci pour les entités tierces. Si tous les liens qui relient les objets au groupe sont dissimulés, alors le groupe est privé et seuls les entités qui peuvent voir ces liens ont accès au groupe.

Cependant, si une partie des liens ne sont pas dissimulés ou si ils sont rendus publics, alors le groupe devient partiellement public.
Les liens, même dissimulés, sont complètement manipulables par toute entité qui y a accès, ainsi en terme de sécurité on peut dire qu’un groupe privé est un groupe public qui s’ignore. Mais ce n’est pas forcément un problème, si une entité A crée un groupe fermé et privé, alors le fait qu’une autre entité B crée un même groupe (même référence) ouvert et public ne rend pas pour autant public le groupe de l’entité A.

Groupe actif ou passif

Un groupe est par défaut passif. Il devient actif lorsqu’il devient capable de réaliser des actions, c’est à dire de signer des liens. Le seul objet capable de signer un lien est une entité, ainsi un groupe actif est un groupe dont l’objet de référence est une entité.

Si le secret de cette entité de référence du groupe n’est connu que d’une seule autre entité (entité maitresse) alors c’est un groupe actif fermé. Si cette entité de référence du groupe a plusieurs entités maitresses alors c’est un groupe actif ouvert.

Un groupe actif ouvert peut aussi être privé si tous ses liens sont dissimulés. Il devient semi-public ou public si une des entités maitresse dévoile tout ou partie des liens du groupe. De la même façon, une entité peut ajouter d’autres entités au groupe, c’est à dire partager le secret de l’entité de référence du groupe. En terme de sécurité, un groupe actif ouvert privé est souvent un groupe actif ouvert public qui s’ignore.

De fait, toute entité piratée devient un groupe actif ouvert, même si le secret de l’entité n’est pas rendu public.

Groupe d’entités

Un groupe d’entité est un groupe dans lequel on ne considère que les objets qui sont des entités. Les autres objets sont ignorés. Lorsque ce groupe n’est plus vu comme un groupe d’entités, tous les objets sont pris en compte et les entités sont gérés comme des objets. La distinction se fait donc uniquement sur le type d’objet que l’on attend du groupe au moment de l’exploiter.

Graphe de groupes

Lorsque l’on a un groupe qui est lié à un autre groupe, comme doit-on l’interpréter ?
Cela crée un graphe de groupes. Il est possible soit d’ignorer les sous-groupes dans un groupe ou au contraire de résoudre le graphe pour en exploiter tous les objets. Dans le cas de la résolution du graphe, on retombe sur les problèmes classiques de la résolution d’un graphe.

Le graphe de groupe peut aussi dans certains cas avoir un traitement convenu. Cela peut être appliqué à la gestion des options ou des droits dans une application. On va ainsi lier des groupes d’entités avec des groupes d’options et/ou des groupes de droits. Dans ce cas on ne parcours le graphe que de façon simple et non ambigüe.

NÅ“ud

La notion de nœud est concurrente de la notion de groupe. Sauf usage nouveau et différencié, le nœud va disparaitre de nebule.

Sondages et votes

Dans un article La Suisse pourrait imposer l’open-source pour le vote électronique de Numerama, il est de nouveau question de la mise à disposition du code source du programme sous forme de logiciel libre.

L’avenir du vote électronique ne fait aucun doute, seule sa réalisation pose problème aujourd’hui. Beaucoup de débats comparatifs et contradictoires ont lieux vis-à-vis de la pertinence du vote électronique et de la confiance que l’on peut apporter aux machines de vote et au processus dans son ensemble. Ces débats peuvent paraître très conservateurs mais ils sont néanmoins nécessaires puisque le vote est un acte fondamental de nos démocraties, c’est le moyen d’expression de chacun d’entre nous.

La confiance en ce genre de machine de vote et du code qui l’anime ne peut être assurée sans l’ouverture du code à minima en lecture. Il faut aussi connaître précisément l’environnement de compilation et d’exécution pour le code soit parfaitement reproductible. Et bien sûr, il faut être sûr ce c’est bien ce code qui a été utilisé et pas un autre.
Invoquer le secret industriel sur du code pour un processus parfaitement connu et un enjeu majeur de démocratie, c’est particulièrement malhonnête. Tout au plus une société éditrice peut-elle demander un droit de paternité et une restriction de commercialisation à son seul bénéfice. Mais il suffit à l’état qui fait la commande du code de demander, et payer, explicitement la libre diffusion ou la libéralisation complète du code.

Le code doit être capable dans son ensemble de permettre la centralisation des votes, l’anonymisation des électeurs ainsi que la vérification en temps réel et à postériori du décompte des votes. L’authentification de l’utilisateur devrait être le principal problème mais il apparaît que c’est en fait le décompte et sa vérification qui interpellent le plus souvent les détracteurs du vote électronique.

Un vote a un point de départ dans le temps et une fin à partir de laquelle le décompte des votes est considéré comme définitif.

L’anonymisation est aussi un problème pour la vérification de conformité du vote à postériori puisqu’elle casse le lien sûr entre le votant et le vote unitaire. On peut ainsi affirmer que le votant à voté (il a posé un papier et signé le paraphore) mais on ne peut pas le prouver à postériori (était-ce vraiment lui).
La capacité de multi-entité et la dissimulation de liens dans nebule permettent de résoudre ce problème.

Voici un scénario possible de vote avec les objets et liens de nebule :

  1. Pour un vote, une entité maîtresse du vote est générée. Elle est explicitement reconnue par les autorités comme telle. Son seul rôle est de générer les jetons de vote et de les attribuer aux électeurs.
  2. L’entité maîtresse du vote va générer autant d’objets jetons qu’il y a de votants. Ces jetons sont aléatoires et n’ont pas de relation directes avec les électeurs. Chaque jeton est en fait la partie publique d’un bi-clé cryptographique (RSA par exemple). La clé privée de chaque jetons est protégé par un mot de passe stocké dans un objet protégé par et pour l’entité maîtresse (dans un premier temps).
  3. Le jeton est en fait l’entité qui réalisera le vote via la clé privée. Chaque vote peut être vérifié par rapport au jeton, c’est à dire la clé publique.
  4. Pour chaque objets de clés privées de chaque jetons, l’entité maîtresse va partager le secret de chiffrement de l’objet contenant le mot de passe. Le lien entre objet chiffré et objet non chiffré est dissimulé, c’est à dire que c’est un lien de type c masquant le vrai lien.
  5. La clé privée de l’entité maîtresse est détruite. Il n’est ainsi plus possible de retrouver l’intégralité des relations en les jetons et les électeurs mais il est possible de vérifier que tous les électeurs ont reçus un lien dissimulé et de vérifier tous les jetons réalisant le vote.
  6. Pour un vote, une entité de décompte du vote est générée. Elle est explicitement reconnue par l’entité maîtresse Son seul rôle est de recueillir et de valider les votes. La période de vote démarre.
  7. L’électeur, c’est à dire l’entités votantes, va récupérer auprès de l’entité maîtresse du vote l’intégralité des jetons et des clés privées associées (et pas juste son jeton). Il va ainsi obtenir tous les liens dont le lien dissimulé le concernant. Via le lien dissimulé, il va savoir quel est la clé privée du jeton que l’entité maîtresse lui a attribué. Disposant de cette information il peut déprotéger à son profit l’objet contenant le mot de passe de la clé privée du jeton.
  8. L’électeur, mettant à profit la clé privée du jeton, peut réaliser un ou plusieurs votes, seul le dernier est pris en compte. Le vote consiste en un lien entre le jeton et le choix de vote dans le contexte de l’entité de décompte du vote (champs méta).
  9. L’entité de décompte du vote vérifie régulièrement auprès de tous les électeurs la présence de liens dont elle est le contexte. au fur et à mesure de la récupération des liens, elle se les approprie (signature du lien de vote).
  10. A la fin de la période de vote, la clé privé de l’entité de décompte du vote est détruite. Plus aucun vote ne peut être ajouté, modifié ou supprimé. Les votes comptabilisés sont ceux qui ont été signés par l’entité de décompte du vote.
  11. L’électeur qui souhaite rendre publique son vote a juste à prouver qu’il dispose du jeton en utilisant sa clé privée pour autre chose que le vote en relation avec sa véritable entité. Il peut aussi révéler le lien dissimulé que lui avait généré l’entité maîtresse du vote.

Un des aspects des liens dissimulés est qu’il est possible de les dissimuler pour plusieurs entités. Ainsi il est possible de générer une entité d’audit du vote à qui l’entité maîtresse partagera les liens dissimulés, de façon également dissimulé.L’entité d’audit devient capable à postériori de vérifier la bonne association entre jetons de vote et électeurs sans être elle-même capable d’émettre de nouveaux jetons.

Le sondage est moins contraignant et surtout peut être à choix multiples.