Skip to main content
Information Security

Return to Answer

added 4 characters in body
Source Link
foreverska
foreverska
  • 2.1k
  • 2
  • 11
  1. Sure.
  2. Okay. The acceptance of both these points relies on me choking on the gut reaction to write "We don't encrypt with asymmetric keys directly."
  3. I don't really understand this one. The client is the one that sent the key to you, not sure why it's necessary to do this challenge and response. If T is some sort of secret, how does it differentiate from the password in step 1?
  4. Fine

HOWEVER

This has ZERO forward secrecy. Compromise of the server private key will enable decryption of all communications, even at a later date. Compromise of the symmetric key by an active attacker in step 2 will lead to decryption of step 4.

As mentioned, writing your own secure protocols is kinda a big no-no. If TLS is a bit much for you, I'd suggest looking at the Noise protocol. The NKPsk0 pattern seems to be what you want (server is known by their asymmetric, clients are known by their preshared secret).

  1. Sure.
  2. Okay. The acceptance of both these points relies on me choking on the gut reaction to write "We don't encrypt with asymmetric keys directly."
  3. I don't really understand this one. The client is the one that sent the key to you, not sure why it's necessary to do this challenge and response. If T is some sort of secret, how does it differentiate from the password in step 1?
  4. Fine

HOWEVER

This has ZERO forward secrecy. Compromise of the server private key will enable decryption of all communications, even at a later date. Compromise of the symmetric key by an active attacker in step 2 will lead to decryption of step 4.

As mentioned, writing your secure protocols is kinda a big no-no. If TLS is a bit much for you, I'd suggest looking at the Noise protocol. The NKPsk0 pattern seems to be what you want (server is known by their asymmetric, clients are known by their preshared secret).

  1. Sure.
  2. Okay. The acceptance of both these points relies on me choking on the gut reaction to write "We don't encrypt with asymmetric keys directly."
  3. I don't really understand this one. The client is the one that sent the key to you, not sure why it's necessary to do this challenge and response. If T is some sort of secret, how does it differentiate from the password in step 1?
  4. Fine

HOWEVER

This has ZERO forward secrecy. Compromise of the server private key will enable decryption of all communications, even at a later date. Compromise of the symmetric key by an active attacker in step 2 will lead to decryption of step 4.

As mentioned, writing your own secure protocols is kinda a big no-no. If TLS is a bit much for you, I'd suggest looking at the Noise protocol. The NKPsk0 pattern seems to be what you want (server is known by their asymmetric, clients are known by their preshared secret).

Source Link
foreverska
foreverska
  • 2.1k
  • 2
  • 11

  1. Sure.
  2. Okay. The acceptance of both these points relies on me choking on the gut reaction to write "We don't encrypt with asymmetric keys directly."
  3. I don't really understand this one. The client is the one that sent the key to you, not sure why it's necessary to do this challenge and response. If T is some sort of secret, how does it differentiate from the password in step 1?
  4. Fine

HOWEVER

This has ZERO forward secrecy. Compromise of the server private key will enable decryption of all communications, even at a later date. Compromise of the symmetric key by an active attacker in step 2 will lead to decryption of step 4.

As mentioned, writing your secure protocols is kinda a big no-no. If TLS is a bit much for you, I'd suggest looking at the Noise protocol. The NKPsk0 pattern seems to be what you want (server is known by their asymmetric, clients are known by their preshared secret).