Comments (53)
As of v0.13.1 (#820), p224
has an arithmetic
feature as well as support for ECDH and ECDSA
from elliptic-curves.
#607 added the initial boilerplate for a p521
crate.
However, implementing it properly will require some breaking changes to the elliptic-curve
crate as various properties which can presently be computed/inferred, such as the size of a serialized field element, will require explicit configuration with p521
.
from elliptic-curves.
#631 extracts a proper generic implementation of AffinePoint
and ProjectivePoint
, which eliminates a lot of code duplication and will make it much easier to implement p521
as well as adding arithmetic backends to bp256
and bp384
.
from elliptic-curves.
p224
and p521
now have base and scalar field implementations, as well as curve parameter definitions, although none of it is properly tested and all gated under the wip-arithmetic-do-not-use
crate feature.
from elliptic-curves.
I've been hoping the new codegen in
fiat-crypto
which uses newtypes in place of type aliases might help track down the issue, but haven't had time to try to update the generated code (and note in general that's a relatively difficult thing to do).
I can help in creating a PR to update the existing code into the new type codegen by fiat-crypto. Would that be helpful?
- Looks like new types instead of type aliases was added in fiat-crypto v0.0.21. I can import v0.0.24's version. Added in #944
- fiat-constify doesn't support new syntax. This seems straightforward to fix. Fixed in RustCrypto/utils#978
from elliptic-curves.
Yep, p521
looks close now. I'm filling in some additional tests.
from elliptic-curves.
@kamulos it might be possible to support sometime after #218 lands
from elliptic-curves.
Now that p384
is mostly good to go and based on what are hopefully reusable wrappers around fiat-crypto (#586), it might be possible to wrap their implementation of P-521's fields, although first I'll probably take a look at migrating the field implementations in p256
to also use fiat-crypto.
from elliptic-curves.
Yeah, primeorder
should work fine for it, but there are other curves I'd like to work on first which are niche but more commonly used, like the Brainpool curves
from elliptic-curves.
@tarcieri I think secp192r1
can be marked as done in this issue, you agree?
from elliptic-curves.
Yes, secp192r1
is "complete" in that high-level private key operations are deliberately not implemented due to the small modulus size, following NIST recommendations. Public-key operations are still available.
AFAIK this requires a breaking change in the primeorder crate.
It's deeper than that, it would be a change to the elliptic-curve
crate: RustCrypto/traits#1304
from elliptic-curves.
Any strong feelings on Curve448-Goldilocks?
Seeing it standardized and favored for inclusion in TLS might be worth the effort to investigate on our end. (I see an emphasis on legacy curves, so maybe not this one for now)
from elliptic-curves.
@drcapybara there's already a few implementations of it out there, e.g. https://crates.io/crates/ed448-goldilocks
We could potentially ask about upstreaming them
This is a solid example. It appears there may be some good opportunity to upgrade some of the scalar arithmetic with functionality offered by crypto-bigint here.
from elliptic-curves.
Yes, along with all of the other NIST P-curves: https://github.com/RustCrypto/elliptic-curves/tree/master/p384
from elliptic-curves.
We could potentially inquire on the upstream repo: https://github.com/crate-crypto/Ed448-Goldilocks
sounds like the authors might be interested: crate-crypto/Ed448-Goldilocks#35
from elliptic-curves.
I added an initial set of Brainpool curves (bp256
and bp384
) in #281 and #280 respectively.
Unfortunately I'm not a Brainpool user, so I was unclear around usage of brainpoolP256r1/brainpoolP384r1 vs brainpoolP256t1/brainpoolP384t1. The crates I added assume the former.
Happy to hear from Brainpool users about how the curves are used in practice. If it turns out *r1
is a mistake we can potentially transition over to *t1
or support both *r1
and *t1
.
from elliptic-curves.
Circling back on Brainpool, I see a couple ways forward. We should decide which one makes sense.
First, for background:
r1
curves are "verifiably pseudorandom" (or rather, were supposed to be but were erroneously generated)t1
curves are the "twist" curves and provide the same effective security properties but permit a slightly more efficient implementation due to the use of smaller parameters
So, it seems like we should probably support both r1
and t1
, for both the 256-bit and 384-bit modulus sizes. Here are a couple of ways that could be done:
Include both r1
and t1
curves in the same crate
This would result in the following crates:
bp256
: brainpoolP256r1 and brainpoolP256t1bp384
: brainpoolP384r1 and brainpoolP384t1
Separate crates for r1
and t1
curves
This would look like:
bp256r1
: brainpoolP256r1bp256t1
: brainpoolP256t1bp384r1
: brainpoolP384r1bp384r1
: brainpoolP384t1
My vote would be for bp256
and bp384
crates for now, each containing both the r1
and t1
variants respectively.
They could be placed under r1
and t1
modules, e.g. bp256::r1
and bp256::t1
As it were, I went ahead and registered bp256r1
, bp256t1
, bp384r1
, and bp384t1
just in case.
Edit: split r1
and t1
variants of bp256
and bp384
in #286
from elliptic-curves.
I know it is not one of the most widespread curves, but is there any chance, that secp224r1 is supported at some point?
from elliptic-curves.
@tarcieri, I know that you mentioned in your original post that:
Note that we are presently focusing on "legacy" short Weierstrass curves. There are many other Rust projects implementing newer curve forms, such as
curve25519-dalek
andbls12_381
.
But is there any chance (or are planning already) to implement the curve25519
natively in RustCrypto's elliptic-curves
crate?
I know that someone can use curve25519-dalek
, but I am mainly looking for a solution that plays along well with the RustCrypto elliptic_curve::PublicKey
(and other related) APIs and especially the "parsing SPKI" feature. This would be super awesome, as I don't think with curve25519-dalek
you can do something similar (i.e. parse from PEM/DER), nor that it interops with the elliptic-curves
crate, unless I am missing something?
from elliptic-curves.
I assume you're specifically interested in Ed25519 and RFC 8410 support?
There's an open PR to add PKCS#8 and SPKI support to ed25519-zebra
:
https://github.com/ZcashFoundation/ed25519-zebra/pulls
I'll also note that similar functionality is available through the signatory
crate:
https://docs.rs/signatory/0.23.2/signatory/ed25519/struct.SigningKey.html#method.from_pkcs8_der
We do also maintain the ed25519
crate which is used by ed25519-dalek
. I could potentially add support for decoding/encoding PKCS#8 and SPKI public keys and private keys to bytes:
https://github.com/RustCrypto/signatures/tree/master/ed25519
from elliptic-curves.
I added PKCS#8 support to the ed25519
crate in RustCrypto/signatures#381
It now provides a KeypairBytes
type which can be decoded from/encoded into PKCS#8.
Note it's still unreleased though
from elliptic-curves.
Deno, a popular JavaScript runtime, uses RustCrypto's implementation of the P-256 and P-384 curves. A lack of support for the P-521 curve is the only thing holding it back from full compliance the WebCrypto standard, implemented by all major browsers. I humbly request the P-521 curve. Thank you very much!
from elliptic-curves.
Has the secp224r1
come any closer with the work? The #218 you mentioned last time seems to be abandoned.
from elliptic-curves.
Do you have a real use case for it?
Note that there's quite a bit of duplication between p256
and p384
, and more work is needed to extract things like the addition formulas and make them generic around the underlying field elements, so we're still not in great shape to start supporting more P-curves.
If it's just p256
, p384
, and p521
, things are a bit more manageable until more of the implementation can be provided generically.
from elliptic-curves.
Sounds reasonable 👍
I need the curve for my company's product. Having this without importing one of the few C crypto libraries supporting it would be nice to have, but obviously I am aware that this is a quite exotic curve.
from elliptic-curves.
@newpavlov we got a request on Zulip for a p224
crate. Can you grant ownership to the elliptic-curves
team?
from elliptic-curves.
@tarcieri Done.
from elliptic-curves.
@newpavlov thank you!
from elliptic-curves.
Could you please add secp192r1
to this list?
from elliptic-curves.
@halvors added, although given its small modulus size it will probably be a fairly low priority (i.e. we should finish up P-224, P-521, and the Brainpool curves first, at least)
from elliptic-curves.
@newpavlov it looks like you're an owner of the sm2
crate. Do you know its status?
from elliptic-curves.
@tarcieri
I have added @RustCrypto/elliptic-curves to owners of sm2
(though I don't remember exactly how I got it).
P.S.: I think it would be better to use the Zulip private chat for such questions, since I doubt other users are interested in these matters.
from elliptic-curves.
I see that secp256k1
is supported, and seems to be the most complete so far, is this generalized? Would it be easy to support other k1 curves, for example secp224k1
?
from elliptic-curves.
@halvors supporting any given curve is a lot of work, as we need to synthesize field implementations (both base and scalar) for each curve, and plug in formulas for the parts of the field implementation which can't be synthesized.
The curve arithmetic implementation is generic; the field arithmetic implementations are not.
from elliptic-curves.
@halvors supporting any given curve is a lot of work, as we need to synthesize field implementations (both base and scalar) for each curve, and plug in formulas for the parts of the field implementation which can't be synthesized.
The curve arithmetic implementation is generic; the field arithmetic implementations are not.
I fully understand that it is a lot of work, but would it still be possible to add it to the list to eventually be added in the future when the other curves are finished?
Also I can to the best of my ability help out, I don't think I am skilled enough to write the field arithmetic implementation myself, but still I can help out with other tedious work like adding test vectors etc that maybe isn't a lot of help but hopefully still can reduce the amount of work that has to be done.
from elliptic-curves.
Okay, I can add it, although I'd prefer to implement curves people are actually using
from elliptic-curves.
Okay, I can add it, although I'd prefer to implement curves people are actually using
Very understandable, in my use case i have to verify signature using P-192, P-224, and k224 (but not signing) this is due to the fact that i am verifying authentication tokens issued by an external provider (somewhat dated one of that).
So me personally have a use case for it, but i understand that the curve is rather exotic and not much used in general.
Has there been any progress on generalizing k256? If so could generic implementations be reused for k224? Or is something that is yet to be done?
from elliptic-curves.
Has there been any progress on generalizing k256? If so could generic implementations be reused for k224? Or is something that is yet to be done?
@halvors https://github.com/RustCrypto/elliptic-curves/tree/master/primeorder seems to be it? Have you tried applying it to your curves?
from elliptic-curves.
Yeah,
primeorder
should work fine for it, but there are other curves I'd like to work on first which are niche but more commonly used, like the Brainpool curves
For future reference the problem with primeorder
is that it doesn't support n
bigger than it's size. For secp224k1
this is 29 bytes long not 28 bytes as other 224 sized curves. AFAIK this requires a breaking change in the primeorder
crate.
from elliptic-curves.
p224
andp521
now have base and scalar field implementations, as well as curve parameter definitions, although none of it is properly tested and all gated under thewip-arithmetic-do-not-use
crate feature.
#114 (comment)
Hello, does this mean basic field arithmetic is currently expected to "work" with these curves (but untested and potentially having bugs and security flaws)?
Is it expected that this snippet features unmarked multiplication overflows (which panics in debug)?
use elliptic_curve::SecretKey;
use p521::NistP521; // with feature wip-arithmetic-do-not-use
fn main() {
let mut rng = rand::thread_rng();
let secret_key : SecretKey<NistP521> = SecretKey::random(&mut rng);
let public_key = secret_key.public_key();
println!("{:?}", public_key);
}
Which apparently occurs in fiat generated code, at https://github.com/RustCrypto/elliptic-curves/blob/master/p521/src/arithmetic/field/p521_64.rs#L324
Moreover if one forgets overflows (e.g. compiles in release), the snippet still does not work as multiplication here relies on inversion, which is unimplemented at the moment. So it appears a scalar multiplication cannot be performed.
I am not too familiar with the structure of the repository and its implementation ; what is the current state of the implementation of these curves, besides the lack of tests and security confidence?
Sorry if this should be in another issue, I don't know as I don't know how much this is expected.
from elliptic-curves.
p521
is not expected to work, no. I'm not sure why you expected that from a feature called wip-arithmetic-do-not-use
to indicate it's expected to work.
p224
has since been promoted to a proper arithmetic
feature after tests were added, but p521
has not and has known issues.
It uses a different fiat-crypto code generator specific to Solinas primes, which is a unique property of the prime modulus of the P-521 base field. However, something is wrong with the implementation and I haven't figured out what.
I've been hoping the new codegen in fiat-crypto
which uses newtypes in place of type aliases might help track down the issue, but haven't had time to try to update the generated code (and note in general that's a relatively difficult thing to do).
from elliptic-curves.
use elliptic_curve::SecretKey; use p521::NistP521; // with feature wip-arithmetic-do-not-use fn main() { let mut rng = rand::thread_rng(); let secret_key : SecretKey<NistP521> = SecretKey::random(&mut rng); let public_key = secret_key.public_key(); println!("{:?}", public_key); } ```.
This note returns a valid public key :)
Required changes:
from elliptic-curves.
@drcapybara there's already a few implementations of it out there, e.g. https://crates.io/crates/ed448-goldilocks
We could potentially ask about upstreaming them
from elliptic-curves.
Any plans to support bn254?
from elliptic-curves.
Arkworks already has an implementation of BN254: https://github.com/arkworks-rs/curves/tree/master/bn254
from elliptic-curves.
Is the required refactoring done in primeorder in order to support secp224k1 with N being 1 bit larger than the curve?
If not what is blocking this and when can it be done?
from elliptic-curves.
The breaking change needs to happen in the elliptic-curve
crate, not just primeorder
, and it probably needs some design work, i.e. new type names, which is something that's really needed revisiting for awhile. Regardless, the relevant issue and place for discussion is here: RustCrypto/traits#1304
from elliptic-curves.
Thank you for all of your work, it's a great endeavor. Did you get to spend any time on the Brainpool curves down the road?
from elliptic-curves.
Yeah, still haven't gotten to the bottom of what the issue is with them, but they should be close to having arithmetic backends
from elliptic-curves.
Has the secp384r1 been done?
from elliptic-curves.
@drcapybara there's already a few implementations of it out there, e.g. https://crates.io/crates/ed448-goldilocks
We could potentially ask about upstreaming them
where does this stand currently? The last published version of this crate came in about a year ago it looks like
from elliptic-curves.
We could potentially inquire on the upstream repo: https://github.com/crate-crypto/Ed448-Goldilocks
from elliptic-curves.
secq256k1? Should be trivial given the secp256k1 code present.
from elliptic-curves.
Related Issues (20)
- Update crates to the newtype `fiat-crypto` codegen
- Request: Instructions to reproduce fiat-crypto files HOT 2
- Using ECDSA key pair for ECDH HOT 1
- Prepend the TapSigHash tag when doing k256 Schnorr signatures? HOT 1
- bp256+bp384: tracking issue for `arithmetic` feature HOT 3
- Numerous unused variable cause Rust difficulties HOT 3
- Bug(deps) p521 crate requires ecdsa 16.8 HOT 2
- BIP340 Schnorr should accept arbitrary length messages HOT 6
- p256::Scalar: implement Reduce<U512> HOT 1
- PKCS8: Cannot parse PrivateKey HOT 2
- Asymmetry in default features: only p384 has `ecdh` by default HOT 2
- Poseidon Support for k256 Hash To Curve HOT 1
- Document use with the PKCS#8 HOT 1
- Pre-release of k256 v0.14? HOT 3
- k256 does not compile without allocator HOT 5
- Additional wycheproof test cases for secp256k1 HOT 3
- k256 disrepency in secp256k1 key recover HOT 12
- How to convert a VerifyingKey of type FieldElement10x26 to a FieldElement5x52 type
- k256: v0.13.2 breaking verification HOT 9
- Bitwise operations for scalars HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from elliptic-curves.