We have an Authority Center (CA) generating some public and private keys for each client (more than one pair for each client). One method for sending keys to client is sharing a secret key between CA and client, and then sending key pairs and certificates by symmetric encryption method (with secret key). But overhead will be high, so i need an efficient method with low message overhead and time for key pairs transmission. How can i do it? is there any way to both sides share a secret key and then generates key pairs using it, without transmitting key pairs, (a way that confirm the key pairs are reliable for CA)?

a way is that public keys are hashed to a common value. is it possible for clients to generates such public keys? but i think it takes a lot of time.

it's very important for me, please help me.

  • Why is your CA generating the clients' key pairs?
    – user49075
    Jul 27, 2014 at 21:30
  • Each key pair should be used one period and server not always available.
    – Parham
    Jul 27, 2014 at 21:32
  • What prevents you from using the default method of having the clients generate a key pair and send the public key to the CA in an authenticated manner? (presumably authenticated by a secret key)
    – user49075
    Jul 27, 2014 at 21:37
  • Is it that the client can't afford to resend it the necessary number of times?
    – user49075
    Jul 27, 2014 at 21:40
  • I edited my question, key pairs should be reliable for other clients (CA should confirm them).
    – Parham
    Jul 27, 2014 at 21:49

1 Answer 1


is there any way to both sides share a secret key and then generates key pairs using it

You can derive further keys from an initial shared key, there are various key derivation mechanisms that would allow you to do this, but you still have the problem of distributing the initial key. Anyone who intercepts this key could replicate the derivation process and derive the same subsequent keys, so you still need to securely transfer this initial key and you have the same problem you started with. This applies to your suggested solution as well; wrapping the keys with a shared secret is a sound idea but you still need a way of securely sharing that secret.

Key distribution is probably the single most difficult part of implementing a cryptographic system. Distributing symmetric/secret keys, as would be needed in the solution you mention, is especially difficult, which is why they are often negotiated wrapped under asymmetric keys, such as is the case for SSL and similar, as the encryption is done using the public half of the receivers key which is not confidential, but you then still have the issue of distributing and verifying the public keys you are using to encrypt the symmetric keys, which is often solved by implementing an entire PKI (public key infrastructure) system, which includes CAs (certificate authorities).

You do mention using a CA, but what you are describing does not seem to be the manner in which a CA usually operates, which would usually involve the client generating their public/private key pair then sending the public half to the CA to be signed and receiving a certificate in return. These certificates can be verified by other clients due to them including the root CA certificate in their store of trusted root certificates. You've described in the comments why you're doing it differently but I'm still not sure I really follow your reasoning...

It also surprises me that the overhead of a simple symmetric encryption is too high for you. Have you actually tested the performance of this and deemed the performance hit to be unacceptable? This smells a little like premature optimisation to me, as symmetric encryption is not particularly computationally expensive (unlike asymmetric, which is why asymmetric is usually only used to negotiate a shared symmetric key which is used for any subsequent data encryption). If the overhead of a single symmetric key wrapping is too intensive then I would be surprised if you have the computational power to use encryption at all, and possibly you should rethink your approach to what it is you are attempting to do.

  • your right. my question needs more comments.
    – Parham
    Nov 15, 2014 at 15:05
  • privacy is important in this network. so key pairs are exchanging periodically.it means CA should send a set of key pairs for each client. therefore message length is too long. if there is a way for client to share a secret number with CA, is it possible for both sides (CA and client) to use this secret num and create key pairs? if possible, communication overhead will be low.
    – Parham
    Nov 15, 2014 at 15:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .