Problem 1 - Keeping the Keys Secret
Most encryption is based on applying a Key to a Message to generate Ciphertext. Hopefully both parties to a communication have identical copies of the Key and, equally hopefully, nobody else has a copy of the Key or else they too will be able to decrypt the message.
Hence, the secrecy of Keys is, arguably, even more important than the secrecy of any given message. The first problem is how do you distribute Keys securely unless you have physical contact and can actually hand over the key person to person? This is the classic "Catch 22" in standard cryptography. We need a secure channel to exchange Keys. But we can only establish the secure channel with such keys in the first place.
Problem 2 - Secret Keys for each Separate Pair of Correspondents
The second problem is the sheer number of keys we each need to maintain (securely) if we are going to conduct secure communications with a large number of other people and organisations. We need a secret pair of keys for each of our potential contacts. This exacerbates the problem of distribution (you haven't got to solve the problem once, but many times) and carries with it the separate problem of "Key Management".
The best solution to this problem to date is the use of Public Key Cryptography(PK). This allows anyone to create a message using the published public key belonging to the intended recipient. Only the holder of the matching private key (hopefully only the intended recipient) can decrypt the message. So why aren't we all using PK for our encrypted communications?
Partly its a performance issue. Encryption of a long message using the large public keys (required for credible security) takes a lot longer than encryption using much shorter (but equally secure) private keys. In fact, anyone using PK almost certainly does not use it for the encryption of the actual message. Instead what most PK systems do is to use the PK only to solve the Key Distribution Problem itself. They exchange private keys which are then used to encrypt the message much faster.
PK also fails to resolve - fully - the initial authentication problem of remote key exchange. i.e. Simply because someone claims a public key belongs to them doesn't actually prove either that it does belong to them or that they are who they say they are. The current solution to that problem is the holding of public keys by Trusted Third Parties who are supposed to make some effort to establish the identity of the Key Owner.
And finally, for the truly paranoid, there is the problem that we don't know just how secure PK really is. It is based on the inherent difficulty of certain mathematical transformations such as factoring large prime numbers, to which no one has yet found an easy or quick solution. However, it is conceivable that some bright mathematician could crack that problem tomorrow morning. In which case, all communications currently protected by PK would be vulnerable to decryption by anyone who could gain access to the ciphertext. Certainly if the message you are transmitting is so sensitive that you want to be sure that no one can read it in, say, 30 years time, then PK is probably not a safe bet. The only currently guaranteed safe bet in those circumstances is a one time pad.
For most remote communicators, however, the one time pad is not a helpful option because the parties need to exchange keys and if they use anything less secure than another one time pad for that exchange, then the key (and any subsequent message) is no more secure than whatever method they used in the exchange.
When implementing our most security dependent product - the anti-counterfeiting protocol - Codel doesn't face a Key Distribution problem because we are required to visit each manufacturer's relevant sites in order to set up the software which will create the VRs and the links to the Codel database. It is probably true to say that we don't require the absolute security of a one time pad for the information being passed between a manufacturer and Codel, but given that we'll be in a position to install the pad securely ourselves, it becomes an obvious choice. It is cheap, easy to implement and does not require reliance on any other parties. Yes it does mean we'll have a key management problem. We need a separate pad for every manufacturer on the system and they will need to be kept securely. But that is less of a problem than establishing a secure channel in the first place.
