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
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 https://github.com/aeternity/aepp-sdk-js/pull/1843
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 ofnetwork 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 adjustingpayload
,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
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 https://github.com/aeternity/aepp-sdk-js/pull/1843