Je déteste les chèvres. Aussi bien vivantes que dans l'assiette. Je ne sais pas exactement pourquoi, et je ne vais pas m'avancer à faire de la psychologie de bazar en parlant de la préparation à un dictée d'un extrait de La chèvre de monsieur Seguin au primaire, où mon père m'a fait faire la dictée autant de fois que fautes commises en tout, car je suis certaine que ça n'explique. Bref, a fortiori, je hais les boucs, ce qui est une raison tout à fait valable et suffisante pour s'intéresser aux e-books.

Ça fait depuis très longtemps que l'idée d'avoir un liseur¹ de livres électroniques me courait dans la tête. Enfin, elle s'y promenait paresseusement.

J'ai commencé par un scepticisme très marqué, comme j'ai par défaut envers tous les e-quidlibet. Parce que commencer avec quelque chose qui marche plutôt bien, et le rendre dépendant d'une alimentation électrique, ça ne commence pas très bien. Le rendre beaucoup plus sensible aux conditions extérieures, en particulier l'humidité et les chocs, n'arrange rien non plus. Il faut donc débarquer avec une bonne quantité d'avantages pour pouvoir commencer à mériter mon attention. Non, être à la mode ne compte pas comme un avantage, si ça doit compter ce serait plutôt négativement.

Le premier argument auquel j'ai été sensible, c'était la recherche de texte. Et c'est typiquement le truc qu'il me manque presque à chaque fois que j'interagis avec du papier.

Le deuxième a été l'encombrement. Ma liste de lecture atteste à quel point je lis peu, alors que ce point fait partie de mes bonnes résolutions de nouvel an (ou pas) depuis une bonne décennie. Je continue de (faire semblant de) garder espoir de pouvoir arranger ça. Bref, j'arrive quand même à plusieurs dixièmes de mètre-cube de livres, et je trouve que ça finit par faire beaucoup.

Il n'y a pas vraiment d'autre avantage qui s'est jeté sur moi, donc cette idée a tranquillement continué son chemin dans mon esprit.

Et puis à Noël dernier, ma moitié a reçu un Kindle, et ça a un peu caféiné cette idée.

Et puis depuis quelques mois je me suis dit que ça pourrait être sympa' de pouvoir lire dans le bain, et je n'arrive pas à trouver assez de confiance en moi pour le faire avec un livre en papier. Alors que mettre autour d'un liseur un sac hermétique (genre ziploc) dans lequel j'ai confiance est un peu moins irréaliste.

Et puis la semaine dernière, pour une raison qui n'a absolument rien à voir avec les considérations récentes de la presse à ce sujet (en dehors du fait d'avoir réveillé cette idée de longue date), j'ai finalement craqué.

Je suis donc maintenant en possession d'un Cybook Odyssey de Bookeen. Je ne suis pas très au clair avec les raisons qui m'ont fait choisir celui-là plutôt qu'un autre, mais je rappelle à toutes fins utiles qu'ici c'est instinctive.eu, pas rationnelle.eu.

Je suppose que le côté « pas un des deux gros » a joué, et son esthétique probablement aussi, mais ça ne fait quand même raisonnablement pas le poids devant l'absence de recherche de texte, l'interface tactile (les boutons, c'est Bien™ (surtout au travers d'un ziploc)) et le manque de hackabilité.

Mais comme j'ai récemment fait plein de décisions rationnelles à l'encontre de mon instinct, il fallait bien que je me lâche un peu. Je vous préviendrai si un jour je le regrette.

En attendant, j'aime bien ce liseur.

Quelque chose s'est horriblement mal passé lors de la première connexion avec le FreeBSD de Yulai, et ça a tué le système de fichier dessus. Après des sueurs froides et de nombreuses réinitialisations de tas de trucs, j'ai pu remettre le jouet dans un état fonctionnel, au prix de tous les e-books préchargés offerts avec.

J'ai depuis pu l'essayer à la lumière du jour, sous éclairage artificiel, et à la lumière de ma lampe de chevet. Et ce avec le Cid, Cyrano de Bergerac, Just so Stories et le premier volume du manga Claymore.

Autant le texte passe très bien, autant le manga n'égale pas le confort du papier, et j'imagine que pour le reste des bandes dessinées ce serait encore pire. D'un autre côté, s'en tenir aux livres (en texte pur) est tout ce que j'en attendais.

Autrement j'ai retrouvé toute seule une bonne partie de cette liste de doléances, mais j'ai surtout été gênée par l'absence de recherche de texte, l'accès peu pratique au contenu de la carte microSD, et les difficultés pour sélectionner « tactilement » les liens (surtout lorsque la zone active est relativement petite et serrée à d'autres, par exemple un lien sur le texte « ePUB » parmi une liste d'autres formats).

Je suis donc contente d'avoir suivi mon instinct, en ne sachant probablement jamais si j'aurais plus aimé une autre solution plus raisonnable.

Maintenant la question ouverte est : ce livre électronique va-t-il réussir à augmenter la place de la lecture dans ma vie ?

Les paris sont ouverts…

Nous avons élu le leader du projet Debian, comme chaque année. Les résultats ont été proclamés le 15 avril (plus d'infos sur la page du vote).

Dix jours plus tard, Timo Juhani Lindfors publie une faiblesse dans le logiciel qui gère le vote et qui permet de casser le secret du vote, et ce pour tous les votes (dans la foulée : plouf l'anonymat du vote).

Pour ceux qui veulent jouer à la maison, une approximation du code source qui gère le vote est disponible. Ce n'est pas encore un paquet debian.

L'analyse du problème est amusante, et la morale en est essentiellement le titre de cette entrée. Dans la suite je ne fais que reprendre l'analyse de Timo Juhani Lindfors en y ajoutant mes propres commentaires.

Le token secret qui permet à chaque votant de vérifier que son vote a bien été pris en compte est constitué de la concaténation de l'instant auquel on prend en compte le vote (modulo 21 jours, cf. le fichier dvt-gack autour de la ligne 160) et de 8 caractères pris au hasard parmi les alphanumériques (soit 26+26+10 = 62 possibilités).

Si le vote est pris en compte à un moment parfaitement aléatoire dans cette période de 21 jours, et si les 8 caractères sont eux aussi pris au hasard uniforme, j'obtiens une borne sur l'entropie de ce token secret d'environ 69 bits. Notons déjà que le vote n'est ouvert que pendant 14 jours.

Première faiblesse: les votants ne choisissent pas leur instant pour voter de façon parfaitement aléatoire, et d'autre part l'utilisation d'un cronjob (toutes les 5 minutes) réduit encore plus l'ensemble des valeurs possibles pour ce timestamp.

Là où les choses s'effondrent, c'est dans le calcul des 8 caractères supplémentaires. Le script utilise la fonction rand de perl sans utiliser de graine particulière. Cette fonction utilise en interne drand48(), mais avec une graine de 32 bits uniquement. Comme il s'agit d'un générateur déterministe, la connaissance de ces 32 bits de graine suffit à prédire complètement la séquence des 8 caractères du token secret. On passe donc d'une entropie théorique d'environ 47 bits pour ces 8 caractères, à seulement 32 bits. En supposant que la machine n'est pas trop surchargée et que cron lance le script de vérification des votes toutes les 5 minutes exactement, on obtient maintenant une borne sur l'entropie d'environ 45 bits.

Une autre faiblesse amusante se trouve dans dvt-tally et concerne l'ordre dans lequel on affiche les votes. On commence par trier les votes par le nom réel du votant, puis on retire au hasard un nom dans cette liste pour l'afficher en premier, et ainsi de suite jusqu'à épuisement des votes. On affiche évidemment les votes masqués, mais l'utilisation de la même fonction rand sans initialisation explicite nous rend vulnérable à une attaque exhaustive. Et vu que l'anonymat du vote est déjà compromise, ce problème est juste la cerise sur le gâteau.

Quelles conclusions tirer de ce problème? Voici les miennes:

• même dans un monde idéal, l'entropie bornée par 69 bits pour le secret est insuffisante si on veut sérieusement protéger le vote individuel de chaque votant. On a longtemps recommandé 80 bits pour se placer au delà de ce qui est réaliste pour une attaque par force brute. L'amélioration des capacités de calcul amène l'ANSSI à recommander 128 bits pour résister au delà de 2020 (recommandation faite en 2010).
• l'utilisation du temps comme source d'entropie (car sa présence dans le token secret n'a pas d'autre usage) est discutable. Les évènements dépendants d'êtres humains n'ont pas tendance à se distribuer dans le temps avec l'uniformité voulue. Et si on s'attaque à mon vote à moi, il est plus raisonnable d'attaquer d'abord les instants auxquels je suis réveillés, que les autres. Si on ajoute à cela le fait que l'application ne maîtrise pas l'instant auquel elle tourne, car lancée par cron, l'utilisation du temps est simplement une mauvaise idée.
• utiliser un générateur de nombres aléatoires sans l'initialiser avec une graine revient à fermer les yeux et espérer que la voiture va magiquement éviter le mur (alors qu'on garde le pied à fond sur l'accélérateur).
• utiliser un générateur de nombre aléatoire déterministe pour des tirages successifs d'une quantité que l'on espère aléatoire est une mauvaise idée.

Ma suggestion pour corriger ces problèmes serait de calculer le token secret comme la représentation hexadécimale de 128 bits lus directement depuis /dev/urandom (ou son équivalent sur d'autres systèmes). Cela revient à un token secret de 32 caractères, ce qui reste raisonnable dans le contexte, et cela aligne la sécurité attendue dans la confidentialité de chaque vote avec les recommandations de la communauté crypto. Lire depuis /dev/urandom est raisonnablement rapide (et essentiellement négligeable dans la mesure où on vient de vérifier une signature RSA ou DSA) et suffisamment sûr aussi (et si on doute de /dev/urandom, je suppose qu'on peut jeter l'éponge sur ce système, car si le noyau n'est pas en mesure de fournir de l'entropie de qualité je me demande bien qui peut l'être).

Et pour finir, afficher les votes en triant selon le hash md5 (comme cela a été suggéré dans le fil de discussion).

Après presque 4 mois sans nouvelles, le nouvel épisode de YEP (n°739) est en ligne.

S'agit-il d'un évènement isolé ou les frémissements d'une reprise plus régulière de la publication? Je répondrais avec une de mes citations d'économiste préférée (attribuée à John Maynard Keynes) :

Demain, on ne sait pas.

Trop dur de lire la situation locale dans votre partie de Go?

Suivez donc le conseil de Bill.

J'ai été relativement surpris de constater que les tarifs des communications mobiles, avec ou sans contrat, sont significativement plus élevés ici (en Californie) qu'en France (en pleine effervescence due à Free quand je suis parti, mais cela reste vrai même en négligeant l'effet des offres Free dans le paysage français).

Et non seulement c'est plus cher, mais la qualité des communications voix est lamentable, et je ne suis pas impressionné non plus par les débits data.

Comment le service de téléphonie mobile peut-il être pire dans ce que je croyais être l'utopie de la concurrence libre et non faussée, que dans un pays économiquement arriéré où les ogres communistes mangent les petits enfants?

Une piste d'explication: ici on n'achète pas un téléphone nu (sans carte SIM), ou une carte SIM nue (sans téléphone) permettant d'accéder à un réseau. On achète majoritairement le combo. En France, on lie souvent les deux. Mais la règle ici, c'est de lier les deux commercialement et technologiquement. Les deux sont physiquement solidaires. Il ne s'agit pas d'un simple simlockage temporaire qu'une loi de protection du consommateur permettrait de déblocker au bout d'un certain temps. C'est juste soudé.

Du coup, l'utilisateur est bien plus captif ici qu'en France.

Cette entrée vous était présentée par le comité de soutien de la main invisible du marché.