I'm trying to get a secure way of exchanging keys between my client application and the server.

The goal is to encrypt all XML messages with AES256. These XML's will be transferred to the server using https (post). yes i know the AES256 probably is overkill as it will already use HTTPS, but security is very important in my case as it is financial data i'm transferring.

The reason i use AES256 is that it is still very strong, and practically unbreakable (if implemented correctly, which is why i am here)

i have the same general idea of this question: Is this RSA/AES combination good? But i want to make the implementation safe.

my current idea:

  • Setup a CA (i can install the certificate on the client in a secure environment)

  • Client generates RSA keypair, and sends public key to server. (could also be in secured env)

  • Client requests key exchange (signs request with RSA)

  • Server generates new AES key Server encrypt key with public key of

  • client Server send encrypted key and signs the message with RSA

  • Client checks signature and decrypts key

After this i want to do a verification step, but i'm not entirely sure what the best way is for this. i was thinking of letting the client encrypt the AES key with the pub key of the server, and sign the message. then the server can decrypt again, but then i'm transferring the key again and i'm not sure if this can be a security risk.

Please note that all of these messages are already transmitted over https (with valid cert)

Is this a secure way? or is there a better/easier way?

another note: The server will not accept a new key request if that client already has one (every client has a unique ID) But if necessary the server can force the Client to generate a new key. New keys can possibly even be forced on a random time.

I just realized I forgot to explain one important thing:

The key exchange needs to happen once, after this the key needs to be stored locally. As the client application still needs to be able to encrypt messages while there is no internet connection. at that point there is a que of encrypted messages.

So it is not like I'm doing the exchange every time, but only once (or once per month) to exchange keys so that the AES encryption can continue.

  • 1
    I think you may not need RSA. Why not just download key via HTTPS? There's key exchange in it already and you can have user cert for it. And setup dedicated server for downloading key to reduce attack surface - if your key server is broken, the message will still not be read, and if your message server is broken, the message will not be read as well. – Aria Jul 21 '16 at 10:49
  • And the server to which you upload do not need to decrypt message. XML can be moved to another server which then retrieves key from key server. – Aria Jul 21 '16 at 11:03
  • So if i understand you correctly: i use HTTPS protocol to download the KEY (is there a special protocol for this?) And for the XML message, i'm not sure waht you mean i do not need to decrypt the message. Or do you mean having a server special for decrypting XML file's and sending them over to the actual service? – Nick Jul 21 '16 at 11:04
  • Especially if this is for something finance-related, do not roll your own crypto. Use something tried-and-true instead. Lots of people spend lots of time trying to build encryption products and get it wrong. And if you insist on rolling your own cryptography, know exactly what you are protecting against and why your scheme protects against that. – a CVn Jul 21 '16 at 11:54
  • I want to use as much standarized stuff as possible, only fixed thing is that i need to use AES256 (or similar) as an extra layer of encryption. this encrypts the XML files the application uses to communicate. but my issue is getting the keys safely synced once as the encryption needs to continue even without internet. so i do not want to use my own crypto, RSA just seemed the best way at the moment to get the keys where they belong. What should i use instead? I'm not sure sending the key over https is accepted. – Nick Jul 21 '16 at 11:59

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.