Allows to sign using the BLS curve #121

spalmer25 · 2024-10-17T11:43:22Z

Associated LedgerHQ/ledger-app-database PR: LedgerHQ/ledger-app-database#279

ajinkyaraj-23 · 2024-10-23T07:17:05Z

src/keys.c

@@ -87,7 +84,7 @@ cx_err_t generate_public_key(cx_ecfp_public_key_t *public_key,
    signature_type_t signature_type = derivation_type_to_signature_type(derivation_type);
    cx_curve_t cx_curve = signature_type_to_cx_curve(signature_type);

-    public_key->W_len = ELLIPTIC_CURVE_PUB_KEY_LENGTH;
+    public_key->W_len = 65;


Avoid using hard number and replace with named macros

ajinkyaraj-23 · 2024-10-23T07:17:22Z

src/keys.c

@@ -105,7 +102,7 @@ cx_err_t generate_public_key(cx_ecfp_public_key_t *public_key,
    if (cx_curve == CX_CURVE_Ed25519) {
        CX_CHECK(
            cx_edwards_compress_point_no_throw(CX_CURVE_Ed25519, public_key->W, public_key->W_len));
-        public_key->W_len = PUB_KEY_COMPPRESSED_LENGTH;
+        public_key->W_len = 33;


No hard numbers , use named macros

ajinkyaraj-23 · 2024-10-23T07:17:36Z

src/keys.c

@@ -151,7 +148,7 @@ static cx_err_t public_key_hash(uint8_t *const hash_out,
        case SIGNATURE_TYPE_SECP256R1: {
            memcpy(compressed.W, public_key->W, public_key->W_len);
            compressed.W[0] = 0x02 + (public_key->W[64] & 0x01);
-            compressed.W_len = PUB_KEY_COMPPRESSED_LENGTH;
+            compressed.W_len = 33;


same here, no hard numbers use named macros

ajinkyaraj-23 · 2024-10-23T07:23:54Z

src/keys.h

+/**
+ * @brief This structure represents a bip32 path and its curve
+ *
+ *        Defines a key when associates with a mnemonic seed


Derivation type is always required. Also where is the key? It only lists derivation type.

This comment come from type.h, it is just a copy.
The comment just tells that you can define a key with a bip32path-&-curve if you associate it to a mnemonic seed (for example, using generate_public_key)

You can fix the grammer like this
Defines the key when associated with a mnemonic seed.

ajinkyaraj-23 · 2024-10-23T13:38:24Z

src/crypto.h

+                                                        size_t path_len,
+                                                        uint8_t raw_pubkey[static 97]);
+
+#ifndef TARGET_NANOS


If we cannot sign BLS on nanos then it does not make sense to allow setting up BLS on nanos either. This will add to confusion.

You're right !
I have added it to allow tz4 holders to use the existing features. But it is indeed confusing if they can not sign.
I have removed BLS support for NanoS !

ajinkyaraj-23 · 2024-10-23T13:43:11Z

test/snapshots/nanos/test_sign_delegation/BLS_tz4Gk6EphzZnu84iEGMV24qwU38vrXSxtw7L/00007.png

if you can not sign BLS with nanos, how did you get these screenshots, what happens when you press accept.
need to remove the entire nanos folder for tests with BLS too

I was still testing BLS with NanoS.
I have fixed it by skipping tests using BLS account for NanoS.

ajinkyaraj-23

Check if eth apps do this or any other app does this? As a last resort we can just ask ledger if saving the private key to RAM is safe or should be avoided .

ajinkyaraj-23 · 2024-10-24T15:26:15Z

src/apdu_sign.c

+                              cdata->ptr,
+                              cdata->size,
+                              G.final_hash,
+                              sizeof(G.final_hash)));


As G.final_hash and sizeof(G.final_hash) is ignored by cx_hash_no_throw when last is false, it would be more readable with an if statement.
if (!last){ cx_hash_update(...., Null, 0); } else{ cx_hash_no_throw(.., CX_LAST, ..., G.final_hash, sizeof..)

ajinkyaraj-23 · 2024-10-24T15:43:51Z

src/apdu_sign.c

+#ifndef TARGET_NANOS
+    // The BLS signature uses its own hash function.
+    // The entire message must be stored in `G.message`.
+    if (global.path_with_curve.derivation_type == DERIVATION_TYPE_BLS12_381) {


if the BLS performs its own hash, can we skip hashing step for BLS in handle_sign above. I think we are hasing twice.

We can not skip hashing step for BLS in handle_sign because we have to send it if the user asks it: INS_SIGN_WITH_HASH.

ajinkyaraj-23 · 2024-10-24T15:50:47Z

src/keys.h

+/**
+ * @brief This structure represents a bip32 path and its curve
+ *
+ *        Defines a key when associates with a mnemonic seed


You can fix the grammer like this
Defines the key when associated with a mnemonic seed.

ajinkyaraj-23 · 2024-10-24T15:52:57Z

src/crypto.c

+    cx_err_t error = CX_OK;
+    cx_curve_t curve = CX_CURVE_BLS12_381_G1;
+
+    uint8_t tmp[BLS_SK_LEN * 2u] = {0};


Overall it seems we are doing multiple steps for signing a single msg using BLS function everytime:

hash the message in handle_sign

derive private key for BLS

derive a public key for BLS

Again generate hash for BLS

sign bls

I think we can optimize by storing BLS pubic and private key when user registers the BLS key as delegate and store it in RAM or when the device starts up.
Then dont hash the msg in handle_sign if the derivation is BLS.
I would also suggest you to check your approach and how it affects benchmarking of existing derivations. I suspect we have increased the time take to sign fo tz2 and tz3 as well.
So when BLS signing requests come we can simply hash and sign.

Actually we can store public and private key for all the derivations in the global ram and compute it when the device starts for the first time. This way we can save some time for all the signatures. I believe we did utilize this approach before.

I think we can optimize by storing BLS pubic and private key when user registers the BLS key as delegate and store it in RAM or when the device starts up.

I'm not sure Legder would agree to store the private key in the RAM (nor keep it alive while the app is open).
Storing the public key should be possible.
We have to ask Ledger for that.

Then dont hash the msg in handle_sign if the derivation is BLS.

We have to if the user asks for it. I will change that !

I suspect we have increased the time take to sign fo tz2 and tz3 as well.

I'm not sure to understand why.

Actually we can store public and private key for all the derivations in the global ram and compute it when the device starts for the first time.

For others derivations, the public key is not required.

Please have a talk with Ledger !

too avoid manual convertion

- use `cx_ecfp_256_public_key_t` instead of `cx_ecfp_public_key_t` because it will become an abstract type - create an union in order to be able to handle all `cx_ecfp_public_key_t` at the same time. `cx_ecfp_384_public_key_t` will be add later for BLS keys

- alias `cx_ecfp_compressed_public_key_t` to differentiate it from `cx_ecfp_public_key_t` - use customize `cx_ecfp_public_key_t` to fit tezos compressed public key and merge them in a struct `tz_ecfp_compressed_public_key_t`

- use directly derivation_type - inline derivation_mode

- gen pk - sign - parsable in operations

As the BLS signature uses its own hash function

- init hash state at first packet - let cx_hash_no_throw handle the hashing

spalmer25 self-assigned this Oct 17, 2024

spalmer25 force-pushed the palmer@functori@add-bls branch 7 times, most recently from c990563 to 09147e0 Compare October 22, 2024 11:01

spalmer25 requested a review from ajinkyaraj-23 October 22, 2024 11:02

spalmer25 marked this pull request as ready for review October 22, 2024 11:02

ajinkyaraj-23 reviewed Oct 23, 2024

View reviewed changes

spalmer25 force-pushed the palmer@functori@add-bls branch 4 times, most recently from c5c8a1c to 4591406 Compare October 24, 2024 12:47

ajinkyaraj-23 reviewed Oct 24, 2024

View reviewed changes

spalmer25 added 13 commits October 25, 2024 11:10

[key] move keys related functions and types in keys

f5cf23b

[key] use the real value for derivation type and signature type

0c3dcb8

too avoid manual convertion

[key] introduce struct for compressed public key

7269bc0

- alias `cx_ecfp_compressed_public_key_t` to differentiate it from `cx_ecfp_public_key_t` - use customize `cx_ecfp_public_key_t` to fit tezos compressed public key and merge them in a struct `tz_ecfp_compressed_public_key_t`

[key] do not use signature_type in keys handling

233fa49

- use directly derivation_type - inline derivation_mode

[crypto] add cryptography for bls

8fc17a1

[bls] add the bls curve to the curves handled

53ffa9e

- gen pk - sign - parsable in operations

[bls] do not sign the hash of the message for BLS

ec7ed0f

As the BLS signature uses its own hash function

[hash] refacto hash

8f1a5f2

- init hash state at first packet - let cx_hash_no_throw handle the hashing

[tests] use pytezos to build messages

4de70d3

[tests] decode public key get from the ledger

d1ce49c

[tests] use the base58 format for signature

6ce31a0

[tests] add tests for bls/tz4

c4ef534

spalmer25 force-pushed the palmer@functori@add-bls branch from 4591406 to c4ef534 Compare October 25, 2024 11:16

spalmer25 requested a review from ajinkyaraj-23 October 25, 2024 12:04

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allows to sign using the BLS curve #121

Allows to sign using the BLS curve #121

spalmer25 commented Oct 17, 2024 •

edited

Loading

ajinkyaraj-23 Oct 23, 2024

ajinkyaraj-23 Oct 23, 2024

ajinkyaraj-23 Oct 23, 2024

ajinkyaraj-23 Oct 23, 2024

spalmer25 Oct 24, 2024

ajinkyaraj-23 Oct 24, 2024

ajinkyaraj-23 Oct 23, 2024

spalmer25 Oct 24, 2024

ajinkyaraj-23 Oct 23, 2024

spalmer25 Oct 24, 2024

ajinkyaraj-23 left a comment

ajinkyaraj-23 Oct 24, 2024

ajinkyaraj-23 Oct 24, 2024

spalmer25 Oct 25, 2024

ajinkyaraj-23 Oct 24, 2024

ajinkyaraj-23 Oct 24, 2024

ajinkyaraj-23 Oct 24, 2024

spalmer25 Oct 25, 2024 •

edited

Loading

Allows to sign using the BLS curve #121

Are you sure you want to change the base?

Allows to sign using the BLS curve #121

Conversation

spalmer25 commented Oct 17, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ajinkyaraj-23 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

spalmer25 Oct 25, 2024 • edited Loading

Choose a reason for hiding this comment

spalmer25 commented Oct 17, 2024 •

edited

Loading

spalmer25 Oct 25, 2024 •

edited

Loading