Nonce length issue using libsodium JS

I am looking to use Libsodium JS on my site for various cryptographic operations aimed at hiding the actions of my visitors from their ISP or any other passive observer of the network (in addition to the use of an SSL/TLS certificate).

However, I am having difficulty, particularly with the crypto_secretbox_easy() function.
Indeed, when I call this function, I receive an error stating that the length of the nonce is invalid.

Here is my code (or at least code following the same reasoning) :
var a=sodium.crypto_kx_keypair(),b=sodium.crypto_key_keypair();  //Generation of two key pairs var e=sodium.crypto_kx_client_session_keys(a.publicKey,a.privateKey,b.publicKey);  //  Calculation of exchange keys var n=sodium.randombytes_buf(sodium.crypto_secretbox_NONCEBYTES); // Nonce generation var encrypted=sodium.crypto_secretbox_easy('my message',e.sharedRx,n);

So, I wanted to see what was wrong. I went directly to the line where the error was triggered, and using the "Sources" tab of the DevTool, I modified the line so that it logs the length of the nonce received and that of the expected nonce.
As expected, the requested length was 24 bytes, but the length received was 32 bytes, regardless of the length of the nonce entered into the function (I tried all numbers between 0 and 7500).

Do you understand anything about it ?
Thank you in advance for your answers.

Welcome to CodeRanch!

Are you sure that the order in which you pass the nonce and the key to the encryption function is correct?

I'm curious, what's the reason you're not relying on just TLS?

Stephan van Hulst wrote:Welcome to CodeRanch!

Are you sure that the order in which you pass the nonce and the key to the encryption function is correct?

I'm curious, what's the reason you're not relying on just TLS?

Thank you for your response and your welcome.

I'm pretty sure I passed the arguments in the right order (otherwise I would have received an error on the type of my arguments), as for the reasons for using the library in addition to the certificate, here they are:

Laws have recently been passed in France, and they will greatly reduce freedom of expression and anonymity online.
My site will include a proxy system in the browser (the idea is to pass traffic from the active tab through the servers hosting my site, they are located in the Russian Federation, and therefore are not restricted in the same way ) as well as end-to-end encrypted messaging.

In order to ensure the security of messages transmitted and the anonymity of activities carried out, I need to add additional encryption managed by my systems.
This helps avoid an advanced MITM scenario with impersonation of my server.

Éloi Marchand wrote:I'm pretty sure I passed the arguments in the right order (otherwise I would have received an error on the type of my arguments)

So what's the type of the arguments? Aren't both the nonce and the key just supposed to be byte arrays?

Anyway, I'm relatively certain that you're supposed to pass in the message first, the nonce second, and the key third.

Ah... yes, it's not stupid, that would explain the length of 32 bytes...
Thank you for your response, I will think before posting next time

No problem.

Oh, another thing. The code you showed us is only being used to try out the library, right? When it's time to write the real thing, you'll not generate both key pairs in the same application?

Can you tell us how you're planning to communicate the public keys between the applications?

Indeed, the code provided was only there for illustration.

The idea to get the other party's public key is:

- The client generates its key pair and stores it in localStorage
- It sends a clear request to the server including the public key
- The server performs various checks (example: if the client's IP is banned)

If the request is accepted, the server generates an identifier and a key pair, which it stores in a database along with the client's public key; then it returns a response containing the generated identifier and the generated public key. The client will use the key to obtain exchange keys, to encrypt messages and the identifier to identify itself to the server.

If the request is refused, the client will be displayed an error message including the cause of the refusal.