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
An attempt to define CTR mode generically. The approach is quite flexible and I think it can be even used with the __m128i type (i.e. we will be able to reduce amount of copied code in the aes crate).
But I get a weird compilation error when I try to define implementations of generate_block and load methods. Even though the default implementation works without problems, when I copy it to the concrete type (Ctr128BE) impl, I get an error which asks me to further restrict N with Div<U16> bound, even though it's already restricted by Div<Self::Size>. Even copying the suggested bound does not resolve the issue, compiler suggests to add already existing bound. Looks like a bug in the compiler to me.
UPD: The implementation got restricted back to 128-bit ciphers, probably until landing of const generics.
The reason will be displayed to describe this comment to others. Learn more.
If it's block position, then it can be simply computed by dividing byte position by block size. Though we probably can extend the seek trait with a method which would return this number right away. I also thought about exposing the block nature of stream ciphers, but I haven't found a good AP for it which would fit different backends and runtime detection for ChaCha.
I am not sure how to work around the compiler error issue. Making the CtrFlavor trait generic over block size instead of the method results in a similar error. I guess we can continue to support only 128-bit ciphers and wait for const generics to land, which it looks like do not have this 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
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.
An attempt to define CTR mode generically. The approach is quite flexible and I think it can be even used with the
__m128itype (i.e. we will be able to reduce amount of copied code in theaescrate).But I get a weird compilation error when I try to define implementations of
generate_blockandloadmethods. Even though the default implementation works without problems, when I copy it to the concrete type (Ctr128BE) impl, I get an error which asks me to further restrictNwithDiv<U16>bound, even though it's already restricted byDiv<Self::Size>. Even copying the suggested bound does not resolve the issue, compiler suggests to add already existing bound. Looks like a bug in the compiler to me.UPD: The implementation got restricted back to 128-bit ciphers, probably until landing of const generics.