cross-posted from: https://lemy.lol/post/4569543

I need to

  • encrypt JSON payload (not just sign)
  • not share private key
  • verify the payload is generated with the shared public key and RSA fitting all of these.

As I’ve only made auth with JWT so far, I’m not sure. If I use RSA, I guess I have to put the encrypted text in the body.

Do you think it can be used? Any other suggestions?

    • iso@lemy.lolOP
      1·
      1 year ago

      We are developing an application in which we will collaborate with a financial institution. That’s why I think it should be extra secure and applicable against MITM attacks.

      The process will work as follows;

      • The user sends the stock pool he wants to invest to our client.
      • Our client sends the user ID and stock pool to our application.
      • We send the optimal stock selections back to the client.

      I’m not sure if mutual authentication fits this.

      • andrew@lemmy.stuart.funEnglish
        4·
        1 year ago

        mTLS would be sufficient and honestly more than enough, it sounds like. Plain TLS (client validates the server) will encrypt all traffic in transit end to end, using appropriate handshakes and symmetric cyphers. Anything using RSA directly will be significantly more likely to be incorrectly implemented and thus worthless.

        mTLS would allow you to trust a CA per user, a cert per user, or issue your own keypairs for clients, depending on the use case. You validate the connection and look up the client based on some certificate field like CommonName or any of the other fields.

        Then you’ve authenticated, and you can perform authorization for any transactions on that entire connection, plus you know for certain if it was MITMed it was done by someone with access to keys trusted by both parties.

      • towerful@programming.dev
        2·
        1 year ago

        So what part are you wanting to protect?
        The user to your client? The client to you? Or essentially end-to-end between the user and you, but via your client?

        Perhaps an alternative way?
        The user sends the stock pool to the client, they give the user a transaction key. The user submits the transaction key to you, you fetch the transaction details from the client, then you process them?

        I guess I’m failing to understand why the payload needs to be encrypted everything is already travelling over an encrypted medium (IE TLS/HTTPS).

        • iso@lemy.lolOP
          1·
          1 year ago

          The client wants to encrypt the payload while sending to us. I hope they know why they want this :)