Hey @lebdron, thanks for bringing this up again during our sync call earlier. I was reviewing the codec table a second ago and thinking about this.

Would it be possible to just combine the existing code for ed25519 keys (0xed) and the code for sha2-256 (0x12)?

So your implementation of "multi-signature" or whatever it gets called would be to pull two varint-encoded multicodecs, one for the key type, and one for the hash algorithm. In this case, it would be 0xed 0x12, but if you wanted e.g. sha3-512 you'd use 0xed 0x14 instead.

Just a thought - if you do need a new code, I think submitting a PR to this repo as @raulk suggested would be fine.

I'd be careful about allowing the hash function to be customized like this. An attacker could:

1. Retroactively change the "hash algorithm" to a less secure one.
2. Cook up a new message with the same hash digest in this new hash algorithm.

Ideally, the hash algorithm would be a property of the key (so changing the algorithm changes the identity of the author).

(yes, you can just ban insecure algorithms, just be careful)

@yusefnapora @Stebalien Any updates?

@yusefnapora has actually been working on a signed envelope spec which should be useful here: https://github.com/libp2p/specs/pull/217/files#diff-1d3e44bb1e34e0581019f35b96151a0d.

Unfortunately, it does use libp2p keys which don't use multicodecs to identify key types.

Thanks for the reply! I looked at the RFC, and the problem is that KeyType is not available in Iroha. What if instead we add just public key types (without signature types), so that we only extend existing ed25519-pub code?

Does not seem to be an issue anymore, as signatures are not transferred without corresponding public keys, and there is already a codec present for the ed25519-sha2 public key.