33-byte pub Key for edcsa opcodes

AlgoSDK
1

Some new TEAL5 opcodes such as ecdsa_pk_decompress require a 33-byte compressed Pubkey as input. How I can get it from the JS AlgoSDK and encode it through an appcall?

Thanks.

2

These opcodes are meant for interoperability with other blockchains.
Usually, such inputs are expected to come from other ECDSA-based system.

If you only plan to work on the Algorand blockchain, it is highly recommended to only use ED25519 that a better signature scheme than ECDSA on many fronts.

5

Fabrice thanks. So I guess ed25519verify is the only alternative for an approval program that checks for message signatures.

6

Yes, ed25519verify is the way to go.

1 Like
7

According to documentation, I must generate a signature for “ProgramData” + programHash + data.

I assume that this can be made properly with the SDK function:

const sig = tealSign(sk, data, hash)

My data is pre-hashed with SHA512_256, so in the contract I expected to match it:

// Data (Hash of original message)
load 2
sha512_256

// (B) signature 
load 3

// (C) validator-address
byte "vaddr"
app_global_get

// Verify signature
ed25519verify
int 1
==
assert

But keeps rejecting me. It’s correct to pass data as first arg or it is required to be programhash+data?

Thanks.

Addendum: According to node source, go-algorand/eval.go at f17f73ef0830d8b8f600caf6b1f91e1c6c521045 · algorand/go-algorand · GitHub it is not required as programHash is evaluated in-context:

	msg := Msg{ProgramHash: cx.programHash(), Data: cx.stack[pprev].Bytes}
	if sv.Verify(msg, sig) {
		cx.stack[pprev].Uint = 1
	} else {
		cx.stack[pprev].Uint = 0
	}
8

I’m not completely sure that the issue is.

  1. Have you looked at Verify Signatures and Signed Data within Algorand Smart Contracts | Algorand Developer Portal ?
  2. Is data in tealSignm(sk, data, hash) the SHA512-256 hash of the message is scratch var 2?
  3. Is hash the actual hash of the TEAL program, that is the smart signature/contract address?

You don’t need to include programhash inside data as input of tealSign, as the JS SDK does it for you: js-algorand-sdk/logicsig.ts at 85db3a83f37273930087f2fde2a5cfca97fb40fb · algorand/js-algorand-sdk · GitHub

9

Thanks Fabrice for the reply. I read the development documentation, and ensured that SHA512-256 is the hash of the same message by checking outputs both in client code and SC through dryrun dump. I will verify the hash but Im sure is from the output of compiled program (.hash member of the compilation result) . I will see how it goes.

10

I found the culprit: the program hash was bogus.

Now I have a probably bigger problem. Since I want to verify messages in an stateful contract where a server sends a packed message in a single transaction, I will hit the 700 maximum cost making the ed25519verify opcode nonfunctional (it’s cost is 1900).

I guess that a probable solution would be to divide the verification and state-saving work in stateless and stateful code respectively. But I guess this kills the TEAL5 feature of using sig verification directly in ApprovalPrograms.

Thanks in advance,
hernan

11

You can group this with other calls to the smart contract that don’t use much opcode budget to make it works as well. See pooled opcode budget here: Discover AVM 1.0 | Algorand Developer Portal

1 Like
12

Hi @JasonW, thank you very much!; this can be done in-contract e.g by generating inner transactions or shall be grouped in the traditional way?

13

group multiple app transaction calls together. Inner txes can not yet do app calls. So the normal way.

1 Like