Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ed25519-sha2 signature code #139

Closed
lebdron opened this issue Jun 28, 2019 · 6 comments · May be fixed by #142
Closed

Add ed25519-sha2 signature code #139

lebdron opened this issue Jun 28, 2019 · 6 comments · May be fixed by #142

Comments

@lebdron
Copy link

lebdron commented Jun 28, 2019

Since it is possible to encode ed25519 (sha2?) public key already with 0xed, it would be great to encode ed25519-sha2 signature in the same way.

The following related issues are not actively updated, but the introduction of "multisig"/multisign may greatly help us in https://github.com/hyperledger/iroha to migrate from one cryptography algorithm to another without losing backward compatibility.
multiformats/multiformats#23
#125

Ping @yusefnapora

@yusefnapora
Copy link

yusefnapora commented Jul 5, 2019

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.

@Stebalien
Copy link
Member

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)

@lebdron
Copy link
Author

lebdron commented Nov 13, 2019

@yusefnapora @Stebalien Any updates?

@Stebalien
Copy link
Member

@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.

@lebdron
Copy link
Author

lebdron commented Nov 16, 2019

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?

@lebdron
Copy link
Author

lebdron commented Jun 17, 2020

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.

@lebdron lebdron closed this as completed Jun 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants