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 X25519 (Curve25519) pub key support #144

Merged
merged 2 commits into from
Mar 9, 2020

Conversation

dmitrizagidulin
Copy link
Contributor

Add support for X25519 public keys (for use with Key Agreement Keys etc).

@Stebalien
Copy link
Member

(notification backlog, sorry)

Out of curiosity, how are (were?) you planning on using this?

Also note: this code is in the very limited one-byte range. Does it really need to just be one byte or could you deal with a two-byte code (we have quite a few more of those).

@dlongley
Copy link
Contributor

Out of curiosity, how are (were?) you planning on using this?

It's being used to express X25519 public keys, typically in DID (Decentralized Identifier) Documents, that can be used to derive secret keys for secure communications with an entity, typically identified by a DID. (see: https://github.com/digitalbazaar/x25519-key-pair and https://github.com/digitalbazaar/did-method-key-js).

Also note: this code is in the very limited one-byte range. Does it really need to just be one byte or could you deal with a two-byte code (we have quite a few more of those).

Hmm, I now see:

The first 127 bits are encoded as a single-byte varint, hence they are reserved for the most widely used multicodecs. So if you are adding your own codec to the table, you most likely would want to ask for a codec bigger than 0x80.

Originally we only saw the three step process for adding something to the table and glossed over this advice. We've been using ed25519 keys (directly related to x25519 keys) that use the memorable 0xed code and reasoned that 0x25 looked like a good and memorable code for x25519 keys. Since ed25519 is in the class of codes that is bigger than 0x80, I suppose we can explore picking something else if this is a sticking point.

@dmitrizagidulin -- can you take a look at this and our existing code to see how difficult it would be to change this (and perhaps recommend another code)?

@dmitrizagidulin
Copy link
Contributor Author

@dlongley No problem. It's not a bad change, it's just a couple places in one file in https://github.com/digitalbazaar/x25519-key-pair repo. (Plus the ripple of package version updates.)

As for suggesting a new code - I'm not fully clear on how the two-byte/varint encoding mechanism works, but let me take a look.

@oed
Copy link
Contributor

oed commented Mar 7, 2020

This would be great to have. @dmitrizagidulin maybe change the code to 0xe8 (right after secp256k1-pub?

@dlongley
Copy link
Contributor

dlongley commented Mar 9, 2020

@dmitrizagidulin, let's change this to 0xec (right next to 0xed which is for Edwards25519 and this is for Curve25519) to address the above issue and get the libraries patched.

@dmitrizagidulin
Copy link
Contributor Author

@dlongley Perfect, will do.

@dmitrizagidulin
Copy link
Contributor Author

@Stebalien I've changed the X25519/Curve25519 entry to 0xec.

table.csv Outdated Show resolved Hide resolved
Co-Authored-By: Dave Longley <dlongley@digitalbazaar.com>
@Stebalien Stebalien merged commit bb0f8b2 into multiformats:master Mar 9, 2020
@Stebalien
Copy link
Member

🎉

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 this pull request may close these issues.

None yet

4 participants