universal-hash v0.5 #965
universal-hash v0.5 #965
Conversation
| use subtle::ConstantTimeEq; | ||
| use typenum::Unsigned; | ||
|
|
||
| /// Trait implemented by UHF backends. |
There was a problem hiding this comment.
Document how this trait is intended to be used.
| /// Size of the inputs to and outputs from the universal hash function | ||
| type BlockSize: ArrayLength<u8>; | ||
| pub trait UniversalHash: BlockSizeUser + Sized { | ||
| /// Update hash function state using the provided rank-2 closure. |
There was a problem hiding this comment.
Document how this method is intended to be implemented (calling out to target-specific backends). If you don't want that documentation to live on the trait that end users will be using, then instead add a reference here to UhfBackend and document the implementor notes there.
There was a problem hiding this comment.
This is also where the note about user trait usage should go, for e.g. AEADs (RustCrypto/AEADs#414 (comment)).
|
@newpavlov can you add the docs @str4d requested and get this merged so we can make progress on RustCrypto/universal-hashes#153 ? |
|
I plan to improve the docs, but they do not block the work on RustCrypto/universal-hashes#153 and update of the AEAD crates. Before working on docs I plan to properly review the @str4d's PR first. |
|
Okay, well there's also RustCrypto/AEADs#414 and RustCrypto/AEADs#415, which means we have a lot of PRs that are interdependent on other PRs. And I'd like to start work on updating |
| /// Trait implemented by UHF backends. | ||
| pub trait UhfBackend: ParBlocksSizeUser { | ||
| /// Process single block. | ||
| fn proc_block(&mut self, block: &Block<Self>); |
There was a problem hiding this comment.
Per RustCrypto/universal-hashes#153 (comment), we are currently lacking a way to inform the consumer of the UhfBackend that the backend is "unaligned" and cannot consume ParBlocks efficiently (with impls either panicking, or always falling back to a simple loop over UhfBackend::proc_block which causes an extra copy of each block and I suspect breaks inlining). One way to avoid this would be for the backend to expose the misalignment:
| fn proc_block(&mut self, block: &Block<Self>); | |
| fn proc_block(&mut self, block: &Block<Self>); | |
| /// Returns the number of blocks that should be passed to `Self::proc_block` before | |
| /// `Self::proc_par_blocks` can be used efficiently. This is always less than | |
| /// `Self::ParBlocksSize`. | |
| fn blocks_needed_to_align(&self) -> usize { | |
| 0 | |
| } |
|
In the interest of moving things along and getting additional We can open a general tracking issue for crates which are in need of more documentation. |
tarcieri
added
univeral-hash
|
Looks like this PR needs a rebase to address merge conflicts? Also I'd like feedback on my suggestion above (as currently I don't think the API changes here can ever help ChaCha20Poly1305 performance due to the immediate 1-block misalignment when initializing the AEAD). |
|
@str4d it seems like adding a "flush" API which consumes the internal buffer and returns it to an aligned state could be added to address that problem? Then AEADs could just flush the UHF after inputting the AAD. Regardless, releases of the AEAD crates seem stalled on this PR, and the only way we could experiment with the necessary API changes to address issues like buffer misalignment without merging this is as a series of PRs to AEADs which point to PRs to this branch of Getting this merged (and ideally an associated prerelease cut) means we can more easily make incremental progress towards a final release. |
|
Rebased/squashed this PR and opened a new one: #1051 |
|
Merged in #1051 |
Originally suggested by @str4d here: #965 (comment) The use case is ensuring unbuffered processing of the input AEAD message body when the AAD does not line up with the number of blocks it's processing in parallel. This number of blocks can be input from the start of the message body to finish completely filling the buffer, ensuring all subsequent processing occurs at the start of the buffer.
Originally suggested by @str4d here: #965 (comment) The use case is ensuring unbuffered processing of the input AEAD message body when the AAD does not line up with the number of blocks it's processing in parallel. This number of blocks can be input from the start of the message body to finish completely filling the buffer, ensuring all subsequent processing occurs at the start of the buffer.
The new API uses approach of emulating rank-2 closures previously introduced in cipher v0.4.
Also moves
ParBlocksSizeUserandParBlocksfromciphertocrypto-common.