You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was a bit torn on whether to call this a breaking change (i.e. bumping the version to 0.7.0-pre).
It seems like the only breaking case would be treating the types exported from aes as the same as either aesni or aes-soft, which would be breaking if ever AES-NI were/weren't used (depending on what you're expecting).
Given that, I think it's safe to call it backwards compatible. We could potentially release this as v0.6.1, and yank the previous v0.6.0 to prevent any shenanigans.
The reason will be displayed to describe this comment to others. Learn more.
I thought that unification is worth only with added runtime detection. Otherwise AES-NI support will be hard to find for users who do not use the aes crate directly. In other words most users will use the software implementation, while with the current implementation they may notice aes-soft in their build log. I think I've seen projects which use aesni directly to motivate users to enable the aes target feature.
But I guess if we'll add the runtime detection before the next minor cipher version, merging crate now should not be a problem.
I thought that unification is worth only with added runtime detection.
We definitely need it for that. The current target-based gating of aesni vs aes-soft crate dependencies makes adding it impossible.
But also it's unclear how to add things like ARM acceleration (#10), which is especially important given the recent launch of the Apple M1. Would that otherwise go into aesni? But then we need to gate on two different targets, and things get quite complicated. Add yet another crate? I think as we add more hardware accelerated backends, converging on a single crate makes things a lot easier.
it's unclear how to add things like ARM acceleration
AFAIK the ideal solution is blocked on rust-lang/rfcs#2725. Meanwhile we would have to either write platform-specific code to extract available features, continue to rely on RUSTFLAGS, or add a feature for forcing hardware-accelerated implementation (assuming M1 uses the AArch64 crypto extension). Considering that ARM intrinsics are still unstable, I think the latter option will be fine for now.
Think I addressed all of the outstanding comments.
Re: cfg-if-based gating in lib.rs I mentioned earlier, I think I'd like to explore that as part of a separate PR.
An additional remaining question is still whether if this is merged, whether it could be published as v0.6.1, or if we should hold off and do a cipher crate upgrade and/or runtime detection first.
Bumps the `aes` crate version to indicate we'll be making breaking
changes before the next release (i.e. `cipher` crate upgrade).
Also removes the `aesni` and `aes-soft` crates from the README.md table
now that they've been unified into the `aes` crate (#200)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Combines all four crates into a single
aescrate.The optional
ctrfeature exposes a consistent set ofAes*Ctrtypes.cc @peterdettman