Terre ocre battue,
Service et balle de match ;
Bientôt les vacances.

Le chiffrage homomorphique est une méthode qui permet à une personne tierce de faire une opération sur des données chiffrés, donc sans avoir accès à la valeur non-chiffrée.

Cela ouvre la voie à la possibilité de pouvoir faire faire des opérations lourdes et complexes sur des machines distantes (« cloud ») sur des données dont on souhaite garder le secret.

L’exemple le plus simple d’un chiffrage homomorphique est le suivant :

Admettons que j’ai deux nombres A et B avec A=3 et B=5.

Je souhaite pouvoir additionner ces deux nombres, mais supposons que cette opération soit lourde et que mon ordinateur mette des heures à faire cette opération. Je souhaite alors pouvoir faire cette opération dans le « cloud », qui lui disposerait de machines et d’architectures bien plus adaptés à ce traitement.

Par contre, je ne veux pas envoyer mes deux nombres en clairs, mais si je les chiffres, il faudrait alors que le « cloud » ait la clef pour les déchiffrer, faire son opération, rechiffrer le résultat avant de le renvoyer : mes deux nombres ne seront pas secrets au moment de l’opération, et donc quiconque aurait accès aux machines du cloud pourrait intercepter mes deux chiffres.

C’est ici que rentre en jeux le chiffrage homomorphique.

Je vais tirer au hazard un nombre entier M : disons M=2.

Je vais multiplier A et B par M pour obtenir A’ et B’ : j’obtiens donc A’=M*A=6 et B’=M*B=10.

Ce nombre M et l’opération « multiplication » sont en fait la méthode de chiffrage homomorphique.

Je soumet alors au « cloud » les nombres A’=6 et B’=10 pour qu’il effectue son opération d’addition.

Le « cloud » additionne donc 6+10 et il me retourne 16.

Je récupère le résultat 16 et j’applique la fonction homomorphique inverse qui est une division par M : 16/M=16/2=8.

J’ai donc le résultat 8 qui correspond bien à l’opération souhaité A+B=3+5=8, et ceci sans que le « cloud » n’ai à aucun moment eu accès à mes nombres 3 et 5 qui sont donc restés secret.

# php -r 'session_start();session_decode(file_get_contents($argv[1]));var_export($_SESSION);' /path/to/php/session/sess_707484e735ad7aa9a108b23ad20cc46f

Le 5 Février 2013, Libération ressort la première édition du journal.

Une phrase retient mon attention dans cette première édition :

Qui d’entre nous, en lisant son journal du matin, n’a pas l’impression d’être le jouet des marchands de publicité, des politiciens ?

Cette question a 40 ans, et pourtant elle apparaît tellement d’actualité.

On lit de moins en moins son journal le matin, mais on lit de plus en plus son journal sur Internet : sur les sites des journaux papier, des sites d’actualité, des agrégateurs de flux d’info, etc. Le journal papier comme support se perd, mais le contenu, la matière, l’information persiste et perdure sur d’autres supports.

Le support de l’information change, et avec elle, la publicité change aussi de support.

La publicité est omniprésente sur Internet : résultats sur un moteur de recherche, bannières/encarts/cadres publicitaire sur les sites d’information, spot publicitaire avant les vidéos, etc.

La publicité c’est très bien adaptée à ce changement de support, peut-être même mieux que le contenu lui même.

Qui d’entre nous, en surfant sur Internet, n’a pas l’impression d’être le jouet des marchands de publicité ?

You can spend your whole life doing no more than preparing for the life and thinking.

Terrance Hayes

In these cases, the solution is to use locking techniques to force sections of code to execute sequentially rather than in parallel.

Note: for those not familiar with locking, it is important to understand that the same locking algorithm should be implemented by each party that will be executing a critical section! Locking is useless if only one party implements it.

Here I’ll show two techniques in PHP (one for local locking, and one for cross-server locking).

In PHP you can use flock() or IPC semaphores to achieve this kind of serialization. Here is an example with flock():

$lockfile = 'foo.lock';
$lock = fopen($lockfile, 'a');
if ($lock === false) {
    throw new Exception(sprintf("Could not open lockfile '%s'", 'lock'));
}

/* Get exclusive lock: this will block until we get the lock */
$ret = flock($lock, LOCK_EX);
if ($ret === false) {
    throw new Exception(sprintf("Could not get lock on lockfile '%s'.", $lockfile));
}

/*
 * Critical section which should not be executed
 * in parallel by another process
 */
[...]
/* End of critical section */

/* Release the lock */
$ret = flock($lock, LOCK_UN);
if ($ret === false) {
    throw new Exception(sprintf("Could not release lock on lockfile '%s'.", $lockfile));
}
fclose($lock);

This might not be the fastest locking mechanism, but it works. But it also only works when your PHP code runs on a single server, as the lock is done on a local file. IPC semaphores should be faster, but they also only work locally.

What if you need to lock PHP code running on different servers?

To achieve this kind of global locking, you’ll still need a shared object accessible by all the PHP servers.

The flock() technique is still possible if the lock file is located on an NFS mounted volume for example. Sometimes flock() over NFS can be problematic, but if everyone is using nfslock daemons, then you should be fine.

Anyway, your PHP application might already be using a shared database? and more precisely a Postgresql database? So here is another technique that rely on the « LOCK TABLE » command with Postgresql database to provide cross-server locking.

