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 P-384 #186

Closed
wants to merge 1 commit into from
Closed

Add P-384 #186

wants to merge 1 commit into from

Conversation

OR13
Copy link
Contributor

@OR13 OR13 commented Aug 2, 2020

AFAIK, this will be the first NIST Curve added here... so its pretty valuable for legacy systems.

AFAIK, this will be the first NIST Curve added here... so its pretty valuable for legacy systems.
@rvagg
Copy link
Member

rvagg commented Aug 3, 2020

This is fine by me, but we're now out of space in 0xeX, I'm wondering if we should just start populating a new space for curve public keys, since there's potentially a lot of them, leaving the current ones in place. There's 4 more prime curves in the NIST set that would go along with just this one and there's no space to nicely order them if we lock this one in.

Thoughts from anyone else?

@OR13 just out of interest, do you have a current use-case for a P-384 public key?

@OR13
Copy link
Contributor Author

OR13 commented Aug 3, 2020

@rvagg

yes, the main problem is that web crypto / hardware backed kms often don't support secp256k1, ed25519 or bls12381... so what do you do if you are required to work with say ... a customer who requires you use NIST curves for somethings ?

I would like to be able to generate a non extractable software isolated key in a browser, and represent it using did:key...

https://github.com/w3c-ccg/did-method-key

I have used did:key with ed25519, secp256k1, and bls12381... but I have no way of doing it for a NIST curve without registering at least 1.

I chose P-384 because of its use by both the US and NZ governments.

PDF Download of GCSB Approved Cryptographic Algorithms

@OR13
Copy link
Contributor Author

OR13 commented Aug 3, 2020

@rvagg yes, its probably better to register all the NIST Curves nicely in their own block... I was wondering how we were going to go higher than ef :) I'm not attached to the prefix length at all.

@OR13
Copy link
Contributor Author

OR13 commented Aug 4, 2020

if someone can recommend the block to register for NIST curves, I will close this PR and open open one which registers them.

@rvagg
Copy link
Member

rvagg commented Aug 5, 2020

Anything above the single byte range is wide open, I see two slots that might be nice (this is mostly a subjective call given the space available!). After x11, we could probably start a block in 0x12XX for common curve pubkeys. There's also space we could work on in 0xb5XX, the preceding poseidon entries are somewhat related (in that they involve a curve).

@OR13
Copy link
Contributor Author

OR13 commented Aug 5, 2020

@rvagg

0x12XX seems like the right place for these: https://www.iana.org/assignments/jose/jose.xhtml#web-key-elliptic-curve

0x1200 - P-256
0x1201 - P-384
0x1202 - P-521
0x1203 - Ed448
0x1204 - X448

^ would this be correct?...

@OR13
Copy link
Contributor Author

OR13 commented Aug 14, 2020

Closing this PR in favor of #190

@OR13 OR13 closed this Aug 14, 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 this pull request may close these issues.

2 participants