Skip to content
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

Fix HMAC usage #3

Open
dd86k opened this issue Dec 23, 2021 · 3 comments
Open

Fix HMAC usage #3

dd86k opened this issue Dec 23, 2021 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@dd86k
Copy link
Owner

dd86k commented Dec 23, 2021

While the Digest API uses std.digest.hmac.HMAC for HMAC, which adds a secret hashed key using the template API, the way BLAKE2 does is just... Weird.

At initiation:

  • Parameter block index 0 byte 1 (little-endian) sets key size in bytes.
  • Key is XOR'd with state alongside IV (ulong for b, uint for s, see the inner_t alias).

Which is simply not possible with the HMAC structure template. Unless there's a hack I don't know of.

@dd86k dd86k added the bug Something isn't working label Dec 23, 2021
@dd86k dd86k self-assigned this Dec 23, 2021
@dd86k
Copy link
Owner Author

dd86k commented Dec 31, 2021

I think I could do a void key(scope const(ubyte)[] data...) function that performs a "second stage" initiation.

@dd86k
Copy link
Owner Author

dd86k commented Jan 1, 2022

Got key stuff in but that's not hmac so keeping this open.

@dd86k
Copy link
Owner Author

dd86k commented Aug 13, 2022

For the HMAC templates to work, the key needs to be initiated at compile-time. The issue is, while the default key is the IV, they are of different types in the s (uint) and b (ulong) variants.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant