Tanguy Ortolo

Signing-party and crypto conference in Paris

Tanguy — Sat, 12 May 2012 15:58:00 +0200

Content: explanations about cryptography, SSL and PGP, then signing-party
Location: EPN la Bourdonnais, 105 avenue de la Bourdonnais, 75007 Paris
Date: 2012-05-21 18:45+02:00
Duration: 02:15

Monday 21st during at 18:45, in Paris, there will be a conference organized by Parinux, where I will explain the principles of cryptography and their application in the SSL and PGP systems. This conference will be followed at 20:30 by a signing-party PGP et CAcert.

For the signing-party, I will ask participants to:

generate a key pair if you do not already have one;
send me you public key and register;
print some copies of your key fingerprint;
print the list of participants I will send you;
come with all that stuff and one or two identity documents.

This is a partial translation of the full article I wrote in French, in case foreigners could attend. Sorry for the very late notice…

Signing-party et conférence crypto

Tanguy — Fri, 04 May 2012 19:59:00 +0200

Contenu : explications sur la cryptographie, SSL et PGP puis signing-party
Lieu : EPN la Bourdonnais, 105 avenue de la Bourdonnais, 75007 Paris
Date : 2012-05-21 18:45+02:00
Durée : 02:15

Le lundi 21 mai au soir, à Paris, se tiendra une conférence organisée par Parinux, où j'expliquerai les principes de base de la cryptographie et leur application dans les systèmes SSL et PGP. Cette conférence sera suivie par une signing-party PGP et CAcert.

Pour le déroulement de la signing-party, je vous demanderai de :

générer un paire de clefs si vous n'en avez pas déjà une ;
m'envoyer votre clef publique et vous inscrire ;
imprimer quelques exemplaires de votre empreinte de clef ;
imprimer la liste des participants que je vous enverrai ;
venir munis de tout cela ainsi que d'un stylo et d'une ou deux pièce d'identité.

Conférence

Cette conférence commencera à 18:45. Elle aura pour but de comprendre les principes et les enjeux des systèmes cryptographiques utilisés aujourd'hui. Pour cela, je donnerai :

une brève description de l'histoire de la cryptographie ;
une petite explication des principes mathématiques des cryptosystèmes asymétriques ;
une explication des systèmes de certification ;
une présentation pratique du système OpenPGP avec son implémentation libre GnuPG.

Signing-party

À l'issue de la conférence, vers 20:30, nous procéderons à une signing-party. Il s'agira pour les participants de vérifier mutuellement leur identité afin de certifier leurs clefs PGP.

Cette signing-party sera également l'occasion, pour les utilisateurs de l'autorité de certification SSL CAcert, de certifier leur identité dans le cadre de cette organisation.

Détails pratiques

Il vous est demandé de vous inscrire afin d'évaluer le nombre de participants.

Si vous n'utilisez pas encore PGP, vous pouvez générer une paire de clefs avec la commande suivante, ou en utilisant un outil graphique tel que ceux fournis avec les bureaux GNOME et KDE :

$ gpg --gen-key

Pour faciliter le déroulement de cette signing-party, veuillez m'envoyer votre clef publique. Vous pouvez exporter votre clef dans un fichier avec la commande suivante (indiquez votre adresse à la place de celle de Tintin…), ou en utilisant un outil graphique :

$ gpg --armor --export tintin@example.com

Pour permettre aux participants tardifs de participer, il sera également utile de vous munir de morceaux de papier indiquant votre empreinte de clef ; vous pouvez en générer avec l'outil gpg-key2ps du paquet Debian signing-party, ou copier plusieurs fois la sortie de la commande :

$ gpg --fingerprint tintin@example.com

Le jour venu, vous aurez besoin à cette signing-party d'un exemplaire imprimé par vos soins de la liste des participants que je vous enverrai, ainsi que d'un stylo.

Pour les utilisateurs de CAcert, veuillez venir avec une bonne liasse de formulaires d'accréditation pré-remplis à votre nom (en tant que demandeur et en tant qu'accréditeur pour ceux qui ont assez de points pour cela).

Debian: switch to UEFI boot

Tanguy — Wed, 25 Apr 2012 20:06:00 +0200

For those interested, here is a way to install Debian and boot it with UEFI if you have an UEFI motherboard. Using UEFI with Debian requires expert knowledge so if you do not feel up to it, keep your BIOS system.

1 Background

UEFI is a specification for motherboard's firmwares which is replacing the old BIOS. For now, UEFI motherboards still include a BIOS compatibility layer.

The UEFI boot process is quite different from the BIOS one. It involves one specific piece of the motherboard's firmware, the UEFI Boot Manager, which is able to load boot loaders from FAT file systems on specially-typed partitions. It can offer a boot menu (boot: Debian from HDD, Windows from HDD, USB stick, DVD?), which can be configured from a running operating system.

So, basically, to boot a system with UEFI, you need two things:

to install an UEFI boot loader on a FAT-formated EFI System Partition;
to tell the UEFI Boot Manager to create an entry for that boot loader.

2 Installation or preparation

If you are installing a new Debian system, read the first part. If you already have a BIOS-bootable Debian system installed, read the second one.

In both cases you will have to use Debian testing, because stable's GRUB has problems with UEFI. You can also use Debian stable while taking only GRUB from testing though.

2.1 Installation of a new Debian system

There is no installer image for UEFI, so you can either:

make your own, by installing an UEFI boot loader to an USB stick, which will load a regular installer kernel and initrd;
use a regular BIOS installer image, using the compatibility mode of your motherboard.

The installer does not provide a convenient way to install an UEFI boot loader, so you are going to install a regular BIOS boot loader at first, and switch to UEFI later.

Use the expert mode and format your hard drive with a GUID Partition Table (GPT). Create a small partition (1 MiB would be far enough), type it as a BIOS Boot Partition (this is the untitled flag above the “bootable” one in Partman), do not format it and do not mount it: this will be needed for BIOS booting. Create another small partition (same kind of size), type it as an EFI System Partition (this is the“bootable” flag), format it as FAT and mount it on /boot/efi: this will be needed for UEFI booting.

Finish the installation as usual, installing GRUB for BIOS, and boot your new system.

2.2 Preparation of an existing Debian system for UEFI

You need to use a GUID Partition Table on your hard drive. If you used an MBR, you lost; you may try to convert it to GPT using a tool such as gdisk, but that means operating without a net, loosing your current boot loader in the process.

If there is no space left on your hard drive, use Debian Live to make some. Create a small partition (1 MiB would be far enough), type it as an EFI System Partition, format it as FAT and mount it (permanently, using the fstab) on /boot/efi (that directory will not exist, so create it first).

3 Switch to GRUB UEFI

Install the package grub-efi-amd64. Prepare it by running the command (assuming your hard drive is /dev/sda):

# grub-install /dev/sda

That will do three things:

generate a GRUB image;
install it to the EFI partition at efi/debian/grubx64.efi;
try to configure the UEFI Boot Manager (the motherboard's boot menu) to load it on start-up

That last step will fail. This is expected, because the UEFI Boot Manager can only be configured from an operating system that was started from UEFI. So if you stop here, you get an unbootable system.

Now, copy (a symlink would be relevant here, but that cannot be done on a FAT file system!) the GRUB image to that other path on the EFI System Partition: efi/boot/bootx64.efi. This is where the UEFI firmware looks for a boot loader when it has not been configured for a specific path, typically on removable media. Reboot to check that…

If that trick worked, you are now on UEFI-booted system. Run grub-install again, which should now succeed to configure the UEFI Boot Manager. Reboot to check that you get a “debian” entry on the motherboard's boot menu, and remove efi/boot/bootx64.efi which is no longer needed.

Des urnes électorales

Tanguy — Thu, 19 Apr 2012 22:49:00 +0200

L'approche d'élections en France est l'occasion de se pencher sur les caractéristiques des urnes utilisées : elles ont l'air d'objets communs, mais malgré leur conception assez simple, elles respectent des caractéristiques particulières essentielles aux garanties de secret et de vérifiabilité.

Des garanties

Pour être plus précis, dans un scrutin public, chacun doit pouvoir (j'en oublie sans doute) :

voter sans que quiconque puisse déterminer le vote en question ;
détecter les fraudes (ajout, retrait ou modification de votes) ;
vérifier le décompte des votes.

Le système de vote actuel avec isoloir, feuille d'émargement, urne et comptage public fournit toutes ces garanties (à vrai dire, le secret du vote n'est pas applicable dans le cas marginal d'une unanimité), mais je vais ici m'attacher particulièrement aux caractéristiques des urnes elles-mêmes. Notons tout de même qu'il ne s'agit pas garanties absolues : dans le cas d'une fraude, ce qui est garanti, c'est qu'il sera possible de la détecter, pas qu'elle sera effectivement détectée.

Des urnes

Parmi leurs caractéristiques générales, les urnes utilisées sont transparentes et grandes :

Transparentes: Pour que chacun puisse constater ce que devient le bulletin de vote, et vérifier qu'il n'y a pas de mécanisme caché à l'intérieur, qui irait par exemple empiler les enveloppes dans l'ordre : un tel système permettrait à un observateur notant l'ordre de passage des électeurs de déterminer précisément le vote de chacun.
Grandes: Ou, pour être plus précis, grandes par rapport à la taille d'une enveloppe, afin que celles-ci puissent s'entasser dans le désordre : avec une petite urne, elles s'empileraient nécessairement dans l'ordre faute de place…

Conclusion

Quand vous irez voter, vérifiez bien ces caractéristiques de l'urne, et si vous constatez qu'elle est opaque, plaignez-vous !

Ce dernier conseil n'est pas seulement hypothétique, puisque certaines mairies ont réellement mis en place des urnes opaques : il s'agit d'ordinateurs de votes, dont le mécanisme interne est caché au public (quand bien même ils auraient le capot ouvert, on ne pourrait pas les vérifier pour autant), qui pourraient tout à fait noter l'ordre des votes, voire modifier ceux-ci. Peut-être le font-ils réellement d'ailleurs, mais il n'y a aucun moyen de le savoir…

Camera with a standard USB cable?

Tanguy — Tue, 17 Apr 2012 19:01:00 +0200

Since some years, there has been a movement towards standardization: mobile devices are now using Micro-USB for data transfer and charging, and SD or Micro-SD for storage extension (except Apple of course).

One piece is lacking to this perfection, however; as far as I know, digital camera producers did realize that SD won for storage, but they do not seem to have acknowledged the Micro-USB standard yet.

Now, since manufacturers and resellers do not indicate the connector type, I have no way to be sure that this is still the case. So, dear lazyweb, do you know if, by chance, there exists a compact digital camera that would use SD cards and a Micro-USB connector for data transfer and integrated charging?

“Everything is a file” rocks

Tanguy — Mon, 16 Apr 2012 19:34:00 +0200

Unix rocks, or at least one of its design feature does: everything is a file.

Here is one funny use of that feature. I consider that programs that manipulate text should basically take it on their standard input, and write it to their standard output, while specifying the name of an input or output file should be an optional refinement.

Well, at least one program was designed the other way: when used to import a foreign key, ssh-keygen -i has no option to read it on its standard input. No problem, this can be worked around:

# ssh-keygen -if /dev/stdin
[paste the foreign key here]

Unfortunately, that does not work with every action of ssh-keygen since not all of them were written to be able to handle streams, which cannot be rewound.

Why “www.”?

Tanguy — Thu, 12 Apr 2012 19:23:00 +0200

Many websites have addresses that use a www.- prefix. Some people are encouraging this practice, other are advising against it.

I, for one, think this prefix makes sense and is really useful, so here is an explanation of my opinion. In a nutshell: the Wold Wide Web is one Internet service among many other such as domain name, mail, mailboxes or instant messenging; using a dedicated prefix allows to distribute all these services to specific servers in a convenient way.

On Internet, you can expose several services, the most common being domain names (DNS), websites (HTTP), incoming mail (SMTP), outgoing mail submission (submission), mailbox fetching (POP) or consultating (IMAP) and instant messenging (XMPP).

Constraints

Modern Internet services can have constraints such as load balancing, failover and most importantly the possibility to use specific servers for each service instead of having all of them on the same server.

Dedicated records

Some service were designed or revised to take these contraints into account; this include the domain name, incoming mail and instant messenging, by using dedicated DNS records:

example.com.                    NS              roquefort.example.com.
example.com.                    MX  10          morbier.example.com.
_xmpp-server._tcp.example.com.  SRV 10 100 5269 morbier.example.com.

In that example, the name service of example.com. is provided by the server Roquefort while the incoming mail and instant messenging service are provided by Morbier

Dedicated prefixes

On the contrary, some services were not designed to take these constraint into account, and may be too fossilized to be revised for that; this includes the Web and mailbox service. A convenient way to work around the antiquated design of these services is to use a well known prefix:

www.example.com.                CNAME           ossau-iraty.example.com.
smtp.example.com.               CNAME           morbier.example.com.
pop.example.com.                CNAME           morbier.example.com.
imap.example.com.               CNAME           morbier.example.com.

In that example, the Web service of example.com. is provided by the server Ossay-Iraty while the email submission and mailbox services are provided by Morbier.

Readability and flexibility

Using dedicated records and prefixes increases the consistency and readability of a DNS zone, since it allows to refer to the servers by their canonical host name, and to define their IP addresses once and for all:

; Services
example.com.                    NS              roquefort.example.com.
example.com.                    MX  10          morbier.example.com.
pop.example.com.                CNAME           morbier.example.com.
imap.example.com.               CNAME           morbier.example.com.
www.example.com.                CNAME           ossau-iraty.example.com.

; Hosts
roquefort.example.com.          A               192.2.0.12
                                AAAA            2001:db8::12
morbier.example.com             A               192.2.0.42
                                AAAA            2001:db8::42
ossau-iraty.example.com.        A               192.2.0.51
                                AAAA            2001:db8::51

You can think of that practice as connecting dots between services and hosts:

name service  •────────────────────→• Roquefort
incoming mail •────────┬───────────→• Morbier
mailboxes     •────────╯ ╭─────────→• Ossau-Iraty
website       •──────────╯

With such a DNS zone, it is very easy to identify which server is hosting each service. Using host names rather than IP addresses multiple times reduces the information duplication, which in turn facilitates future chances and reduces the risk of error (it is easier to swith the website from Ossay-Iraty to Morbier than from 192.2.0.51/2001:db8::51 to 192.2.0.42/2001:db8::42).

JSON License considered harmful

Tanguy — Fri, 09 Mar 2012 23:34:00 +0100

Summary

The JSON License may seem interesting, but it a bad license, both non-free and ambiguous: do not use it. If you are the author of a piece of software that uses JSMin or its PHP port, consider dropping that non-free part or at least rendering it optional.

The JSON license

Do you know the JSON License? It is a software license inspired by the MIT/Expat license with one additional morality clause:

The Software shall be used for Good, not Evil.

Non-free

For novices that clause can be perceived as a good idea serving a noble goal. But the problem here is that is would make your software non-free.

Indeed, there are two common definitions of free software: the FSF definition, and the Debian Free Software Guidelines, also known as the Open Source Definition. Basically, both definitions indicate that to be free, a piece of software must be usable with no restrictions, and forbidding evil uses is such a restriction. Specifically, it violates:

the FSF's zeroth liberty: “A program is free software if the program's users have the four essential freedoms: The freedom to run the program, for any purpose (freedom 0). […]”
the DFSG/OSD sixth point: “No Discrimination Against Fields of Endeavor: The license must not restrict anyone from making use of the program in a specific field of endeavor.”

Ambiguous

In addition to these incompatibilities to being free, this morality clause implies additional problems, the most important one being that it is ambiguous, which is very bad for a license clause: who exactly defines what is Good and what is Evil? If it is the author, then this clause could be used for arbitrarily forbidding any use; it it is the licensee, then this clause it as good as void.

Do not use it

For all these reasons, the JSON License with that infamous morality clause is not suitable for free software, so if you plan to use that license for your work, please consider these suggestions: 1. do not; 2. do not, really; 3. if still in doubt, refer to point 1. There are several standard free software licenses, the closest one being the MIT/Expat one, that you should consider instead.

Now, if you really want to be considered as non-free, and rejected by Debian, Red Hat/Fedora, Google Code and more generally any free software distributor, this is the way to go.

On thing worth noting is that this morality clause only annoys free software distributors, that are certainly not doing Evil, but will not prevent any evil person to do Evil things with your software. To encourage people to do Good rather than Evil, it would be better to formulate that clause as a suggestion rather than an order:

The Software should rather be used for Good, not Evil.

The JSMin case

This infamous JSON License is known to be used by JSMin and its PHP port. If you are a Web application author, be careful when embedded external content, since it can render you whole piece of software non-free! If you are using JSMin, I would suggest that you drop it, or at least make it optional by using a conditional (if JSMin is here, use it, otherwise do nothing) so that distributors such as Debian can expurgate that non-free part.