New articles !

content/crypto/pgp-problemes.rst

@@ -0,0 +1,75 @@
+Les problèmes de PGP
+####################
+
+:date: 2015-05-25
+:headline: Quels sont les soucis liés à PGP, que faire ?
+
+.. epigraph::
+
+  Flip a bit in the communication between sender and recipient and they will
+  experience decryption or verification errors. How high are the chances they
+  will start to exchange the data in the clear rather than trying to hunt down
+  the man in the middle? 
+
+  -- http://secushare.org/PGP
+
+Une fois passé l'euphorie du "il faut utiliser PGP pour l'ensemble de nos
+communications", j'ai réalisé lors de discussions que PGP avait plusieurs
+problèmes, parmi ceux-ci:
+
+- Les *meta données* (y compris le champ "sujet" de la conversation) sont quand
+  même échangées en clair (il est possible de savoir qu'un message à été échangé
+  entre telle et telle personne, a telle date);
+- PGP se base sur un protocole de communication qui est lui non chiffré, et il
+  est donc facile de soit se tromper, soit dégrader le mode de conversation vers
+  une méthode non chiffrée;
+- Il est facile de connaître votre réseau social avec PGP, puisque tout le
+  principe est de signer les clés des personnes dont vous validez l'identité;
+- En cas de fuite de votre clé privée, tous les messages que vous avez chiffrés
+  avec elle sont compromis. On dit que PGP ne fournit pas de *forward secrecy*;
+- La découverte de la clé de pairs se passe souvent *en clair*, sans utiliser une
+  connexion "sécurisée" (HTTPS). Tout le monde peut donc voir ces échanges et
+  savoir de qui vous cherchez la clé;
+- Les discussions de groupes sont très difficiles: il faut chiffrer pour chacun
+  des destinataires (ou que ceux-ci partagent une paire de clés).
+
+Je suis en train de creuser à propos les alternatives à PGP, par exemple `Pond
+<https://pond.imperialviolet.org/>`_, qui lui ne construit pas par dessus un
+standard déjà établi, et donc n'hérite pas de ses défauts (mais pas non plus de
+son réseau déjà établi).
+
+En attendant, quelques bonnes pratiques sur PGP ;)
+
+Bonnes pratiques
+================
+
+Il est en fait assez facile d'utiliser PGP de travers. Riseup à fait `un
+excellent guide
+<https://help.riseup.net/en/security/message-security/openpgp/best-practices>`_
+qui explique comment configurer son installation correctement.
+
+- J'en ai déjà parlé, mais il faut absolument choisir des phrases de passes
+  suffisamment longues. Pas facile de les retenir, mais indispensable. Vous
+  pouvez aussi avoir un document chiffré avec une clé que vous ne mettez jamais
+  en ligne, qui contiens ces phrases de passe, au cas ou vous les oubliez.
+- Générez des clés RSA de 4096 bits, en utilisant sha512;
+- Il faut utiliser une date d'expiration de nos clés suffisamment proche (2
+  ans). Il est possible de repousser cette date si nécessaire, par la suite.
+
+Parmi les choses les plus frappantes que j'ai rencontrées:
+
+- Utiliser le *flag* `–hidden-recipient` avec PGP pour ne pas dévoiler qui est
+  le destinataire du message;
+- Ne pas envoyer les messages de brouillons sur votre serveur, ils le seraient
+  en clair !;
+- Utilisez HPKS pour communiquer avec les serveurs de clés, sinon tout le
+  trafic est en clair.
+
+Le `projet Bitmask <https://bitmask.net/>`_ vise lui à rendre les outils de
+chiffrement d'échanges de messages et de VPN simples à utiliser, encore quelque
+chose à regarder.
+
+Enfin bref, y'a du taf.
+
+.. image:: {filename}/static/porte.jpg
+    :alt: Un peu d'ombre.

content/crypto/webcrypto-distribution-signing.rst

