Conversation
newpavlov
approved these changes
Jun 9, 2020
Member
newpavlov
left a comment
There was a problem hiding this comment.
I am a bit hesitant about ParBlocks. Does it make sense for hardware cryptographic accelerators? IIUC they either work on per-block basis or process the whole message (multiple of block sizes) at once with a given mode (e.g. ECB or CBC).
Member
Author
|
I’d agree: I just did it for feature parity, but these use cases are always |
Adds a stateful equivalent to `BlockCipher` that permits `&mut self` access to the underlying type. The main use case for this trait is hardware cryptographic accelerators which need to e.g. communitate with a peripheral device via an underlying `&mut` reference. While it's possible to use some underlying logic to use the existing `BlockCipher` trait in such a scenario, the solutions are somewhat ugly. Here is a real-world example: https://github.com/iqlusioninc/usbarmory.rs/blob/develop/firmware/usbarmory/src/dcp/aes128.rs#L198-L236 The idea with `BlockCipherMut` would be to alternatively provide `AeadMut`/`AeadMutInPlace` for AEAD modes with an underlying `BlockCipherMut` (when possible).
17eac70 to
680bb66
Compare
Member
Author
|
Updated to remove |
Merged
dns2utf8
pushed a commit
to dns2utf8/traits
that referenced
this pull request
Jan 24, 2023
…ustCrypto#182) Closes RustCrypto#179. This commit makes the `Params` struct always available regardless of enabled crate features, adding on functionality when the `password-hash` feature is enabled. Per the added TODOs in this commit, it really seems like in the next breaking release, `Argon2::new` should accept `Params` as an argument rather than duplicating all of the individual parameter fields and passing them in as arguments. After that, they can be validated and stored within the `Argon2` struct itself. But that would be a breaking change, so for now they're stored piecemeal. Additionally, this commit now ensures enough context is available in the `Argon2` struct in order to implement `hash_password_simple` that uses the configured params rather than the defaults, which addresses the aforementioned issue.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Adds a stateful equivalent to
BlockCipherthat permits&mut selfaccess to the underlying type.The main use case for this trait is hardware cryptographic accelerators which need to e.g. communitate with a peripheral device via an underlying
&mutreference.While it's possible to use some underlying logic to use the existing
BlockCiphertrait in such a scenario, the solutions are somewhat ugly. Here is a real-world example:https://github.com/iqlusioninc/usbarmory.rs/blob/develop/firmware/usbarmory/src/dcp/aes128.rs#L198-L236
The idea with
BlockCipherMutwould be to alternatively provideAeadMut/AeadMutInPlacefor AEAD modes with an underlyingBlockCipherMut(when possible).