const_fn is stable since Rust 1.31
(https://github.com/rust-lang/rust/pull/54835) and enables calling
`Scalar::from_bits(..)` from other const fn contexts, potentially
saving some overhead here and there.
Especially useful in contexts where constants are being built from a bit
pattern.
The `signature` crate provides `Signer` and `Verifier` traits generic
over signature types:
https://github.com/RustCrypto/traits/tree/master/signature
There's presently an open call to stabilize the parts of its API needed
by Ed25519 signatures and release a 1.0 version:
https://github.com/RustCrypto/traits/issues/78
The `ed25519` crate, based on the `signature` crate, provides an
`ed25519::Signature` type which can be shared across multiple Ed25519
crates (e.g. it is also used by the `yubihsm` crate):
https://github.com/RustCrypto/signatures/tree/master/ed25519
This commit integrates the `ed25519::Signature` type, and changes the
existing `sign` and `verify` methods (where applicable) to use the
`Signer` and `Verifier` traits from the `signature` crate. Additionally,
it replaces `SignatureError` with the `signature` crate's error type.
This has the drawback of requiring the `Signer` and/or `Verifier` traits
are in scope in order to create and/or verify signatures, but with the
benefit of supporting interoperability with other Ed25519 crates which
also make use of these traits.
The `crypto_box` crate provides a pure Rust implementation of the
public-key authenticated encryption primitive from NaCl which combines
X25519 + XSalsa20Poly1305 (a.k.a. "Curve25519XSalsa20Poly1305")
This commit adds a link to it case x25519-dalek users are interested in
using it as part of a hybrid cryptosystem.
This is useful for programs/protocol which can do some heuristics or
learning-based approach towards optimising the table size based on the number of
uses of e.g. a public key, the second basepoint in a Pedersen commitment, etc.,
i.e. the first time a public key is used to verify a signature, the usual
variable-time basepoint multiscalar multiplication is used, however after 1000
verifications, the table size is upgraded, and again after 10000 verifications,
etc.
This implements a macro for implementing the BasepointTable trait, and
uses the macro to create basepoint table types. The default table
still uses radix-16 representation and is ~30KB in size. The new
table types, and their memory usage and additions required per
basepoint multiplication are:
* `EdwardsBasepointTableRadix64`: ~120KB, 43 additions
* `EdwardsBasepointTableRadix128`: ~240KB, 37 additions
* `EdwardsBasepointTableRadix256`: ~480KB, 32 additions
It doesn't appear to me that ed25519-dalek crate needs any of the std-related
features of serde. But it turns them on anyways because it doesn't put
`default-features = false`.
This breaks no_std builds. Otherwise I think we could use 1.0.0-pre3 in mobilecoin.
I'm going to test this revision in our build and see if I'm right. I don't think
this is a breaking change from dalek's point of view.
