The things which have changed most in my engineering job

Original article date: June 1997

If I look at the things which have changed most in my engineering job over the last few years, the following two stick out (well, if you ignore the hours getting longer!)

1. More and more is done on computers

2. More and more paperwork seems to be required.

The paperwork comes from three main areas:

ISO9000 et al result in far more proceduralised generation of documentation

The implications of CE marking even the smallest machine are that you will essentially record and documnent processes that common sense was making you do in the past anyway

Working with pharmaceutical companies with regulatory requirements to satisfy means huge amounts of supporting paperwork.

And yet at the same time, more of it is done on the ‘confuser’ than ever before. Which begs the question “Does a document on a computer count?”. What about a signature on a computer? Hmmm.

To answer these questions, I delved into the world of data encryption, which turns out to be a fascinating place. Here’s a taster.

Encryption is usually for one of four reasons:

1. Confidentiality. I want to send something to you over the ‘Net and I want nobody else to be able to read it.

2. Authenticity. I have received this set of instructions from you and I want to know it really came from you, rather than someone pretending to be you.

3. Non-repudiation. You have asked me to do this and I don’t want you later to be able to deny these were your words.

4. Anonymity. You want to prove to me you are a member of this video club without actually giving your name. Or you want to transfer money electronically with the untraceability of cash.

Mostly encryption works as follows. You and I will communicate a set of data over some (maybe unsecure) route. I will have encrypted it with some software that jumbles it up and you will de-crypt it with similar software. I will have used some sort of ‘key’ to characterise the encryption, and you will have some corresponding key that enables you to unjumble it. A key might be a string of numbers (4 Kbits in size, maybe) thay you feed into the software along with the data. Nobody aunauthorised who gets hold of it can do anything without a key.

Here we fall foul of some governments, who think that they should be able to decrypt anything. The US government think it should be illegal for a US software company to export such encryption software. This is excellent news for Europe’s home grown encryption software industry, some of whom even make add-ins to replace the missing modules that US companies were forced to chop from their European product variants!

But how do you and I know the right keys to use, even though nobody else does? Until about ’75, the answer was we pre-agreed them at some time when we had a secure comms link of some sort.

Then came a bright idea.

It all works like this: First, I think of a secret key, called my private key. I then put it through a complex process that generates another code (my public key). This process is sufficiently complex that nobody could ever do it in reverse. That is, even given my public key, someone could not deduce my private key. Anyway, you use my public key to encrypt something, and then the resulting data can only be de-crypted by me, using my private key. This way only I can read it, whoever gets hold of it. It doesn’t matter who gets hold of my public key, it’s harmless.

Inevitably, this makes public keys quite untidy, as they are the result of a complex algorithm, even if the private key was chosen to be something quite easy to remember. One suggested modification to this system is as follows. I think of a nice neat public key. The private key is made by a process that is performed by the government (only they can do it). They send me back my private key. Thus my public key could be my email address, or my name! You may have spotted the glaring security hole in this plan. I have to prove who I am to the Government before they can tell me my private key, and making that process totaly secure is bound to fail. Also the government can always read your encrypted data if they choose (whoever “The Government” in this case are). Does that bother you ?

This whole is very much a fast changing field with legislation being bandied about left right and centre. But without it, there will never be any real commerce on the Internet. So should the government (or the anti terrorist squad) be able to read all private encrypted data if they need to? What do you think?

June 1997