Cela n’aura pas échappé à certain-es d’entre nous, les serveurs de clefs OpenPGP ont été la cible d’une attaque très simple, liée intrinsèquement au fonctionnement de PGP.
Pour les plus curieux-ses, une toute nouvelle newsletter (Cryptography Dispatches) propose une analyse claire et concise de l’attaque, et quelques points de perspectives pour la suite des événements.
The final piece of the puzzle are keyservers. Keyservers are public services that host arbitrary OpenPGP keys, so that clients can fetch unknown ones by fingerprint or user ID (in theory to then verify them via the web of trust), or update known ones to discover new related packets. There is a network of public keyservers that sync contents with each other called the SKS pool.
Critically, anyone can upload a key to an SKS keyserver, and its content will be joined with the current view of that key across the SKS network. New subkeys and preferences need to be signed by the master key to be valid, but web of trust signatures can be uploaded by anyone².
Now, here’s a question you could ask in a job interview for a security role: what can go wrong in a system like this?
Au-delà des problèmes des serveurs de clefs, un article revient sur les défauts historiques de PGP en tant que standard, et de GnuPG en tant qu’implémentation.
Quelques extraits :
You can have backwards compatibility with the 1990s or you can have sound cryptography; you can’t have both .
There are, as you’re about to see, lots of problems with PGP. Fortunately, if you’re not morbidly curious, there’s a simple meta-problem with it: it was designed in the 1990s, before serious modern cryptography. No competent crypto engineer would design a system that looked like PGP today, nor tolerate most of its defects in any other design. Serious cryptographers have largely given up on PGP and don’t spend much time publishing on it anymore (with a notable exception). Well-understood problems in PGP have gone unaddressed for over a decade because of this.
Encrypting Email
Don’t.
Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext.
PGP begs users to keep a practically-forever root key tied to their identity. It does this by making keys annoying to generate and exchange, by encouraging “key signing parties”, and by creating a “web of trust” where keys depend on other keys.
Long term keys are almost never what you want. If you keep using a key, it eventually gets exposed. You want the blast radius of a compromise to be as small as possible, and, just as importantly, you don’t want users to hesitate even for a moment at the thought of rolling a new key if there’s any concern at all about the safety of their current key.
Sauf nouvelle info, je renonce à promouvoir gpg, du coup.
Je reviens à mon ancienne certitude : les email (comme les sms) sont des messages diffusés en clair sur les réseaux, et il faut utiliser d’autres messageries (Signal, etc.) pour les chiffrer plus sérieusement.
Au passage, merci pour wormhole (même si il ne fonctionne qu’en ligne de commande)
