Feature Request: signMessageWithoutRand api of kaspa wasm

[witter-deland]

Is your feature request related to a problem? Please describe.

We have a scenario where we require a stable signature for verification purposes. Currently, the existing functionality in kaspa wasm does not provide a dedicated api for this specific need. Without the signMessageWithoutRand api, we face difficulties in achieving consistent and reliable signature verification, which is crucial for the integrity and security of our operations.

Describe the solution you'd like

We would like the addition of the signMessageWithoutRand api in kaspa wasm. This api should allow us to generate signatures in a stable and deterministic manner, without the randomness factor that may cause variability in the signature generation process. It should accept the necessary input parameters, such as the message to be signed and the relevant key information, and return a signature that can be used for reliable verification.

Describe alternatives you've considered

We have considered implementing our own custom signature generation mechanism outside of kaspa wasm. However, this would require significant additional development effort and may not integrate as seamlessly with the existing kaspa infrastructure. It also poses risks in terms of compatibility and security compared to having a native api within kaspa wasm. Another alternative was to look for workarounds within the existing api set, but we have not found a satisfactory solution that meets our stability and verification requirements.

Additional context

In our application, we have a process that relies on the verification of signatures to ensure the authenticity and integrity of data. The lack of a stable signature generation api has led to inconsistent results in our verification process, which can potentially lead to security vulnerabilities and incorrect data handling. We believe that the addition of the signMessageWithoutRand api would greatly enhance the reliability and security of our overall system.

[elichai]

In our application, we have a process that relies on the verification of signatures to ensure the authenticity and integrity of data. The lack of a stable signature generation api has led to inconsistent results in our verification process, which can potentially lead to security vulnerabilities and incorrect data handling. We believe that the addition of the signMessageWithoutRand api would greatly enhance the reliability and security of our overall system.

Can you explain more on this? how did it affect the results? how are you using those signatures? is it that you hash the data+signature and expect it to reproduce with a new signature? a bit more overview of the usecase would be great and can increase the odds of it merging into rusty-kaspa

[witter-deland]

One use case : use the signature of a specific message as the AES encryption key for some user data

[elichai]

One use case : use the signature of a specific message as the AES encryption key for some user data

Now that's insecure :) the signature is not uniform and should not be treated as "secret"
Why not derive an AES key from the private key and message? (via (H)MAC)

[witter-deland]

In the use scenario of the wallet, the third party will not be given permission to use the private key. Similarly, as long as the wallet application can provide the same message, the signature must be the same, and there is no need for uniform

Such as kasware-wallet/extension#5

One use case : use the signature of a specific message as the AES encryption key for some user data

Now that's insecure :) the signature is not uniform and should not be treated as "secret" Why not derive an AES key from the private key and message? (via (H)MAC)

[elichai]

In the use scenario of the wallet, the third party will not be given permission to use the private key. Similarly, as long as the wallet application can provide the same message, the signature must be the same, and there is no need for uniform

Got it, sounds similar to what StarkWare is doing (using the "deterministic signatures" as private key for their chain), IMHO you should try harder to avoid that and provide some kind of HMAC API, signatures are usually logged into log files by wallets and are not considered secrets