-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Async traits #304
Comments
I would really love to find some solution for allowing an embedded cryptographic accelerator to process work in the background while the primary processor/MCU is performing other operations. Down-the-road I think This would be quite helpful for algorithms like AES-GCM and AES-GCM-SIV (decryption, at least), by allowing encryption to happen in parallel on an accelerator/coprocessor while authentication is handled on the main processor/MCU. |
In nightly it is already possible to have async traits with IMO it's not worth it to stand up an async traits ecosystem with the current async_trait crate or other workarounds that require alloc/dyn, only to break them later when switching to "real" async traits with |
Another potential use-case is using Web Crypto API as a backend for some algorithms. But I also don't think we should depend on the Another question is what to do with the software implementations? Should we in future add a wrapper which would use a thread pool to emulate async API? |
Sounds good to me! As noted above, the
Seems pretty context-dependent to me. I think it's a problem worth leaving open-ended initially, letting people define the sync-vs-async relationships as they see fit, and then perhaps seeing if there are common patterns we could wrap up with things like blanket impls (perhaps gated with marker traits) or failing that, proc macros. |
Adds an `async-signature` crate with `AsyncSigner` and `AsyncDigestSigner` traits, based on the `async-trait` crate. Though we'd discussed not using an `async-trait`-based approach (#304), there are some immediate needs for these traits for `std` users, namely providing a common `async` API to things like Cloud KMS services and NetHSMs. I think we can still pursue nightly-only versions of these traits in the `signature` crate itself (ones which will work in `no_std` environments). In the meantime, these traits are self-contained within their own, relatively small crate to unblock making some initial progress with things like Cloud KMS abstractions.
FYI, I spiked out an That said, I did it with the caveat that the longer-term goal is to move those traits into the |
Adds an `async-signature` crate with `AsyncSigner` and `AsyncDigestSigner` traits, based on the `async-trait` crate. Though we'd discussed not using an `async-trait`-based approach (#304), there are some immediate needs for these traits for `std` users, namely providing a common `async` API to things like Cloud KMS services and NetHSMs. I think we can still pursue nightly-only versions of these traits in the `signature` crate itself (ones which will work in `no_std` environments). In the meantime, these traits are self-contained within their own, relatively small crate to unblock making some initial progress with things like Cloud KMS abstractions.
Adds an `async-signature` crate with `AsyncSigner` and `AsyncDigestSigner` traits, based on the `async-trait` crate. Though we'd discussed not using an `async-trait`-based approach (#304), there are some immediate needs for these traits for `std` users, namely providing a common `async` API to things like Cloud KMS services and NetHSMs. I think we can still pursue nightly-only versions of these traits in the `signature` crate itself (ones which will work in `no_std` environments). In the meantime, these traits are self-contained within their own, relatively small crate to unblock making some initial progress with things like Cloud KMS abstractions.
Adds an `async-signature` crate with `AsyncSigner` and `AsyncDigestSigner` traits, based on the `async-trait` crate. Though we'd discussed not using an `async-trait`-based approach (#304), there are some immediate needs for these traits for `std` users, namely providing a common `async` API to things like Cloud KMS services and NetHSMs. I think we can still pursue nightly-only versions of these traits in the `signature` crate itself (ones which will work in `no_std` environments). In the meantime, these traits are self-contained within their own, relatively small crate to unblock making some initial progress with things like Cloud KMS abstractions.
Adds an `async-signature` crate with `AsyncSigner` and `AsyncDigestSigner` traits, based on the `async-trait` crate. Though we'd discussed not using an `async-trait`-based approach (#304), there are some immediate needs for these traits for `std` users, namely providing a common `async` API to things like Cloud KMS services and NetHSMs. I think we can still pursue nightly-only versions of these traits in the `signature` crate itself (ones which will work in `no_std` environments). In the meantime, these traits are self-contained within their own, relatively small crate to unblock making some initial progress with things like Cloud KMS abstractions.
Adds an `async-signature` crate with `AsyncSigner` and `AsyncDigestSigner` traits, based on the `async-trait` crate. Though we'd discussed not using an `async-trait`-based approach (#304), there are some immediate needs for these traits for `std` users, namely providing a common `async` API to things like Cloud KMS services and NetHSMs. I think we can still pursue nightly-only versions of these traits in the `signature` crate itself (ones which will work in `no_std` environments). In the meantime, these traits are self-contained within their own, relatively small crate to unblock making some initial progress with things like Cloud KMS abstractions.
I have this use case where I want to construct aead::stream using AES-GCM in Web Crypto (async api) when targetting wasm32. What would currently be the best workaround? |
There's presently no async support for As it seems GATs may soon be stable, I would suggest holding off explorations of how to asyncify those crates until GATs land. I agree there are many uses for async |
Bumps [crypto-bigint](https://github.com/RustCrypto/crypto-bigint) from 0.4.2 to 0.4.3. - [Release notes](https://github.com/RustCrypto/crypto-bigint/releases) - [Changelog](https://github.com/RustCrypto/crypto-bigint/blob/master/CHANGELOG.md) - [Commits](RustCrypto/crypto-bigint@v0.4.2...v0.4.3) --- updated-dependencies: - dependency-name: crypto-bigint dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Hi, Async traits are now available since 1.75. |
Nope, and in fact the What would be helpful now that AFIT is stable is to have some concrete use cases for async traits to drive their design. An example would be embedded We already have those for signatures, in that there are many external signers (e.g. KMS) where |
What a coincidence, or maybe not! :) I'm currently writing an DTLS 1.3 implementation for embedded (Cortex-M mainly) and for accelerating the AES128-GCM and SHA256 I was planning to use the crypto accelerator and the hash accelerator of the MCU. Generally most MCUs that are communication oriented have acceleration for at least the symmetric encryption, but some also has hash accelerators. How could I help give some insight? |
@korken89 perhaps you could open a PR with the traits you'd like to see? |
Additionally, are there any reason the |
@MathiasKoch I think it might be leftover from before AFIT when it was using |
I can indeed have a look at the traits! |
Several crates in this repo could benefit from having
async
equivalents. There are several use cases forasync
, such as communicating with network services which implement a particular cryptographic primitive (Cloud KMS, NetHSM), or things like cryptographic tokens, SmartCards, non-networked HSMs (e.g. PCI cards, USB devices), or embedded cryptographic accelerators.Unfortunately Rust doesn't natively support async traits yet. The most commonly used solution at the moment is @dtolnay's async-trait crate. This provides an ergonomic syntax which should hopefully be easy to transition to hypothetical future natively supported async traits, however at the moment it requires
std
and usesBox
to storeFuture
s. There's some discussion about improving this happening on rust-internals right now.I think it'd be useful to start defining some async traits, even if they presently depend on
std
. Here's a tracking list of crates that could benefit from async traits:aead
: embedded cryptographic acceleratorscipher
: embedded cryptographic acceleratorsasync-signature
: Cloud KMS/NetHSM services and embedded cryptographic acceleratorsOthers? (please leave a note in the comments if you have a use case and I'll update)
The text was updated successfully, but these errors were encountered: