I am using AES to create a secure tunnel for transmission of data.

As the symmetric key encryption will require the same key to encrypt and decrypt, so we need to generate the exact same key for the decrypt process. Is there any possible way for me to generate the exact same key for both side?


There are two main ways to have the same symmetric key on both parties:

The former is what you will find in TLS, where public key infrastructure is used to verify the other party's public key.

The latter is used in things like command-line encryption tools to derive a symmetric key from a password (and salt).

If you wish to setup a secure communications channel, your first choice should be TLS unless you have a very good reason not to use it.

| improve this answer | |
  • $\begingroup$ known secret? the known shared secret? Not clear how the client and server will get the same key? What happened to DHKE so that FPS is guaranteed. $\endgroup$ – kelalaka Oct 5 at 9:15
  • 1
    $\begingroup$ The shared secret is the password in the case of a PBKDF. With the same parameters (salt and iteration count) you get the same generates key. DHKE falls under the first bullet point: key exchange. $\endgroup$ – Marc Oct 5 at 9:29
  • $\begingroup$ Not exactly, DHKE is not encryption that you explained in the parenthesis about asymmetric cryptography. How do you send the password securely then? If there is already a secure channel no need to work with passwords. $\endgroup$ – kelalaka Oct 5 at 9:34
  • $\begingroup$ True, dropped the parentheses. The public key crypto aspect was the important point. The channel for PBKDF is usually a more human friendly one, hence the need for a password rather than a binary key. It doesn't mean that channel can be used to send large amounts of binary data (eg: handing you a USB key and telling you the password or loud). $\endgroup$ – Marc Oct 5 at 9:40
  • 1
    $\begingroup$ I mean, you want to send the password clearly then derive the same symmetric key. That is insecure even for the login. There should be already a secure channel for this. Also, Passwords tent to have low entropy. I would rather stick to ECDH then KDF or RSA-KEM then KDF. $\endgroup$ – kelalaka Oct 5 at 9:46

Your Answer

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

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