@@ -0,0 +1,107 @@
+Web distribution signing
+########################
+
+:lang: en
+:date: 2015-06-29
+:headline: Bringing trust back between software authors and user agents.
+
+.. note:: I'm not a crypto expert, nor pretend to be one. These are thoughts
+          I want to share with the crypto community to actually see if any
+          solution exists to solve this particular problem.
+
+One `often pointed <http://www.tonyarcieri.com/whats-wrong-with-webcrypto>`_
+flaw in web-based cryptographic applications is the fact that there is no way
+to trust online software distributions. Put differently, you don't actually
+trust the software authors but are rather trusting the software distributors
+and certificate authorities (CAs).
+
+Attack vectors
+==============
+
+Let's try to describe a few potential attacks:
+
+*Application Authors* just released a new version of their open source web
+crypto messaging application. *Indie Hoster* installs it on their servers so
+that a wide audience can actually use it.
+
+Someone alters the files on *Indie Hoster* servers, effectively replacing them with
+other *altered files* with less security properties / a backdoor. This someone could either be
+*Evil Attacker* or *Indie Hoster* which can already alter these files because
+they're distributing them.
+
+Trusted *Certificate Authorities* (read "governments") can also trick to
+User Agents (i.e. Firefox) into thinking they're talking to *Indie Hoster* even
+if they're actually talking to a different party.
+
+**Altered files** are being served to the User Agents, and *Evil Attacker* now
+has a way to actually attack the end users.
+
+Problem Mitigation
+==================
+
+I hope it's clear by now that we miss a way to create trust between
+*Application Authors* and *User Agents*. The User-Agent has to trust
+*Certificate Authorities* and *Indie Hoster*.
+
+I believe this specific problem had been solved, at least partially, for
+desktop software distribution: *Crypto Experts* audit the software, sign it
+somehow and then this signature can be checked locally during installation or
+runtime.
+
+For web applications, we don't have such a mechanism, but it should be
+possible. Consider the following:
+
+- *App Authors* publish a new version of their software; They provide a hash of
+  each of their distributed files;
+- *Crypto Experts* audit these files and sign the hashes with their private
+  key;
+- *User Agents* have a way to add the certificate for *Crypto Experts*;
+- When a *User Agent* downloads files, it checks if they're signed.
+
+Chosing who you trust
+=====================
+
+.. note:: And now is the time I start talking about things I don't know. But
+          maybe you trust me?
+
+In terms of user experience, handling certificates is hard, and that's where
+the community matters. Distributions such as `Tails <https://tails.boom.org>`_
+could chose who they trust to verify the files, and issue warnings / refuse to
+run the application in case files aren't verified.
+
+But, as highligted earlier, CAs are hard to trust. A new instance of the same
+CA system wouldn't make that much differences, expect the fact that
+distributions could ship with a set of trusted authorities (for which
+revocation would still need to be taken care of).
+
+.. epigraph::
+
+  [...] users are vulnerable to MitM attacks by the authority, which can vouch
+  for, or be coerced to vouch for, false keys. This weakness has been
+  highlighted by recent CA scandals. Both schemes can also be attacked if the
+  authority does not verify keys before vouching for them.
+
+  -- `SoK : Secure Messaging <http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf>`_;
+
+It seems that some other systems could allow for something more reliable:
+
+.. epigraph::
+
+  Melara et al proposed CONIKS, using a series of chained commitments to Merkle
+  prefix trees to build a key directory [...] for which individual users can
+  efficiently verify the consistency of their own entry in the directory
+  without relying on a third party.
+  
+  This “self- auditing log” approach makes the system partially have no
+  auditing required (as general auditing of non-equivocation is still required)
+  and also enables the system to be privacy preserving as the entries in the
+  directory need not be made public. This comes at a mild bandwidth cost not
+  reflected in our table, estimated to be about 10 kilobytes per client per day
+  for self-auditing.
+
+  -- `SoK : Secure Messaging <http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf>`_;
+
+Now, I honestly have no idea if this thing is practicable, and I'm pretty sure
+this design has many security problems attached to it. But that's a problem
+I would really like to see solved one day, so here the start of the discussion,
+don't hesitate to `get in touch </pages/about.html>`_!

content/pages/about.rst

@@ -3,7 +3,7 @@ Bonjour, je suis Alexis
 
 :slug: about
 
-(english version below)
+.. note:: There is an english version of this page below.
 
 Je suis un développeur logiciel intéressé par l'écologie, l'éducation
 (populaire !), la thématique agricole et le *Do It Yourself* (DIY).
@@ -50,7 +50,7 @@ english.
 You can find most of the computer related projects I am involved with 
 `on my github page <http://github.com/ametaireau>`_, on `the Mozilla services
 github page <https://github.com/mozilla-services>`_ or on `the Spiral project
-page <http://github.com/spiral-project/>`_ 
+page <http://github.com/spiral-project/>`_.
 
 Don't hesitate to contact me at `alexis at notmyidea org`. The associated
 public key is `0x078805D867F56F12 </static/alexis.notmyidea.org.asc>`_.

content/pages/projets.rst

@@ -5,6 +5,9 @@ Je pense que l'informatique est un fabuleux moyen de répondre à des besoins
 existants, en terme de collaboration notamment. Voici quelques logiciels dont
 je suis l'auteur ou un des contributeurs.
 
+Projets personnels
+==================
+
 Pelican
   `Pelican <http://getpelican.com>`_ est un générateur de site statique. Son
   objectif est de permettre de trasformer des fichiers sur votre disque en blog
@@ -45,5 +48,41 @@ Formbuilder
   libre et gratuit à Google forms.
 
 
+Projets professionnels
+======================
+
+Kinto et Cliquet
+  `Kinto <https://github.com/mozilla-services/kinto>`_ et `Cliquet
+  <https://github.com/mozilla-services/cliquet>`_ sont les successeurs
+  spirituels de Daybed. L'idée est toujours la même: stocker des données en
+  ligne, les partager et les synchroniser.
+
+  Rémy, Mathieu, Nicolas et moi travaillons en ce moment sur ce projet pour
+  Mozilla.
+
+Firefox Hello
+  `Firefox Hello <https://firefox.com/hello>`_ est un moyen d'établir des
+  communications pair à pair en utilisant Firefox. Contrairement à d'autres
+  solutions, les communications ne passent par un tiers que lorsque cela est
+  absolument necessaire.
+
+  J'ai écrit avec Rémy `le serveur de mise en relation
+  <https://github.com/mozilla-services/loop-server>`_.
+
+Circus
+  `Circus <https://github.com/circus-tent/circus>`_ est un gestionnaire de
+  processus. C'est un logiciel *coté serveur* dont l'objectif est de veiller
+  sur les programmes qui s'executent afin de les relancer en cas d'échec.
+
+  J'ai rejoint Tarek et Benoit sur le projet après qu'ils aient entammé le plus
+  gros du travail.
+
+Cornice
+  `Cornice <http://github.com/mozilla-services/cornice>`_ tente de rendre plus
+  simple la création de services web en mutualisant les bonnes pratiques.
+
+  Tarek à écrit la première version du logiciel que j'ai ensuite retravaillé
+  pour rendre les évolutions plus simples.
+
 Je n'indique ici que certains des projets auquels je contribue, vous pouvez en
 trouver d'autres sur `mon profil GitHub  <https://github.com/ametaireau>`_.