In my life, I’ve studied hundreds of papers on complex cryptographic algorithms and protocols; the type of academic papers that take five days to fully understand how much you don’t understand the described protocol. I’ve even written a few papers that might fall into that category. These algorithms and protocols all share one thing in common: despite the marvellous security guarantees and functionalities that they purport to have, they are unlikely to be implemented in any commercial product.

In many ways, this is understandable. I cannot imagine any commercial organisation would want to produce a product containing complex components that it didn’t fully understand, and even a large company, that can perhaps afford to employ a consultant cryptographer, is unlikely to want to risk their entire business reputation on the word of a single, fallible human being. Why risk an implementation error in a complex system if you can survive by using a simpler one? Or a series of simpler ones? Or a simple system and an online third-party server?

This sounds like a reasonable trade-off, but simple systems can often be a lot slower than their more mathematically advanced counterparts and combinations of simple systems can often give rise to unexpected security weaknesses. Let me give you an example:

Suppose you want to send a confidential e-mail over the Internet to someone outside your organisation. The textbook answer on how to do this is to encrypt the message using a public-key encryption scheme. You obtain the receipt’s public key from a PKI (checking the certificate from the CA) and encrypt the message using that public key. If the public-key encryption scheme is secure, then only the intended recipient can now read the message.

What about if you want to send a normal e-mail in such a way that the recipient knows that it came from you and hasn’t been changed on route? Again, the textbook answer is to use public-key cryptography. You use a digital signature scheme to digitally sign the message. The recipient can check your signature using your public key, obtained from a suitable PKI, and will only accept the message if the signature is correct.

Now, what about if you want to send a confidential message in such a way that the recipient knows that it came from you and hasn’t been changed? The obvious answer is to combine a public-key encryption scheme and a signature scheme. For example, you might send both an encryption of the message and a signature on the message, but not the message itself. The recipient would be expected to do two jobs: first it would recover the message by decrypting the ciphertext, and then it would have to check the signature on the message to make sure that it hasn’t been changed on route.

The problem is that this encrypt-and-sign construction is not secure. It’s very likely that the signature on the message would give away some information about the message. In some cases, the signature might give away the entire message itself! Since the signature is sent in the clear, the signature actually breaks the confidentiality of the encryption scheme.

(I should point out here that it’s not sufficient to simply encrypt the signature: similar problems exist for encrypt-then-sign and sign-then-encrypt schemes.)

So how do you send a confidential e-mail in such a way that the recipient knows that the e-mail came form you and hasn’t been changed on route? You have to use a type of cryptographic algorithm called a signcryption primitive. Signcryption not only provides confidentiality and integrity protection, but, because it’s a single cryptographic algorithm, it can also do so twice as fast as any combination of a signature scheme and public-key encryption scheme.

The problem is that, in its entire eleven year history, I haven’t heard of a single instance of it being used in a commercial product. There are lots of reasons why this might be the case, the lack of standards and potential patents being the first two that spring to mind, but I suspect that the biggest reason is that it a more complex system. Signcryption algorithms are powerful, efficient and flexible; but they are more complex and difficult to understand than any simple combination of signatures and encryption, and I think that that may scare away potential implementers.

If the greatest compliment to a scientist is to use his work, then academic cryptography can be a very frustrating subject to work in.

Hopefully signcryption won’t continue to be an unused technology for very much longer. The ISO/IEC standardisation body has already started work on a signcryption standard and there is some interest from the IEEE standardisation bodies too. I think that this is a great step forward: I’m hoping that once we manage to convince a few people that it’s a good idea, then everyone will see its benefits. After all, it’s only taken a decade.

It would be nice to think that some of my ideas might be implemented, even if I don’t get to see it for another ten years.

Dr Alex Dent