nRF9160DK ECDSA non-deterministic

RE: nRF9160DK ECDSA non-deterministic

dejans — Thu, 29 Sep 2022 11:41:42 GMT

Hi,

Yes, you cannot do anything now using our library.

Best regards,
Dejan

RE: nRF9160DK ECDSA non-deterministic

Gioele — Tue, 27 Sep 2022 22:00:35 GMT

So I can't do anything for now...

RE: nRF9160DK ECDSA non-deterministic

dejans — Tue, 27 Sep 2022 15:11:24 GMT

Hi,

[quote user="Gioele"]I only want to verify my ecdsa.[/quote]

I understand that. Unfortunately, it seems that your request exceeds what we are currently supporting with our binary library.

Best regards,

RE: nRF9160DK ECDSA non-deterministic

Gioele — Sun, 25 Sep 2022 16:42:44 GMT

I understood that. I only want to verify my ecdsa.

RE: nRF9160DK ECDSA non-deterministic

dejans — Fri, 23 Sep 2022 15:34:20 GMT

Hi,

Unfortunately, our binary library provides a specific set of features that does not include Ethereum block chain support.

Best regards,
Dejan

RE: nRF9160DK ECDSA non-deterministic

Gioele — Thu, 22 Sep 2022 09:55:46 GMT

int verify_message(void)
{
	psa_status_t status;

	LOG_INF("Verifying ECDSA signature...");

	/* Verify the signature of the hash */
	status = psa_verify_hash(pub_key_handle,
				 PSA_ALG_ECDSA(PSA_ALG_SHA3_256),
				 m_hash,
				 sizeof(m_hash),
				 m_signature,
				 sizeof(m_signature));
	if (status != PSA_SUCCESS) {
		LOG_INF("psa_verify_hash failed! (Error: %d)", status);
		return APP_ERROR;
	}

	LOG_INF("Signature verification was successful!");

	return APP_SUCCESS;
}

This is the code to verify our sign but we don't know the public key.
The problem is always the same, we need some values we can't find inside this library.
For example, we could obtain the public key from the private key but we need the generation point G.

"The public key is calculated from the private key using elliptic curve multiplication, which is practically irreversible: K = k * G, where k is the private key, G is a constant point called the generator point, K is the resulting public key, and * is the special elliptic curve “multiplication” operator. Note that elliptic curve multiplication is not like normal multiplication. It shares functional attributes with normal multiplication, but that is about it. For example, the reverse operation (which would be division for normal numbers), known as “finding the discrete logarithm”—i.e., calculating k if you know K—is as difficult as trying all possible values of k (a brute-force search that will likely take more time than this universe will allow for)."

We need to use the verify method but we need the correct values.

RE: nRF9160DK ECDSA non-deterministic

dejans — Mon, 19 Sep 2022 16:41:37 GMT

Hi,

In order to get to common understanding, I would suggest that you read chapter 4.1.4 verifying operation.

Best regards,
Dejan

RE: nRF9160DK ECDSA non-deterministic

Gioele — Fri, 16 Sep 2022 11:13:39 GMT

We understood that the Nordic code doesn't fit correctly with Keccak256 and Ethereum but we saw that after some attempts the ECDSA is correct.
So this is our idea. We could verify each time the correctness of our ECDSA and when the ECDSA is correct we can use that sign.

cryptobook.nakov.com/.../ecdsa-sign-verify-messages

ECDSA Verify Signature

The algorithm to verify a ECDSA signature takes as input the signed message msg + the signature {r, s} produced from the signing algorithm + the public key pubKey, corresponding to the signer's private key. The output is boolean value: valid or invalid signature. The ECDSA signature verify algorithm works as follows (with minor simplifications):

1.

Calculate the message hash, with the same cryptographic hash function used during the signing: h = hash(msg)

2.

Calculate the modular inverse of the signature proof: s1 =
$s−1(modn)s^{-1} \pmod n$

3.

Recover the random point used during the signing: R' = (h * s1) * G + (r * s1) * pubKey

4.

Take from R' its x-coordinate: r' = R'.x

5.

Calculate the signature validation result by comparing whether r' == r

The general idea of the signature verification is to recover the point R' using the public key and check whether it is same point R, generated randomly during the signing process.

There is the verification of ECDSA implemented by Nordic but we need the Public key. We only have the private key.
Thank you!

RE: nRF9160DK ECDSA non-deterministic

dejans — Thu, 15 Sep 2022 14:16:43 GMT

Hi,

Unfortunately, we do not have support for Ethereum. It is not supported in CryptoCell hardware which means that software implementation would be needed.

