rawSignTxn To support only requiring the scalar (not the seed) to sign.

[ehanoc]

Problem

Being able to sign transactions with derived keys from schemes like BIP32-ed25519, in which only kL (scalar) is known.

The following SDK code in file: transaction.ts:

  // returns the raw signature
  rawSignTxn(sk: Uint8Array) {
    const toBeSigned = this.bytesToSign();
    const sig = nacl.sign(toBeSigned, sk);
    return Buffer.from(sig);
  }

  signTxn(sk: Uint8Array) {
    // construct signed message
    const sTxn: EncodedSignedTransaction = {
      sig: this.rawSignTxn(sk),
      txn: this.get_obj_for_encoding(),
    };
    // add AuthAddr if signing with a different key than From indicates
    const keypair = nacl.keyPairFromSecretKey(sk);
    const pubKeyFromSk = keypair.publicKey;
    if (
      address.encodeAddress(pubKeyFromSk) !==
      address.encodeAddress(this.from.publicKey)
    ) {
      sTxn.sgnr = Buffer.from(pubKeyFromSk);
    }
    return new Uint8Array(encoding.encode(sTxn));
  }
  

Calls "Secret Key" to the Ed25519 seed. Explaining picture below:

In order to support HDWallets, we need to able to sign with the scalar. We use tweetnacl API's that use SEED + PublicKey instead of a + RH, which the latter would be preferable when only the scalar and RH is available.

Solution

Support signing with the scalar instead of the seed (which is known as secret key within the SDK's code)

Urgency

High - as it blocks the ecosystem from adopting BIP32-ed25519 derived keys and to continue to use the SDK to sign transactions with those derives keys.

[HashMapsData2Value]

https://github.com/algorandfoundation/ARCs/blob/8b4de1d49e9b857533a53992965e79d45adc439e/assets/arc-0052/contextual.api.crypto.ts#L157

Lines 157-175 contain example code of a signature generationn function that uses a 32 byte scalar directly and produces a 64 byte signature that successfully verified against LibSodium and TweetNacl and has been used to sign Algorand transactions. It relies on LibSodium primitives.

[johnalanwoods]

Hi folks - this one is important for HD wallets.

[jasonpaulos]

I can imagine two different scenarios for how algosdk and the ARC-52 BIP32 work can be used together.

One scenario is that they are closely related, and this SDK provides convenience functions for BIP32 support. Now, this SDK is not a crypto library, it only calls into crypto libraries for basic hashing and signature operations. Something as complex as BIP32 key derivation and signing would be better placed in its own standalone library where it can be well tested and ideally audited. This SDK could then import/reference the library and offer support/convenience functions as needed. Even outside of this specific use case, I believe a standalone library for ARC-52 would be very useful and the fastest way to make the standard available to users.

The other scenario is that they're completely independent. You use the SDK to build transactions, and you have the option of using the separate BIP32 library/code to generate accounts and sign transactions. We already have been heading in this direction to support offline/remote signers, and as such we offer a way of attaching a signature obtained elsewhere to a transaction using the Transaction.attachSignature method. There is also the Transaction.bytesToSign method which can be used to obtain the exact byte string over which the signature should be computed.

Since the second scenario is already possible today without any code changes to the SDK, I'd encourage adopters of ARC-52 to follow this route. Down the road if we feel there is too much friction in having to install two libraries and use them together in this way, I'd be open to reevaluating introducing more support for ARC-52 into the SDK.