Some of you may have seen from my last guest blog that I made tentative use of my schoolboy Latin to highlight some weaknesses of traditional approaches to internet security.

Consequently, I've become the butt of running jokes here in the office (you know, employees demanding manumission, that kind of thing), but what the hell – if I can get away with it once, I can get away with it again. And so, mes amis, my language of choice in this current blog is French! For which, I will admit, I did require some in-house help.

Anyway, let's return to our sheep, as (y)our Gallic cousins say. You may remember that I also wrote in my last piece about the dangerous notion of the security certificate and the ‘Trusted Authority'. I likened these to a 1930s airport, where a clerk would glance at your passport once, pronounce you of impeccable character and then give you the run of the place.

Well, in the same way that those certificates turned out to be not very certificate-like, the other traditional foundation of internet security – the key – has a personality disorder all of its own. Although ostensibly designed to keep data encrypted and therefore private, what it actually does is put the ability to decrypt and read data squarely in the hands of a third party. A third party who is, in fact, one of those not-so-trusted authorities. Zut, alors!

Let's delve a little. Now, I'm going to get very non-technical on your derriere here, so hold on to your chapeau. In conventional internet security, the trusted authority works as a keystore - think of it as a warehouse full of padlocks (and for this analogy, I owe thanks to the excellent Charles Arthur, who had a conversation with me about it over by Euston Station a few weeks back.)

When you want to encrypt data for sharing, your device knocks on the door of the warehouse, has a quick conversation with the chap in the brown slop coat about what you want to send and to whom and comes back down again with your padlock, which protects your data.

When you decide you want to share or send the data, the nice warehouseman then performs some ‘encryption key management' - that is, he looks up your identity against the list of padlocks issued, makes a few checks with the recipient (who must be known and pre-enrolled), decides you're both OK and the recipient can then use their appropriate key to open the padlock. All tickety-boo? Mais non!

Firstly, the warehouse isn't a stronghold. Thieves can (and do) break in and steal piles and piles of genuine padlocks. Once they are in control of those padlocks, they are in control of your data, and the horrifying thing is that neither you nor your recipient will suspect a thing. The padlocks look just as heavy and solid as they always did, complete with a reputable maker's name stamped into the brass.

Secondly, it's your data. Why on earth would you want someone else to have control of the padlocks that secure it in the first place? Et voila, we've said it. In order to encrypt data effectively, we have to rethink all our entrenched notions of what constitutes a key and how it should behave. Those big old padlock warehouses?  Tear ‘em down. Why? Because the process can now take place chez toi, within your device.

Now, this is extremely difficult to put into an analogy, but bear with me. Instead of grabbing a padlock from the padlock warehouse, you can now make a padlock in your browser. Imagine that this padlock is sprayed with a special substance that bonds your identity to it – your DNA - so that you, and only you, can be identified as the owner of that padlock.

The recipient, meanwhile, has their own padlock, similarly created within their browser and sprayed with the magic identity-bonding substance representing their DNA. When your padlocked data reaches your recipient, there is no registering or pre-enrolment required. Instead, a little bit of intimate frottage immediately takes place between the padlocks, and the mingling of the sprays creates a unique new compound which acts as a key that both sender and recipient can use, enabling data to pass between them – as long as the locks are still in contact with each other. Magnifique!

OK, I'm perpetuating national stereotypes, here. I'm also deliberately oversimplifying, as the actual mechanics of this kind of distributed private key generation are mathematically extremely complex and are the subject matter of learned academic papers.

But the point is this: in the process I describe above, no third party is able to appropriate, monetise or otherwise use the keys that are generated. Because the key generation is operated by the sender and recipient, and can only occur when both parties' ‘sprays' have been combined, only the sender and recipient have access to that key.

Almost absurdly (but rather gratifyingly), even the company delivering the technology that enables this sender-recipient key generation process to take place cannot make use of the keys in any way!

So when is a key not a key? When only two people can use it to open one thing and nobody else can use it to open that thing or anything else. Ah oui - c'est simple

Brian Spector is CEO of CertiVox