Optionally implement zerocopy traits on relevant curve25519_dalek and x25519_dalek types

[danderson]

Fixes #821

Overview

The PR has 3 self-contained commits:

• The main change that does the Cargo.toml paperwork and adds the trait derivations to types which can/should be safely transmutable to byte sequences.
• Changelog entries for both crates. I kept this one separate because I don't know the project convention: do you add changelog entries when actually doing a release, or do you accumulate changes incrementally into vNext as they show up? I kept the change separate so it's easy to drop if unwanted.
• Feature table in x25519_dalek's readme. Not strictly related to this change, but I missed having it when I started using the crate, and so figured while I'm in the area... I tried to keep the style in line with the features table in curve25519_dalek, and like in that crate didn't document features whose only purpose is to propagate features into dependencies (e.g. precomputed tables).

Testing

Tested both modified crates with:

cargo test --no-features
cargo test --all-features
cargo test --features=zerocopy
cargo test --no-default-features --features=zerocopy
cargo test --no-default-features --features=zerocopy,alloc
cargo clippy --all-features

I didn't add any new tests, since the change is merely deriving new traits that come with their own compile-time correctness checking. If you like, I could add a test that does nothing more than verify that the trait methods are available when the feature's enabled, to avoid a regression where the derives are mistakenly removed?

[tarcieri]

Impls on the public key types are fine, but impls on secrets are slightly worrisome.

One scenario is someone may unintentionally pass the wrong type and could accidentally expose key material because both the public and secret types impl the same trait.

[danderson]

The same concern applies to the serde traits, no? By definition, StaticSecret is transformable into a form that can be stored, that's why it exists as a separate (riskier) type than ReusableSecret. You could also as_bytes() the key and pass it to anything that handles bytes and the type system won't stop you.

I can see an argument for only allowing serialization via explicit, non-trait methods in order to make it harder to accidentally trigger serialization, but in that case the same argument should apply to the serde derivations?

[tarcieri]

Yes, FWIW the @RustCrypto crates don't implement the serde traits on secrets, though I guess that happened in curve25519-dalek

[danderson]

For my purposes, zerocopy is most useful for serializing data into network packets, and indeed in that case it would be quite bad to serialize a cleartext secret key :)

I'm okay with either outcome, either consistency with the serde traits or treating the serde traits as a historical mistake (I assume we can't remove them without a breaking semver release). In the latter case I can remove the derivations from StaticSecret.

... although tbh that means this entire change, with a new cargo feature and all the plumbing, is effectively to support zerocopy on a single type (x25519 PublicKey), and maybe we're back to the discussion of "is this even worth it" :)