Hello everyone,
I was looking at SPAKE2+ example (NCS v2.6.99) and trying to understand where the password used to derived the shared secret is set or used. Can anyone help me?
BR.
Hello everyone,
I was looking at SPAKE2+ example (NCS v2.6.99) and trying to understand where the password used to derived the shared secret is set or used. Can anyone help me?
BR.
The SPAKE2+ algorithm itself does not operate on a password, but rather an already hashed password; where the first half of the hash is denoted w0 and the second half w1.
Typically, a nordic chip acts as the verifier and a smartphone/tablet/computer acts as the prover (typically with a user interface with a password field or qr code camera). The cpu at the prover is powerful enough to perform a slow hash operation such as scrypt or Argon2. The verifier only stores a pre-hashed verifier entry and thus does not perform any hashing. Therefore, you will not see any API function taking a password.
The API takes w0 concatenated by w1*P for the verifier instead of a password. The idea is to pre-hash this value on a different device and then transfer this data over to the verifier device and store it on flash. I suggest that you read RFC9383 to get familiar how the mechanism works.
The example code as well as the PSA API unfortunately calls the verifier "public_key". This is certainly not a public key but the password hash and should hence not be leaked, since an attacker in the possession of this can perform a brute force attack to recover the password. Remember that SPAKE2+ is designed to operate on passwords with low entropy.
The SPAKE2+ algorithm itself does not operate on a password, but rather an already hashed password; where the first half of the hash is denoted w0 and the second half w1.
Typically, a nordic chip acts as the verifier and a smartphone/tablet/computer acts as the prover (typically with a user interface with a password field or qr code camera). The cpu at the prover is powerful enough to perform a slow hash operation such as scrypt or Argon2. The verifier only stores a pre-hashed verifier entry and thus does not perform any hashing. Therefore, you will not see any API function taking a password.
The API takes w0 concatenated by w1*P for the verifier instead of a password. The idea is to pre-hash this value on a different device and then transfer this data over to the verifier device and store it on flash. I suggest that you read RFC9383 to get familiar how the mechanism works.
The example code as well as the PSA API unfortunately calls the verifier "public_key". This is certainly not a public key but the password hash and should hence not be leaked, since an attacker in the possession of this can perform a brute force attack to recover the password. Remember that SPAKE2+ is designed to operate on passwords with low entropy.
Hi,
Our PSA Crypto API Implementation implements the PSA Crypto API specification. You could consider opening discussion on specification there.
Here is relevant discussion on the use of public key.
Best regards,
Dejan
Hello,
Thank you for your response.
Does your example follow the RFC 9383 specification? In your example, the first two exchanged messages are both 65-byte messages (0x04 followed by 64 bytes), which I assume represent the X and Y coordinates - each 32 bytes. These first two messages should correspond to:
Next, I see that the following pair of messages consists of 32-byte messages. Could you clarify what exactly these intermediate messages represent? I understand that both parties need to compute the shared secret curve points (Z and V) and then derive a shared secret from these points, but I’m unsure of the role of these intermediate messages.
Finally, the last set of messages should serve as confirmation or "evidence" that both parties possess the password and that the process was successful. In your example, this confirmation message is also 32 bytes long, but I was expecting (and require) a 16-byte message instead. Would it be possible to adjust this? Specifically, I need to use the last configuration from the table in the provided link:
G: P-256 and CMAC-AES-128 (I need CMAC instead of HMAC) to obtain a 16-byte confirmation value.
I appreciate your guidance on this.
Best regards.
Hi,
Portilha said:Next, I see that the following pair of messages consists of 32-byte messages. Could you clarify what exactly these intermediate messages represent?
Which intermediate messages and 32-byte messages do you refer to?
Best regards,
Dejan
The second message exchange (different values for verifier and prover), before the final message that has the same K_shared. Also, I want to know if there is any way to adjust the example to use CMAC-AES-128.
BR.
I want to have something like this example:
Where the CMAC output (confirmP and confirmV) are both 16 bytes.
BR.