Tony Arcieri

`PublicKey` and `SecretKey` are really intended for working with wire formats (e.g. PKCS#8/SPKI), and in that regard, seem orthogonal to `hash2curve`, which use a different class of wire formats (or...

FWIW, I proposed renaming `group::Curve` to `group::CurveGroup` here, which I think would cut down on some of the confusion: https://github.com/zkcrypto/group/issues/51

I would probably suggest against any breaking changes to `zeroize`. Due to the trait-based nature of its API, which is used across crates, it makes breaking changes extremely difficult due...

`dsa` and `rsa` are some examples of where data isn't flat. Keys have a single secret field, but the type which stores them is a newtype for e.g. `Box`/`Vec` like...

> For most of RustCrypto crates upgrade should be quite painless since they do not provide Zeroize impls and instead only have zeroizing Drop and ZeroizeOnDrop. As argued above, the...

> I think you overestimate potential consequences. Downstream crates which derive Zeroize/ZeroizeOnDrop on their structs will continue to work without any changes. There are a lot of uses which aren't...

The problem is when you have cross-crate interdependencies, especially when there are multiple different vendors of crates at various levels, e.g.: protocol implementation -> elliptic curve library -> numerical library...

Yet another approach is to simply make a new library with a different name which provides the same functionality / end goals, which can be vetted independently, and if it...

> One of motivation factors for the proposed redesign is desire to remove a lot of zeroize boilerplate from our crates. I think we can make progress there without breaking...

> Zeroizing usefulness is limited. It can be used only for "primitive" types (e.g. raw keys), complex types do not implement Zeroize and instead implement zeroizing Drop. This isn't quite...