We’ll be using the « LOCK TABLE » command on a dedicated blank table. The « LOCK TABLE » command must be used in a transaction, and once the lock is acquired, it will last until the transaction ends (either with a « COMMIT » or  » ROLLBACK »).

We’ll lock on an empty table, that will contain no data, and whose purpose is only for locking.

First, we need to create a blank table we’ll call « global_lock »:

CREATE TABLE global_lock (id int);

Now, we can issue « LOCK TABLE » commands on this table:

$conn = pg_connect($dsn);
if ($conn === false) {
    throw new Exception(sprintf("Error connecting to database with DSN '%s': %s", $dsn, pg_last_error());
}

/* Start a transaction */
$res = pg_query($conn, 'BEGIN');
if ($res === false) {
    throw new Exception(sprintf("Error starting transaction: %s", pg_last_error($conn));
}

/* Try to acquire a lock: this will block until we get the lock */
$res = pg_query($conn, 'LOCK TABLE global_lock');
if ($res === false) {
    throw new Exception(sprintf("Could not get lock on 'global_lock': %s", pg_last_error($conn));
}

/*
 * Critical section which should not be executed
 * in parallel by another process
 */
[...]
/* End of critical section */

/* Release the lock */
$res = pg_query($conn, 'ROLLBACK');
if ($res === false) {
    throw new Exception(sprintf("Could not release lock on 'global_lock': %s", pg_last_error($conn));
}

Regarding performances, I’m not sure this is faster than flock(), and it might also add pressure on your Postgresql’s max_connection limit if lot of PHP requires locking.

Services that heavily rely on locks (like distributed filesystems) uses dedicated services (like a Distributed Lock Manager), and that might be the route to go if you need that kind of performance/scalability.

Are there any known incompatibilities between Western Digital SATA disks (WD1002FAEX / Firmware version 05.01D05) and ICH9 SATA controlers?

I have a remote server (don’t have physical access to it) with an ICH9 SATA controler and two different disks  in a MD RAID1 volume: one Hitachi and one WD.

The problem is that I have poor write performance and iostat is always reporting a 100% utilization (%util field) on the Western Digital disk, while the Hitachi (HDT721010SLA360) does not reports such high %util usages.

The WD disk as been changed with another (same model) WD disk, and I’m still having 100% utilization on this disk.

Could there be an incompatibility between theses WD disks and ICH9 controlers?

Initialy the server was running with two Hitachi disks, and one of them failed, so it was replaced by these WD disk. Since then, I’m stuck with theses 100% util usages on this disk.

So, here is a couple of DomainKeysSigner and DomainKeysVerifier PHP classes that implement the sign and verify operations, with the verify operation fetching the public key through a custom DNS TXT record.

To start with, you need a public/private RSA key that you can obtain with openssl:

# openssl genrsa -out my.service.example.net.private.key 1024

Extract the public key:

# openssl rsa -in private.key -text -pubout

Now, you need to setup a DNS TXT record for your host/domain containing the base64 key from the previous command, without the « —–BEGIN PUBLIC KEY—– » and « —–END PUBLIC KEY—– » tags.

Let say you wan’t to set the key on « foo.example.net »:

foo.example.net. IN TXT "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCyvgpjWK2w6FmlFxdxcSBwP0P50jsIUB3ZV0xYXolLF0jipXdjN/TgZjBAlRYlF7u/iXW7WmrbU/mwpdlyiK0+dZvwZMGUzqBOC1ULz5i8xPVidutkBhMMWFovipibnvU6TePJjMdeBTlEDpi1p4/V66yOxJ8sU1nYCTYJIqaX1QIDAQAB"

Now you can use the DNSPubKeySigner and DNSPubKeyVerifier classes to sign and verify a data signature with the public key fetched from the DNS TXT record.

- https://github.com/eguaj/DNSPubKeyVerifier

Here is a use case I’m seing for such a protocol:

Given a mobile device that can do Wifi or 3G.

When the device is in the vicinity of a known (or open) Wifi network, it connects to it in order to get access to the Internet.

Now, if the DSL (or any other broadband access) connection on the Wifi router is dead, then my device can’t connect to the Internet, and it will stay connected to this Wifi network trying endlessly to get Internet connection through this Wifi router.

In these cases, the Dead-WAN-Detection protocol could instruct the device that the Internet/uplink connection is dead (although the Wifi connection is up), and the device could react by switching to 3G in order to get Internet connection.

Then, when the uplink connection get back on the Wifi router, the router could broadcast a signal indicating that the connection is up, and the device would then switch back from 3G to Wifi for its Internet connection.

L’application « Kobo by FNAC » est inutilisable depuis la sortie de iOS 6.

Depuis le 19 Septembre 2012, date de sortie de iOS 6, les commentaires négatifs s’accumulent donc sur la page de l’application dans l’App Store : 109 commentaires négatifs contre 29 positifs.

À l’heure actuelle il n’y a toujours pas de mise-à-jour disponible, et la version disponible est toujours celle du 23 Novembre 2011…

Par curiosité, si on va faire un tour sur l’App Store U.S., on a alors la surprise de voir qu’il existe une app « Kobo » (sans FNAC) et qui semble être à jour et supporter correctement iOS 6.

Malheureusement, on a pas le droit de télécharger cette application avec un compte iTunes FR.