Hi,

I've previously spoken with @newpavlov via e-mail, and he asked me to create this PR and made some cursory comments on the original, internal-to-MobileCoin, source code for this crate. I've attempted to address the comments and clarify the Nonce object's purpose. My goal here is to get this interface into widespread usage, so I'm amenable to changing whatever needs to be changed to make that a reality.

The crate itself is intended to provide a misuse-resistant, rust-ish way to use RFC5116 AEAD ciphers.

Migrating to 2018 edition is a long overdue and since it's a good chance to introduce breaking changes, I propose to use this issue to discuss them. Right now I have the following list of changes:

• [x] Migrate to 2018 edition and bump MSRV to ~~1.36~~ 1.41 (needed for generic-array v0.14)
• [x] Update generic-array to ~~v0.13~~ v0.14.
• [x] Release crypto-mac v0.8 which uses subtle v2. (see #35)
• [x] Rename crypto_mac::Mac::input and digest::Digest::input methods to update.
• [x] Rename digest::Input to digest::Update.
• [x] Remove digest::Reset trait in favor of reworked FixedResult trait. See this comment.
• [x] Deprecate block-cipher-trait and use block-cipher crate instead #28.
• [x] Introduce a new NewBlockCipher trait (#164).
• [x] Add stream_cipher::FromBlockCipher trait.
• [x] Add impl_write! macro to crypto-mac.
• ~~Find solution for buffer-to-buffer cipher operations #31~~
• ~~Add try_new methods~~ (closed as wontfix, see #47)
• [x] Rename MacResult type to something like Code/Output and rename code method to into_bytes for consistency with the universal-hash crate.
• ~~Add macro for implementing io::Write to crypto-mac similarly to the digest crate.~~ (dup of above)
• [x] Bump opaque-debug to v0.2
• ~~Support variable length AEAD Nonces #65~~ (EDIT: solved by making ciphers generic over their NonceSize)
• [x] Rename crypto_mac::Mac::result, digest::Digest::result, and universal_hash::UniversalHash::result to ::finalize or ::finish

I may have forgotten some changes I had in mind. Feel free to suggest other public API changes.

This is a tracking issue for a final v0.3.0 release of the cipher crate, containing such changes as refactored block cipher traits (#352), unified error types (#373), and lots of cleanups of things that were missed with the "initial" release of the cipher crate (v0.2, bumped from the v0.1 releases before we owned it).

From my perspective it's ready to release, however there are at least a few things it might be worth considering getting in there before we do:

• [x] #344: make dev modules private, re-export blobby from toplevel
• [ ] #272: merge block-modes crate into cipher

@newpavlov any others?

It would be nice to have support for a from_uniform_bytes functionality for the elliptic curve implementations that performs the hash-to-curve operations described here, preferably the _SSWU_RO_ variants!

This is an announcement of a 2-week final comment period (ending March 22nd) which will be followed by a 1.0 release of the signature crate some time thereafter.

Original 1.0 stabilization proposal here.

Current status

I've published signature v1.0.0-pre.3, which includes significantly more documentation and clearly calls out (using doc_cfg) the 1.0 stable versus unstable "preview" parts of the API:

Docs: https://docs.rs/signature/1.0.0-pre.3/signature/index.html

I'd love feedback on the docs before a final release, particularly what parts of the current design remain unclear.

Note that I do intend to include more usage examples, but I would like those examples to highlight notable real-world ecosystem examples rather than contrived ones, and there's a bit of a chicken-and-egg problem in doing that.

API to be stabilized

The goal of this stabilization proposal is to stabilize the following types in the signature crate:

• Signature
• Signer
• Verifier
• Error

The remaining types (e.g. Digest*) now require enabling off-by-default *-preview features which call out their instability, but with a pledge that breaking changes are accompanied by a minor version bump. I've opened separate tracking issues for each of these here:

• #92 digest-preview: DigestSignature, DigestSigner, DigestVerifier
• #93 derive-preview: custom derive for Signer and Verifier for use with DigestSignature
• #94: rand-preview: RandomizedSigner

Rationale for stabilization

The four types/traits called out earlier for stabilization are sufficient for stable use of Ed25519 signatures/signers/verifiers via the ed25519 crate, which is intended to see a 1.0 release as well after a 1.0 release of this crate is published. This is the main impetus for a 1.0 release of this crate.

Current usage

The signature traits have seen a lot of real world usage, both in libraries that natively use them, and in crates which provide thin wrappers (and therefore a unified object-safe API) across several other notable ecosystem crates:

• ed25519-dalek: via the signatory-dalek wrapper crate. There is also an open PR to use the signature traits and ed25519 crate directly
• ring: via the signatory-ring crate
• secp256k1-rs: via the signatory-secp256k1 crate
• sodiumoxide: via the signatory-sodiumoxide crate

Crates which natively leverage the signature traits include:

• yubihsm for ECDSA and Ed25519 signing
• ledger-tendermint for Ed25519 signing

Alternatives considered

NOTE: See also the "Alternatives considered" section of the signature rustdoc.

This stabilization proposal is for a trait/object-safe API, as enumerated above. The main audience of this API is consumers of digital signature systems, and thus its design is very much optimized with that audience in mind.

Several people have proposed, and we have previously investigated, an alternative design based on generic signature types with algorithm-specific marker traits, as well as leveraging use of associated types, rather than generic type parameters on traits, to allow the usage of more concrete types. An API like this would be more beneficial to implementers of signature provider libraries, and allow less invasive first-class support of the signature traits.

The good news is that these approaches aren't orthogonal, and several of the other crates in RustCrypto/traits provide both an object-safe high-level API as well as an associated type-leveraging lower-level API for similar reasons. Done correctly there can be a blanket impl of the object-safe API for the provider-oriented API.

That said, the design and implementation of such an API isn't considered a blocker on a 1.0 release specifically for the reasons that it can be implemented in the future in a purely additive manner.

• [x] Allow methods to accept multiple data/msgs by using &[&[u8]], á la Hkdf::expand_multi_info().
• [x] Implement hash_to_scalar, got an implementation for P-256 already working with test vectors.
• [x] Remove 'static requirement for dst. Maybe we don't want hash_to_scalar on GroupDigest, because it also pulls in arithmetic for no real reason.

The goal here is to make this usable for voprf. VOPRF sometimes builds complex msgs that are impossible to concat without allocation, this is why the multi-message API was necessary. I would even prefer just to take an Iterator<Item = &[u8]>.

The 'static requirement doesn't work for VOPRF because it needs to build the dst from multiple parts that are party derived from associated types from traits, this can't be used in const to build a &'static [u8] in Rust right now.

CC @tarcieri @mikelodder7

The hash2curve module has three submodules which start with the expand_msg prefix:

• expand_msg
• expand_msg_xmd
• expand_msg_xof

This commit refactors them into a structure I think its more idiomatic, placing xmd and xof into submodules:

• expand_msg
  • xmd
  • xof

Accessing them is effectively the same:

• expand_msg_xmd => expand_msg::xmd
• expand_msg_xof => expand_msg::xof

I'd cite this as precedent (which is similar, but not quite exactly the same thing):

https://github.com/rust-lang/rfcs/blob/master/text/0356-no-module-prefixes.md

We've had a long standing request to do new crate releases (#43). Unfortunately, I haven't heard back from this project's creator (@newpavlov) since January 2020.

I have access to the full GitHub org, but unfortunately, do not have crates.io publishing access to the overwhelming majority of crates in this repository (I have it for the signature and universal-hash crates but none of the others).

Unless we hear back from @newpavlov (which I think would be the best outcome!) the only way to publish new crates is under a new set of names. This would be unfortunate as the current names are somewhat ideal, and would also be disruptive as people would need to figure out the new names, but the only way to make progress.

It's getting to the point I'm not sure what else to do besides attempting this, so here are some proposed options for how to proceed... I've gone ahead and squatted all of these names just to make sure I'll have access.

For each existing crate, I've registered a plural version, a "longer" version, and also the same name but prefixed with a rustcrypto-* pseudo-namespace:

| Current Name | Plural Name | Longer Name | rustcrypto-* prefixed name | |---------------|-------------|---------------|------------------------------| | aead | aeads | authenticated-encryption |rustcrypto-aead | | block-cipher-trait | block-ciphers | N/A | rustcrypto-block-cipher | | crypto-mac | crypto-macs | message-authentication-codes | rustcrypto-mac | | digest | digests | hash-functions | rustcrypto-digest | | signature | N/A | digital-signatures | rustcrypto-signature | | stream-cipher | stream-ciphers | N/A | rustcrypto-stream-cipher | | universal-hash | universal-hashes | N/A | rustcrypto-universal-hash |

Of these available options, I'm personally inclined to go with adding a rustcrypto-* prefix (I also claimed the rustcrypto crate itself). It seems like the most straightforward way to transition (particularly if @newpavlov returns and is able to publish crates under the original names again).

This commit adds encrypt_in_place_detached() and decrypt_in_place_detached() methods to Aead and AeadMut, along with default implementations of encrypt() and decrypt() which assume a postfix authentication tag.

Presently all of the AEAD implementations in RustCrypto/AEADs use this pattern. This PR exposes the detached interface as a public API:

https://github.com/RustCrypto/AEADs/pull/21

Note that this need not be the only in-place API (hence the long name with _detached on the end. I plan on doing a follow-up PR for adding an in-place API which does not depend on alloc but also handles ciphertext message assembly/parsing, which would be more useful for end users.

That said, this API isn't just useful for AEAD implementers: there are genuine use cases for a detached API from an end user perspective, e.g encrypted filesystems.

With the addition of this API, we can also make alloc an optional (but enabled-by-default) feature, allowing use of AEADs on truly #![no_std] targets.

As noted on #865 there are some potential overflow problems constructing the messages used for expansion, particularly around input lengths.

This commit changes ExpandMsg::expand_message, and all of its transitive callers, to be fallible in order to handle these cases.

cc @mikelodder7 @daxpedda

Closes #263.

Adds a crate containing a no_std-friendly heapless/stack-allocated implementation of the PHC string format specification.

As the specification notes, it's designed with constraints which enable implementations based entirely on stack-allocated buffers. In order to maximize portability, this implementation relies entirely on stack allocated buffers.

With https://github.com/dalek-cryptography/curve25519-dalek/pull/473 hopefully getting done, it would be nice to use more types with Ristretto255.

Unfortunately types like PublicKey, SecretKey, NonZeroScalar, hash2curve::GroupDigest, and the ecdh module all work over Curve, which can not be implemented over Ristretto255 (as far as I understand).

So transitioning these types to use Group instead could allow us to use these types with Ristretto255 too.

It would be nice to implement math that is generic over both projective and affine points with a common prime marker trait, see https://github.com/zkcrypto/group/issues/43. I believe in the meantime we could use Into<ProjectivePoint<C>> where C: PrimeCurve.

In the future I would like to implement the following math (which I believe are correct):

• Multiplication between NonIdentity points.
• Multiplication with NonZeroScalar.
• Introduce fn add_identity(&self) -> NonIdentity.

Additionally the PublicKey type has to be adjusted to return NonIdentity when appopriate, which is a breaking change.

On a last point I would like to suggest renaming this to NonIdentityPoint, which would be more in line with NonZeroScalar.

Fixes #1170.

This is a tracking ticket for releases of signature 2.0 and its downstream dependencies, with changes originally proposed in #237 and implemented in #1141.

The goal is to perform a coordinated release of all of these crates in a relatively short timeframe to ensure people who use several of these crates in a single project are not blocked on upgrades.

RustCrypto/traits

• [ ] signature v2.0.0

RustCrypto/signatures

• [ ] dsa v0.5.0
• [ ] ecdsa v0.15.0
• [ ] ed25519 v2.0.0

RustCrypto/elliptic-curves

• [ ] bp256 v0.5.0
• [ ] bp384 v0.5.0
• [ ] k256 v0.12.0
• [ ] p256 v0.12.0
• [ ] p384 v0.12.0

RustCrypto/SSH

• [ ] ssh-key v0.6.0

dalek-cryptography/ed25519-dalek

• [ ] ed25519-dalek v2.0.0

This is similar to NonZeroScalar.

I often found myself handrolling custom serde implementations to make sure that a ProjectivePoint is not an identity element.

Additionally it could be useful to allow arithmetic that can guarantee some outputs without having to constantly check for identity elements. For example multiplying a NonIdentityElement with a NonZeroScalar should yield a NonIdentityElement without having to do any checks or returning an (Ct)Option.

Interactions with PublicKey could be similar to whats done between NonZeroScalar and SecretKey, enabling non-fallible conversions.

Happy to make a PR of course.

Not sure if this is the right place for this, but we've found frequently needing to read or write data while simultaneously hashing the data. Based on the implementation in the phase2 crate, gated by the "std" feature.

While creating this PR I noticed this previous PR which is somewhat related, but I think a little different, and I also note the documentation describes that hashers can implement io::Write, which I think is also slightly different.