You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feature to support curve "P-256k1" (secp256k1) #222
Hey @iamliqiang, thanks for opening the issue. We currently don't support SCEP (it's on the roadmap) so that's probably why we haven't gotten around to this curve.
I have a question though: I don't see this as one of the supported curves in the golang crypto library (https://golang.org/pkg/crypto/elliptic/#Curve). I assume this means we would have to roll our own support, use a fork of the crypto lib, or pull in a dependency that implements this curve?
Given that this curve isn't supported by default I get the sense this would be a far reaching change.
secp256k1 is more safe than P256 by NIST， that is why it is used wildly by bitcoin、ethereum and mainstream blockchain； and not P256， NSA and NIST support P256， and maybe has backdoor
I mentioned before that SCEP support is on the horizon, so we'll probably wait to implement this simultaneously. Unless we see more support from the community asking for this curve in the short term. In which case we'll re-prioritize.
If anyone has some spare cycles to add this curve, we'd happily accept a PR :)
Ah, shoot. I think I got a bit confused. In the description of the issue we used the term "scep256" and I assumed wrongly assumed this was associated with SCEP. The curve appears to be "secp256" and is not directly associated with SCEP.
So please ignore what I said about the SCEP timeline. We'll put this issue in the backlog for now and prioritize based on incoming support from the community.
For the other curves we're using the IANA registered names that are documented as part of the JSON Web Algorithms (JWA) spec, and used by the other JOSE specs (JWK, JWT, JWS, etc). If we're going to add this curve we need to figure out what to call it. I took a look at the IANA registry and I don't see a standard name for this curve. Perhaps there's a draft spec out there somewhere with a name for it that we could use? It's also possible that the JWA spec is drawing from another standard or semi-formal namespace, and there may be a name for this curve there?
Relatedly, does anyone know where the secp... & sect... names come from?
Activity
[-]feture to support curve "P-256k1"[/-][+]feture to support curve "P-256k1" (secp256k1)[/+]dopey commentedon Feb 20, 2020
Hey @iamliqiang, thanks for opening the issue. We currently don't support SCEP (it's on the roadmap) so that's probably why we haven't gotten around to this curve.
I have a question though: I don't see this as one of the supported curves in the golang crypto library (https://golang.org/pkg/crypto/elliptic/#Curve). I assume this means we would have to roll our own support, use a fork of the crypto lib, or pull in a dependency that implements this curve?
Given that this curve isn't supported by default I get the sense this would be a far reaching change.
maxmetagravity commentedon Feb 21, 2020
there is a good implement reference：
https://github.com/ethereum/go-ethereum/tree/master/crypto/secp256k1
secp256k1 is more safe than P256 by NIST， that is why it is used wildly by bitcoin、ethereum and mainstream blockchain； and not P256， NSA and NIST support P256， and maybe has backdoor
dopey commentedon Feb 21, 2020
Awesome! Thanks for linking the reference!
I mentioned before that SCEP support is on the horizon, so we'll probably wait to implement this simultaneously. Unless we see more support from the community asking for this curve in the short term. In which case we'll re-prioritize.
If anyone has some spare cycles to add this curve, we'd happily accept a PR :)
dopey commentedon Feb 21, 2020
Ah, shoot. I think I got a bit confused. In the description of the issue we used the term "scep256" and I assumed wrongly assumed this was associated with SCEP. The curve appears to be "secp256" and is not directly associated with SCEP.
So please ignore what I said about the SCEP timeline. We'll put this issue in the backlog for now and prioritize based on incoming support from the community.
Still very open to PRs though :)
maxmetagravity commentedon Feb 22, 2020
@dopey thanks，yes it is secp256k1 curve，and used wildly in blockchain
mmalone commentedon Feb 25, 2020
For the other curves we're using the IANA registered names that are documented as part of the JSON Web Algorithms (JWA) spec, and used by the other JOSE specs (JWK, JWT, JWS, etc). If we're going to add this curve we need to figure out what to call it. I took a look at the IANA registry and I don't see a standard name for this curve. Perhaps there's a draft spec out there somewhere with a name for it that we could use? It's also possible that the JWA spec is drawing from another standard or semi-formal namespace, and there may be a name for this curve there?
Relatedly, does anyone know where the
secp...§...names come from?dcow commentedon Feb 25, 2020
@mmalone https://www.secg.org/sec2-v2.pdf
maxmetagravity commentedon Mar 7, 2020
@dopey yes 👍
algorithm: ES256K
curve name: secp256k1
https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-03
this algorithm is gaining traction in the Crypto world and is being standardized. It would be great if smallstep support it
about go implements ,there is a similar talking : square/go-jose#263, and square/go-jose#278, maybe help.
there is a refer draft : JSON Web Token (JWT) with ES256K (secp256k1) signature
https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-03#section-3.1
[-]feture to support curve "P-256k1" (secp256k1)[/-][+]feature to support curve "P-256k1" (secp256k1)[/+]