-
Notifications
You must be signed in to change notification settings - Fork 562
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
Compile-time output length #4065
Comments
I can absolutely understand why you'd want this. But it may not be really possible for us to provide it. Really we couldn't provide it even in the old interface with a named-class-per-algorithm; it works in your example but not for SHA-3, BLAKE, SHAKE, etc since there there is a variable output length which is parameterized at runtime. The best approach I can see that might get you some of the way to what you're looking for would be a hypothetical API that I just made up.
This would actually be pretty nice and avoid a lot of string handling that we're otherwise stuck with during algorithm creation. But, this isn't something that's likely to happen very soon. |
Thanks for the input. I hadn't considered the case of the variable output length functions (I haven't used those). |
Such a thing would also be useful for some internal use cases. We did have some discussion about something similar in the context of asynchronous algorithms. And there's a ticket tracking this todo (for the record): #3706. |
Just wanted to open a discussion about HashFunction's
output_length()
.One feature that would be nice to have would be to a way to get the output length at compile-time rather than relying on runtime asserts. In cases where you don't want to Botan allocating a vector for the result, it's cumbersome and error-prone (been there, done that) to have to do something like:
It'd be nice to be able to just write something akin to:
This would have been trivial to add under the original v1 design but the newer string-based interface rules it out. I saw that there's an open discussion on providing a better interface but that has a much wider scope and as such, it seems unlikely to go anywhere.
I do have some thoughts on possible solutions but the changes required would feel a little disjointed, but at least the scope would be narrow and wouldn't introduce any breaking changes. However, if a new interface was likely to be on the horizon, it'd be better to hold off.
Thanks!
The text was updated successfully, but these errors were encountered: