[pull] master from RustCrypto:master - #4
Open
pull[bot] wants to merge 1945 commits into
Open
Conversation
dingelish
force-pushed
the
master
branch
2 times, most recently
from
October 5, 2019 19:19
bdfc1ca to
6447161
Compare
I was myself confused by the breakages removing these methods caused the other week: RustCrypto/formats#2140 (comment) If it's confusing me as the person who made the changes, no doubt it will confuse others, as it's something of a counterintuitive migration (though ultimately for the best). This adds back the methods trying to mostly preserve the type signatures from `crypto-common` v0.1, and deprecates them, along with providing documentation for what to do instead.
Provides a common API for retrieving the canonical representitive for a given field element
Adds a dependency on `crypto-common` (all curve implementations pretty much have a transitive one already) and replaces all of the RNG functionality with the new `Generate` trait (#2096), for the following types: - `NonZeroScalar` - `ScalarValue` - `SecretKey` - `ecdh::EphemeralSecret` Additionally `Generate` trait bounds have been added to the associated types for `CurveArithmetic`: `AffinePoint`, `ProjectivePoint`, `Scalar`
Impls the newly added trait from `crypto-common`. Also impls its supertrait `KeySizeUser`.
This makes way to add more functionality to the `dev` module that isn't related to `MockCurve`, which currently occupies the entire module. The types are re-exported with a deprecation, for now, though maybe we can get rid of that before a release.
Writes `criterion` benchmarks for `ProjectivePoint` using a macro which has been tested with both `criterion` v0.7 and v0.8, which means we can release on the former (for MSRV 1.85 compat) and then later upgrade to to the latter in a non-breaking manner
Release which includes #2152
The current code is not compatible with `v0.2.0-rc.8`
Rather than using the `FromStr` impl to parse the associated `Params` type, it instead bounds on a `TryFrom<phc::ParamsString>` impl, which provides a more explicit PHC-specific params conversion.
Better describe what this crate actually does
Traits which provide an API for interacting with Key Derivation Functions. We have several of these located at https://github.com/rustcrypto/kdfs and password-based KDFs at https://github.com/RustCrypto/password-hashes but the APIs for using these are typically just free functions, whereas traits could provide a common API.
## Added - Enable `missing_debug_implementations` lint and add `Debug` impls (#1411) - `AeadCore::TAG_POSITION` and `TagPosition` enum (#1798) - Re-export `crypto_common` as `common` (#2237) ## Changed - Replace `generic-array` with `hybrid-array` (#1384) - Edition changed to 2024 and MSRV bumped to 1.85 (#1759) - Replace `AeadInPlace` with `AeadInOut` (#1793) - Split `new_test!` into `new_pass_test!` and `new_fail_test!` (#2019) - Bump `crypto-common` to v0.2 - (#2276) ## Removed - `AeadCore::CiphertextOverhead` constant (#1737) - Stateful AEAD traits: `AeadMut*` (#1740) - `stream` module - extracted into `aead-stream` crate (#1801) - `heapless` support - will be added back in a future patch release (#1999) - Nonce generation APIs - use `Generate` trait instead (#2098) ## Fixed - Minor documentation error in `AeadCore::TagSize` (#1351)
The w-NAF implementation, originally from `group`, was extracted into its own crate in RustCrypto/elliptic-curves#1777
The main thing this feature enables is the w-NAF implementation in the `group` crate, which is currently incompatible with our curves due to the big endian field serializations. This instead should help direct people to use the implementation from the `wnaf` crate instead, re-exported as `elliptic_curve::wnaf`
This release uses the w-NAF implementation from the `wnaf` crate
We can move all of this functionality to `primeorder`, which is *much* easier than trying to keep all of it here, while also making it easier to iterate on because it's all in one repo. The real goal was to share this code between `k256` and elsewhere, with much of it originating in `k256`, but now `k256` uses `primeorder` as a hard dependency when its `arithmetic` feature is enabled.
Upstreams some of the bounds from RustCrypto/elliptic-curves#1800, useful for several common use cases like radix-16 precomputed tables as well as SEC1 point serializations.
This removes the `basepoint-table` and `wnaf` features, shrinking the API surface, and ideally getting us to a true release candidate (I'd hope so after 35 "release candidates"!)
## Changed - Have `getrandom` feature enable `rand_core` (#2452)
The previous `BatchInvert` trait was based on blanket impls bounded by `Field`, unfortunately `k256` needs to provide its own to handle normalization. The new version operates in-place requiring a temporary buffer, whereas the previous version return a value. This winds up making the generic implementation of something like batch normalization significantly simpler, since it can be in complete charge of the storage. It also means we don't need separate methods for arrays vs slices / `Vec`. I'm sure we discussed and considered that at one point in the past and I probably said no at the time, but this style of API makes the downstream code *significantly* simpler. Also, rather than blanket impls it has a generic provided implementation which can work everywhere except `k256`, which needs to do its own normalization. Companion PR: RustCrypto/elliptic-curves#1829
Instead of supplying our own generic implementation of Montgomery's trick, we can use the one in `ff` supplied by `BatchInverter`, which just so happens to have a signature that's very close to the one we switched to in #2455 (great minds think alike). The main difference between that PR and what `BatchInverter` provides is instead of returning a `Choice` in the event of zero elements, it ignores them and returns the inverse of the product of all non-zero field elements.
…2457) Removes the `FieldBytesEncoding` trait and replaces it with: - `Curve::FIELD_ENDIANNESS` which defaults to `ByteOrder::BigEndian` - `field::{bytes_to_uint, uint_to_bytes}` generic free functions This constant annoyingly duplicates the ones we have elsewhere, but without getting it upstream into `ff` (zkcrypto/ff#158) there is no single other convenient place to hang it but here. Ideally this functionality could be phased out completely, but there are still places that need it for now (e.g. legacy `rfc6979`, ECDSA recovery). In a future breaking release after the imminent one, we need to refactor everything so the base and scalar fields are treated completely separately. At that point, hopefully this all can and will need to go away, and we will be able to leverage an upstream endianness constant instead of having to stick (another) one in `elliptic-curve`.
We've generally tried to hide base field element types from the public API, but this has lead to a litany of poorly composing workarounds since there's no way to generically access the base field element type whatsoever. Instead we have the `field` module (and formerly the `FieldBytesEncoding` trait) along with `FieldBytes` and `FieldBytesSize` with the latter an alias to `Curve::FieldBytesSize`. Without a central place to hang that type-level information and trait bounds, things have gotten somewhat messy. `primeorder` ended up defining its own associated `FieldElement` type as part of `PrimeCurveParams`. This commit effectively vendors that associated type into a new `hazmat` module, similar to the modules we have in other crates e.g. `ecdsa`, as a new `FieldArithmetic` trait with an associated `FieldElement` type, which `primeorder` can switch to using. We can then remove features like `export-field` which re-export `FieldElement` at the toplevel of crates, mixing it in with other types like `Scalar` and `AffinePoint`/`ProjectivePoint` as opposed to keeping it at a separate level of abstraction. Anyone wanting field element access no longer needs to futz with features, but *does* need to import this `hazmat` trait.
May it be the one that is truly a "release candidate", after thirty some other failed attempts
Most of the time this is what we're doing anyway, and the functional style is a bit more awkward. Also bounds `Double` on `Sized`.
It was previously in `point`, but I kept looking for it in `ops` which seems like a better location for it. While points are one of the main things we double, it could also potentially be used on field elements as well, so it seems more like `ops` than `points`.
## Added - Implement `PartialEq + Eq` for `NonIdentity` and `NonZeroScalar` (#1834) - Implement `Zeroize` for `NonIdentity` (#1832) - `NonIdentity::mul_by_generator()` (#1833) - Implement `Mul<&NonZeroScalar>` for `NonIdentity` (#1852) - Implement `Mul<NonIdentity>` for `NonZeroScalar` (#1855) - Expose `AffineCoordinates::y` (#1891) - Scalar macros originall from `primeorder` (#1894) - Implement `BatchNormalize` for `NonIdentity` (#1896) - Re-export `group::Curve` as `CurveGroup` (#1902) - `NonIdentity`/`NonZeroScalar` casting methods (#1903) - `AffineCoordinates::from_coordinates` (#1996) - `getrandom` feature (#2085) - `ctutils` traits to `arithmetic` bounds (#2166) - `Retrieve` bound for `C::Scalar` (#2169) - `crypto_common::Generate` support (#2173, #2208) - Implement `crypto_common::TryKeyInit` for `SecretKey<C>` (#2174) - `dev::bench_projective!` macro (#2177) - Provide `Sec1Point::from/to_sec1_bytes` (#2221) - Implement `From<SecretKey<C>>` for `PublicKey<C>` (#2247) - `SecretKey::diffie_hellman` (#2248) - `LinearCombination::lincomb_vartime` method (#2286) - `ops::MulVartime` trait and bound `Scalar` (#2379) - `ops::MulByGeneratorVartime` trait ([#2381]) - `SecretKey::from_pem` (#2387) - `SecretKey::from_der` (#2408) - `hazmat` module with `FieldArithmetic` trait (#2458) - `Double::double_in_place` (#2464) ## Changed - Migrate from `generic-array` to `hybrid-array` (#1462) - Rename `LinearCombinationExt` => `LinearCombination`; replacing old trait (#1501) - Edition changed to 2024 and MSRV bumped to 1.85 (#1759) - Make `SecretKey::new` fallible (#1804) - Replace `ops::Invert` trait with `crypto_bigint::Invert` (#1839) - Rename `SecretKey::new` => `::from_scalar` (#1893) - Replace `Reduce` trait with `crypto_bigint::Reduce` (#1949) - Bump `serdect` dependency to v0.4 (#1978) - Use `crypto_bigint::Odd` to represent `Curve::ORDER` (#2006) - Bound `Curve::Uint` on `Unsigned` (#2007) - Rename `ScalarPrimitive` => `ScalarValue` (#2008) - Accept mixed-case hex-encoded strings in `FromStr` impl for `ScalarValue` (#2037) - Deprecate `SecretKey::random` (#2086) - Move `MockCurve` to `dev::mock_curve` (#2176) - Bump `rand_core` to v0.10 (#2250) - Rename `EncodedPoint` => `Sec1Point` (#2264) - Bump `crypto-bigint` to v0.7 (#2330) - Bump `digest` to v0.11 (#2331) - Bump `sec1` to v0.8 (#2339) - Bump `hkdf` dependency to v0.13 (#2349) - Use `*Vartime` as a suffix in names (#2378) - Bump `pkcs8` to v0.11 (#2397) - Bump `ff` and `group` to v0.14 (#2430, #2431) - Simplify `BatchInvert` trait (#2455) - Replace `FieldBytesEncoding` trait with `C::FIELD_ENDIANNESS` (#2457) - Move `Double` to `ops` module (#2465) ## Removed - `hazmat` feature (#1599) - `hash2curve` and `oprf` modules: moved to same-name crates (#1929) - PKCS#8 blanket impls for SEC1 private key traits (#1930) - `ShrAssign` bound on `Scalar`s (#1938) - JWK support: migrated to `jose-jwk` crate (#1963) - `weierstrass` module (#2005) - `bits` feature (#2417) ## Fixed - Include curve OID in SEC1 private keys (#1707, #1933)
…2468) Adds the following: - `BatchInvert::batch_invert_in_place_vartime` - `BatchNormalize::batch_normalize_vartime` Both are provided methods that currently call the constant-time path, but in the future we can potentially provide default implementations that are variable-time and optimized. Since the new methods are provided, this isn't a breaking change.
The `ecb` crate was transferred to RustCrypto in RustCrypto/block-modes#118.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )