Different key types

Iroha uses Hyperledger Ursa which makes it possible to utilise several Digital Signature Algorithms (DSA) at the same time. This document explains the issues that do not allow achieving that now and proposes changes to have multiple DSA algorithms which can be easily selected by users.

Keys in configuration file

Currently in configs we store both private and public keys in a form of byte arrays (example):

```shell=
"IROHA_PUBLIC_KEY": "[101, 170, 80, 164, 103, 38, 73, 61, 223, 133, 83, 139, 247, 77, 176, 84, 117, 15, 22, 28, 155, 125, 80, 226, 40, 26, 61, 248, 40, 159, 58, 53]",
"IROHA_PRIVATE_KEY": "[113, 107, 241, 108, 182, 178, 31, 12, 5, 183, 243, 184, 83, 0, 238, 122, 77, 86, 20, 245, 144, 31, 128, 92, 166, 251, 245, 106, 167, 188, 20, 8, 101, 170, 80, 164, 103, 38, 73, 61, 223, 133, 83, 139, 247, 77, 176, 84, 117, 15, 22, 28, 155, 125, 80, 226, 40, 26, 61, 248, 40, 159, 58, 53]"
```

There are several problems here:

1. Array format is bloaty
2. There is no information about which kind of DSA algorithm was used to generate such keypair (ed25519, bls,..). As we use Ursa which has multiple implementations of DSA algs, it makes sense to put somewhere such information
3. Information about public key is redundant as it could be obtained from the private key

Keys in Iroha core

Now keys format in Iroha is basically byte array of the fixed size. We don't store any information about which kind of DSA algorithm was used to generate keypair, so it is not possible to select main DSA algorithm used by the nodes as well as to support clients with different kind of keys in terms of the DSA algorithm used to produce them.

Proposal 1. Switch from array representation of the keys/signatures to the hex format

Array format is bloaty. Any bytearray could be described using hex, base58 or other serialization techniques.

From my perspective and Iroha1 experience hex format is the most convenient. It is compact enough, readable and can be easily serialized/deserialized on any language or from the console.

Proposal 2. Utilize multihashes to manage keys and signatures inside Iroha

)

Multihash is a format for storing hashes/keys/signatures in a way that also self-describes the type of that hash/key/signature. We can distringuish multiple key types inside Iroha using this format.

Format is quite simple. It is basically the hash/key/signature itself prepended with the corresponding id of the hash/key/signature + size of the bytearray.

Such approach is already used in Iroha 1. (TODO: check with Iroha1 team how exactly Ursa is used).

Same can should be used for signatures. So, when we receive message with signature, we can understand which DSA alg was used to produce a signature.

Of course in the beginning we will have only ed25519 signatures by default. However, in future it will be simple to switch between different DSA algorithms (for example when we need to support HSM with non-ed25519 crypto) if we start implementing multihash approach now.

Proposal 3. Do not store public keys in the configs

Actually all we need to obtain the public key is the private key. Also private key stored using multihash approach can be used to understand which DSA was used to produce the key.

```shell=
"IROHA_PRIVATE_KEY": "0xe5be9a5092b81bca64be81d212e7f2f9eba183bb7a90954f7b76361f6edb5c0a"
```

With such approach keys can be stored in a very compact way while keeping information about DSA algorithm that should be used to produce public key.

Polkadot approach

Polkadot uses subkey tool (simillar to Iroha's ursa utils) to generate the keys. For example `inspect` command generates a keypair from the provided random input:

```shell=
subkey inspect //Alice
# Secret Key URI `//Alice` is account:
# Secret seed: 0xe5be9a5092b81bca64be81d212e7f2f9eba183bb7a90954f7b76361f6edb5c0a
# Public key (hex): 0xd43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d
# Account ID: 0xd43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d
# SS58 Address: 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
```