Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Imagine a SSL-like protocol that instead of using certificates signed by a trusted CA, has the server's public key hard-coded in the client. My question is: what happens if the server's private key is compromised? Without certificates, the system doesn't have a CRL (Certificate Revocation List) and until the users update the client, the attacker can impersonate the server. How can one build a system that makes public-key revocation possible while having the public-key hard coded in the client?

share|improve this question
The trivial answer is to use a CA and hard code the public key of the CA in the client. I presume you thought of that already, so what is wrong with that solution? – Henrick Hellström Apr 16 '14 at 0:30
hardcode a 2nd revocation key into the client? – Richie Frame Apr 16 '14 at 3:22

If the application completely trusts the public key (e.g., runs code signed by it), then you could add "master key change" messages that can be signed by it, that make the application change it's hard-coded key. For additional security, you could require that the new key be additionally signed by a key hopefully separated from the now-compromised one - here decent options are either an additional more-secured key or confirming the new master key via HTTPS (trusting the CA hierarchy).

Of course in all methods you must ensure the client gets reasonably recent revocation messages - which may require periodic signing of "non-revocation" messages - but note that CRLs have this problem too.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.