There is a key exchange process which I am having a look at. I am aware of key exchange algorithms such as Diffie-Hellman and the like, however as there is a method to provide an initial key out-of-band (in this case with the installer of the agent) this was proposed as an alternative. Ignoring any potential comments about the actual use of this (i.e. assume we can't use some kind of web of trust solution and just using TLS etc is not feasible), as there are other steps and constrains not relevant to the security of this specific process - can anyone see any flaws in this specific process?


  • 'Agent' is installed, the current RSA Public Key of the 'Central Server' is bundled into the Agents installer

  • Upon starting - the agent will generate an RSA Keypair and will encrypt its public key using the Central Server's public key.

  • The agent will then send this to the Central Server which will decrypt it using its Private Key

  • The Central Server will then generate a random symmetric key (say AES key for arguments sake) and will encrypt this newly generated symmetric key with the Agents RSA Public Key

  • The Central Server will then send this encrypted Symmetric Key back over to the Agent, which can decrypt it with its own RSA Private Key

Overview of the process

The two hosts now have a symmetric key to encrypt further communication between them with. I was worried about a potential MITM attempt of step 1 where an attacker can replace the Agents public key with their own, however if they don't have access to the servers public key then they can't do this as it will fail to decrypt right? Am I missing anything?

  • 1
    This looks overly complex to me: It is unclear for me why you generate a key pair at the client, then send the public part encrypted to the server and then let the server create the symmetric key which is send back encrypted with the clients pubkey to the client. It would be simpler to just let the client create the symmetric key and send it encrypted with the servers pubkey to the server? This is essentially what RSA key exchange does. Apart from that TLS can be perfectly used without having some kind of PKI. No need to reinvent your own. – Steffen Ullrich Mar 11 at 14:31
  • @SteffenUllrich The thinking was that if we wished to modify the symmetric key generation we would be able to do so without having to update every 'Agent' and can just change the central server process - assuming the key can actually be used in the same manner the agent would not need to know about how the key was generated. This would also rule out platform/config specific bugs if the agent was deployed in different configurations in different places. Does that make sense? – Milney Mar 11 at 14:34
  • 1
    So you design for changes on parts which will likely never happen (how symmetric key gets generated - they should just be random anyway) by adding complexity to the client and implementing your own instead of using known good implementations. And the excuse for this is that you might need to update these parts (unlikely) because why? Maybe you should save some time and costs by using known good implementations (TLS) and better spend the effort to have a robust and scalable mechanism to update the clients - which you need to have anyway. – Steffen Ullrich Mar 11 at 14:41
  • @SteffenUllrich Points noted, as I mentioned there are other constrains and requirements on the overall solution which complicate matters and I have not mentioned them in the post as the focus was on this actual key exchange specifically, but thanks for your insights anyway – Milney Mar 11 at 14:47
  • 1
    And with that gap plugged, it’s almost completely reinvented PKI and TLS (except for the decades of real-world security testing, of course.) – John Deters Mar 11 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.