2

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?

zebiskin
  • 31
  • 5

1 Answers1

15

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.

Marc
  • 1,583
  • 1
  • 16
  • 16
  • 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. – kelalaka Oct 05 '20 at 09:15
  • 1
    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. – Marc Oct 05 '20 at 09:29
  • 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. – kelalaka Oct 05 '20 at 09:34
  • 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). – Marc Oct 05 '20 at 09:40
  • 1
    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. – kelalaka Oct 05 '20 at 09:46
  • And key exchange might also include key agreement for the forward secrecy variants. – eckes Oct 05 '20 at 20:54
  • There are Password Authenticated Key Exchange algorithms that can be used over an open channel, but they're a form of key exchange that happens to involve a password. So more bullit point 1 than point 2. – SAI Peregrinus Oct 05 '20 at 22:41
  • @kelalaka If you have ever used WiFi at a friends house, you have used the password method (Pre Shared Key) - and it works quite well, think how much more cumbersome it would be to solve the problem of connecting to a WiFi with an asymmetric key exchange. – Falco Oct 06 '20 at 07:49
  • @Falco honestly, I was adding it to my comments, however, from the security perspective it lacks forward secrecy. SO. not added. – kelalaka Oct 06 '20 at 09:48