Best regards,
Dejan

RE: nRF9160DK ECDSA non-deterministic

Gioele — Wed, 14 Sep 2022 15:53:22 GMT

Is there a way with this code to verify the signature of ECDSA?

Thank you very much!

RE: nRF9160DK ECDSA non-deterministic

Gioele — Tue, 13 Sep 2022 15:01:49 GMT

So There is nothing that can I do..?

RE: nRF9160DK ECDSA non-deterministic

dejans — Tue, 13 Sep 2022 14:52:26 GMT

Hi,

The issue is not whether your keccak256 is correct or not. There is a notion on the algorithm being used. Even though keccak256 and sha-256 have the same length, they cannot be used interchangeably. You use PSA_ALG_DETERMINISTIC_ECDSA(PSA_ALG_SHA_256) in the code, but even with hashed input, the result might be wrong. It is important that you use same hash algorithm as the input.

Best regards,
Dejan

RE: nRF9160DK ECDSA non-deterministic

Gioele — Tue, 13 Sep 2022 14:22:10 GMT

We are sure that our keccak256 is correct. Are you saying that the problem is the input? Both Keccak256 and SHA256 have the same length. In each case, we noticed that sometimes our output is correct. What should we do now? We need that our code works!
The code of the example supports the ECDSA non-deterministic.

RE: nRF9160DK ECDSA non-deterministic

dejans — Tue, 13 Sep 2022 14:15:06 GMT

Hi,

I have got a prompt reply.

We currently do not support Ethereum blockchain neither in MbedTLS nor in crypto runtimes. In addition, we do not support keccak256. We only support Deterministic ECDSA using HMAC_DRBG which uses SHA-256. In this case, SHA-256 (not keccak256) is the only valid hash for the input. We check deterministic ECDSA with SHA-256 and verify it with NIST test materials. It seems that the root issue in your case is keccak256 which is not supported and therefore leads to a wrong result.

Best regards,
Dejan

RE: nRF9160DK ECDSA non-deterministic

dejans — Tue, 13 Sep 2022 11:02:34 GMT

Hi,

Please note that the reply might not be quick, but I'll inform you when I get it.

Best regards,
Dejan

RE: nRF9160DK ECDSA non-deterministic

Gioele — Tue, 13 Sep 2022 09:49:04 GMT

Perfect, I hope for a quick reply. For now, thank you very much!

RE: nRF9160DK ECDSA non-deterministic

dejans — Tue, 13 Sep 2022 08:49:07 GMT

Hi,

I have made an internal inquiry related to your question.
We are planning to perform some tests. Please note that this may take at least several days. I'll get back to you when I get new information.

Best regards,
Dejan

RE: nRF9160DK ECDSA non-deterministic

Gioele — Mon, 12 Sep 2022 13:04:53 GMT

I send the transaction to the Blockchain, or I just use a transaction decoder. These methods show me if the transaction is correct or not.

RE: nRF9160DK ECDSA non-deterministic

dejans — Mon, 12 Sep 2022 08:32:35 GMT

Hi,

Which criteria did you use to determine the validity of the raw transaction?

Best regards,
Dejan

RE: nRF9160DK ECDSA non-deterministic

Gioele — Fri, 09 Sep 2022 17:51:10 GMT

Okay, now I will try to explain all the procedures.
Like I said we need to create a raw transaction for an Ethereum Blockchain.
To create the raw transaction we need to follow some steps:
1)Make the RLP of the information
2)Make the Keccack256 of the RLP above
3)Make the ECDSA of the Keccack256 resulting
4)Make another time the RLP of the information plus the values of the sign of the ECDSA

We make this procedure for any time we need to create a transaction.
We use ECDSA non-deterministic so the values of the sign are different every time. We are mathematically sure of the whole procedure, the only thing that we can't be sure of is the ECDSA. Sometimes the raw transaction is correct the first time, sometimes we need to repeat the procedure to obtain different sign values because not always the raw transaction is considered valid. The problem is related to the ECDSA.

RE: nRF9160DK ECDSA non-deterministic

dejans — Thu, 08 Sep 2022 15:43:16 GMT

Hi,

[quote user=""]We discovered that ECDSA non-deterministic algorithm is not so accurate.[/quote]

Could you describe the procedure how you determined that the algorithm is not so accurate? In which way is it not so accurate?

[quote user=""]There is the possibility that the sign of ECDSA is not correct on the first attempt, but we need to execute our application more times.[/quote]

Could you elaborate on this?

Best regards,
Dejan