Add support for uncompressed public key type

[conr2d]

Background

Blockchains including EOSIO usually support ECDSA secp256k1 to verify their transactions. However, in some blockchains, the result of recovering key from signature is different from EOSIO, because they use uncompressed key (65 bytes) instead of compressed one (33 bytes) which EOSIO uses.

As far as I know, the main strategy to improve EOSIO scalability is IBC among EOSIO-based sidechains or fork chains. If uncompressed public key type is supported in EOSIO smart contract, we can achieve better interoperability among heterogeneous blockchain networks.

Proposal

Add intrinsic API for uncompressed public key type

Available options

0. Common

New types capi_public_key_point and eosio::public_key_point are added

struct capi_public_key_point {
   char data[66];
};

namespace eosio {
   struct public_key_point {
      unsigned_int type;
      std::array<char,65> data;
   };
}

1. Add decompression API converts compressed public key (eosio::public_key) to uncompressed one (eosio::public_key_point)

::decompress_key (const char* data, uint32_t length, char* pubkey_point)

2. Add conversion API between compressed public key and uncompressed one, the size of outlen determines which type of public key (compressed/uncompressed) needs to be serialized

::serialize_key (const char*data, uint32_t datalen, char* out, uint32_t outlen)

3. Add feature to recover_key for recovering uncompressed public key from signature, the size of publen determines which type of public key needs to be recovered

::recover_key (const capi_checksum256* digest, const char* sig, size_t siglen, char* pub, size_t publen)

Other considerations

Currently, wrapper classes of secp256k1 and secp256r1 provide recover() method which returns only compressed public key. If 3rd option is adopted, there can be two way to make it, one is recovering compressed and decompress it, or the other is adding ability to recover uncompressed public key to wrapper classes.

---

The next commits are very early stage impelmentation of this proposal.

conr2d@0458416
conr2d/fc@34cd44a

[conr2d]

IMHO, I like the 3rd option most, because it doesn't add an API explicitly and it wouldn't break existing behavior in most cases. (publen in ::recover_key() passed is usually 38)
https://github.com/EOSIO/eosio.cdt/blob/master/libraries/eosiolib/crypto.cpp#L66