Score:0

Is the Key Exchange authenticated and confidential?

in flag

I have made a private messaging program and would like to check that nothing is stupid in my use of cryptography. I am an amateur and nothing is for production. I thank you in advance.

The message exchanges are encrypted end-to-end with AES-OCB. The session key is exchanged as follows:

At the beginning, the private key is loaded and the public key is generated. The server sends its public key to the client. The client verifies the public key of the server with a know_host file. In this file the host addresses are stored hashed (sha256) with their public key (sha256). The client checks that the received public key is the right one, otherwise the sha256 fingerprint of the public key is displayed for verification by the user.

The client generates the 128 bits session key and encrypts it with the server's public key. The client sends to the server: the encrypted session key, its public key, the RSASSA-PSS signature (sha256) of the session key.

The server verifies the identity of the client with its own know_host file. It decrypts the session key. It verifies the signature of the session key with the client's public key.

Both parties are authenticated and have the session key, normal communication begins.

Score:1
kr flag
  1. Your scheme has no forward secrecy. If an attacker obtains the server private key someday, all past sessions can be decrypted: Session keys can be decrypted and thus the corresponding sessions can be decrypted. See details here.

  2. You scheme is prone to replay attack. If the attacker intercepts the traffic and knows the meaning of particular part of the encrypted data, then the attacker can send these data again. If it is done within the same session, then the same encryption key is still used, and it will be impossible to detect if the message was really send by the other side or if it was sent by the attacker. Depending on the message semantic, it can be dangerous. See details here.

SAI Peregrinus avatar
si flag
Also the method the client uses to encrypt the session key wasn't specified. If it's RSAES-OAEP, that's OK, but just about anything else is going to have some caveats or be downright unsafe. And it's arguably better to use RSA-KEM or ECDH to generate a shared secret rather than encrypt and send one.
kr flag
@SAIPeregrinus: Sure. And SSH tunnel or TLS would be better than self made protocol.
SAI Peregrinus avatar
si flag
Agreed. Or at least a Noise protocol, if SSH or TLS (or Wireguard) don't work for whatever reason.
in flag
For the encryption of the session key I use RSAES-OAEP. If I use ECDH for the session key exchange, will the "no forward secrecy" problem be solved?
kr flag
@Laurent57: Not quite. It should be ECDHE, ephemeral ECDH. Then you will have forward secrecy.
in flag
Thank you for your helpful answers, I value your feedback.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.