On defining security – I

I’d use the next few posts to start a discussion on defining security. Satisfactorily defining security is one of the most important enterprises in the theory of cryptography. There’s much to say, and I’m sure there’re many possible divergent views on this. So all the usual disclaimers are in place.

What should a security definition be like? One would expect to get a reassuring guarantee that if a scheme meets the definition, then nothing can go wrong in an unexpected way, when using the scheme. Now, it would be rather presumptuous on the part of a cryptographer to give such a guarantee, for there are other parts in the system which may have nothing to do with the cryptographic protocol (like, say your trusted buddy turns hostile and decides to publish all the e-mails you sent him or her, or say the stock-market crashes and you lose all your money). You wouldn’t want to blame your misfortunes on the poor cryptographer. On the other hand, if you think that your now-hostile buddy managed to find out some of your secrets because of a flaw in a cryptographic protocol, or that you lost money because your competitors managed to cheat in an auction protocol that ought prevent cheating, then by all means, you can ask for an explanation from your cryptographer.

The security guarantee, then, should be an assurance that whatever goes wrong, it won’t be the cryptographer’s fault.

So, how does one give a guarantee that if something goes wrong it won’t be the cryptographic protocol to blame? We shall come back to that question in subsequent posts. For now I just want to leave you with this thought: traditionally (I’d imagine) one indeed used to think of giving security guarantees as giving an assurance that nothing can go wrong in an unexpected way. The major limitation of this — philosophically speaking — is that we can give such a guarantee only in relatively simple scenarios where we know what all can go wrong. For more variable/complex scenarios, we shall give up on such an absolute security guarantee for a protocol, and instead go for a don’t-blame-me/not-my-fault kind of guarantee; it would leave room for things to “go wrong,” but not because of flaws in the protocol.

(Thanks to Jonathan Katz for prompting me to blog on. Well, more accurately he suggested I should either blog more often or just delete the blog. I don’t know if he would be disappointed at the choice I made )