Ensure that the delegation signature can't be used as a transaction signature

[davidyuk]

While doing typed data signing in SDK we added a magic number to distinguish its payload from anything else, but I found no such magic number in delegation signature signing.

Most delegation signatures look safe because they include the account address in the payload, except for delegation signature to respond to oracle query. As I understand it is generated as sign(network id + contract address + oracle query id). Without proper validation on the signer side, a malicious actor can get a signature of network id + arbitrary 64 bytes.

Transaction signature can be generated as sign(network id + encoded transaction). The length of the encoded transaction can be increased by adjusting payload, gasLimit fields without behavior changing. So, using a method to sign delegation signature is theoretically possible to generate a transaction signature by crafting a transaction of 64 bytes and splitting it into two pieces ("contract address", "oracle query id").

I didn't spend enough time to find a meaningful example, the closest one is

tx_+D4qAaEBhAyXS5cWR3ZFS6EZ2E7cTWBYqN7JK27cV4qy0wtMQgCCAtOAgwcAA4ZFYFJNsAAAAACBgIQ7msoAgHSE2aw=

it is a 64-byte long ContractCreateTx with empty bytecodes, so it can't be mined.

To protect from attracts like this I suggest adding a mark to ensure that these sign payloads won't overlap. It may be a 0x1a01 prefix in the fashion of aeternity/aepp-sdk-js#1843

[hanssv]

Good observation!

Though used in Sophia the delegation signatures are just signatures for the sake of the compiler - could you please point this to aeternity repo?