0

I am reasoning about the following scenario:

  • A server listening on a port
  • A client (always the same) that sends messages

When the server receive a message, it performs an action and then responds to client saying success or failure. The only requirements of this simple communications are integrity of client messages and authentication of the client. The simplest and fastest idea it came to my mind is to generate RSA keys on client side, then store permanently its public key on server side.

The client send messages with this structure
Pr{packet | hash(packet)} where packet is data | time. ( | means concatenation, Pr{abc} means abc encrypted with RSA by private key of client Pr )
The idea is to prevent replay attack with time, provide integrity check with hash(packet) and provide authentication by the means of the encryption with client private key.

Why am I using a custom protocol to do the job instead of TLS socket? Because data are a few bytes, for which I don't require strong symmetric encryption, so TLS handshake is too expensive for the goal. And more, as said the client is supposed to be always the same machine, and it must be the unique machine for which server accepts messages.

Matteo
  • 1
  • 1
    WRT 'Pr{abc} means abc encrypted with RSA by private key of client Pr' - you cannot encrypt a message with an RSA private key. See https://security.stackexchange.com/questions/239219/what-happens-when-i-encrypt-something-with-my-rsa-public-key for more info. – mti2935 Feb 10 '22 at 13:29
  • ok that is clear, maybe I wrote in an ambogous manner, but what I mean is not to provide confidentiality by RSA (encrypt public key, decrypt private key) but to make possible for the server to recognize the message came from the client. The case I described seems to be similiar to digital signature, that provides non-repudiation. My question so becomes "Does non-repudiation implies authentication, if we prevent replay attacks?" – Matteo Feb 10 '22 at 13:40
  • Is this a connected or non connected protocol, and if not connected what it expected in case of a packet loss (a request never reaches the server or the client rever receives its response for any reason,)? – Serge Ballesta Feb 10 '22 at 14:19
  • That is connected, I was planning to make it work on TCP protocol, so there is no management of packet loss because of the assurance given by TCP. – Matteo Feb 10 '22 at 14:22

0 Answers0