1

This question already has an answer here:

I have a client - server setup with TLS communication. I want to be sure of mutual authentication.

The safety that certificates can offer assumes that the private key that links to the certificate remains private. But isn't this the same as assuming a pre-shared key remains private? Because both the client and the server are programmed at my computer, can't the exchange of the key be done just as safe in advance?

So is using a certificate at both ends any safer then a Pre-shared key in this scenario? And is there any other advantage that certificates can provide?

marked as duplicate by Lucas Kauffman, Xander, Adi, TildalWave, Steve Jan 17 '14 at 18:32

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

3

"Pre-shared key" is indeed a valid model, and simple, if you can pull it off. Asymmetric cryptography, with public and private keys, and certificates, was invented to solve the secret key distribution problem: in general, it is hard to ensure that all pairs of systems/people who must securely talk to each other actually share a secret value. In a client-server setup, where client and server are distinct machines, then a shared secret must necessarily have travelled from one machine to the other. Travelling secrets are "less secret". With asymmetric cryptography, only public values actually go over the wires; private keys can remain local through their complete life cycle, and that's usually a good idea.

Similarly, if client and server share the same secret value, then an attacker hijacking either machine learns the secret and can impersonate both. With asymmetric cryptography, an attacker who plunders the RAM or disk of the client can later on connect to the server and authenticate as a client, but cannot run a fake server which would fool the client.

These are reasons why a pre-shared key mechanism, though tempting (it is lighter on CPU, and involves none of the dreaded X.509/CA business), make in practice imply some weaknesses, depending on how the system is installed and maintained.

(Of course, in all of the above I suppose that you do not do anything stupid, such as having a shared "secret" between the server and 10000 clients; if 10000 clients know a "secret" then it no longer is a secret. Appropriate pre-shared key systems use a different key for each client-server pair. When the pre-shared key is a human-remembered secret, i.e. a password, then extra care must be employed, because passwords are weak; this can be managed with SRP.)

  • So if I understand it correctly, when i have 10000 clients the following would be true: Pre-shared key: server has 10000 keys and each client has one key. Certificates: the server has one certificate and each client has its own certificate. To me they both sound impractical, so how can this be done? – mstrdenz188 Jan 20 '14 at 7:44
  • With certificates, each system just has to store one private key (its own). Even the server does not need to store the clients' certificates: the client just sends it during the handshake. The real gain, though, is that with certificates no private key has ever to travel from system to system. – Thomas Pornin Jan 20 '14 at 12:19

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