The Key Management Problems With Public Key Cryptography

by Krishna on September 27, 2011

Sometime back, I had drawn a diagram to explain public key cryptography, but it is not complete. As Eric Lippert explains here, there are four management problems with them. To paraphrase him,

  1. If the sender does not keep their private key secret, then the saboteur can send a false message that seems to be coming from the sender.
  2. If the receiver does not keep their private key secret, then the spy (eavesdropper) can listen to any message sent to the receiver.

The other two are:

Somehow [both sides] had to securely exchange public keys. Why’s that? […] If Alice sends her public key to Bob over an insecure channel then Mallory can intercept the message and replace Alice’s public key with Mallory’s public key. Mallory now knows Alice’s public key, and Bob believes that Mallory is Alice!

This problem is in practice solved by both the client (you) and the server (the web site) agreeing to trust a third party called the Certifying Authority, or CA.  Now we have yet another key management problem. The CA has to keep their private key a secret, and the CA has to somehow tell you what their public key is without being attacked by a man in the middle purporting to be the CA!

This is the point where the crypto stops. The secure transmission of the CA’s public key is the piece that has to be accomplished without using any crypto. How you accomplish that is up to you; typically the operating system comes pre-installed with a list of known public keys of certifying authorities that have been verified independently by the operating system vendor.

So, here is the original diagram with a minor modification to note the role of the Certifying Authority. Also, a quick link to Google for more images related to public key cryptography.

Public Key Cryptography and Certifying Authority


Bhaskar Chowdhury September 28, 2011 at 1:22 am

Cool!!! I have been using GPG with Thunderbird for quite sometime personally. And uploaded my public key one of the key server( there are many) one of them is : You can also publish your public key there so others can sign it and utilise it to sen messages with encrypted form to you. Kudo to Phil Zimmerman,,the guy who wrote PGP.
I have had the experience in the corporate that whenever they assign a notebook to a user ,they hashed it with the underlying data will be safe..if that notebook got stolen(experiance out of my INTEL job 4 years back).It;s a kinda de facto standard or corporate policy.

But for SSL over the HTTP share a different way as far I as I know.In one of my previous assignment with a chennai based client I have done an end to end SSL implementation for them. The certifying authority was Thawte ..IIRC ..that was was ROR running on CentOS for an UK client..ohh it remind me of all those entropy…urandom…pools….Hard way came to know those.

To me security should be like ring of onion..if malicious user breach one..then he has to prove to the next level to go forward….moreover security is an ongoing activity ..constant vigilance is required…no system in this world are “Secure” ..there are just more level of hardle to come over.

Last , if the private key got compromised the we can revoke it..option is there to create revocation certificate and should keep it in a non accessible place like external media.

Krishna September 28, 2011 at 4:42 pm

Thanks for the comment, Bhaskar. Lots of interesting stuff there.

The other side of security is usability. Sometimes, security is not as hard as it could be because it would make it very difficult for end users to use an application.

Bhaskar Chowdhury September 29, 2011 at 1:32 am

Dead right Krishna!!

Comments on this entry are closed.

Previous post:

Next post: