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

const fn hashing #288

Open
rubdos opened this issue Jul 14, 2021 · 4 comments
Open

const fn hashing #288

rubdos opened this issue Jul 14, 2021 · 4 comments

Comments

@rubdos
Copy link

rubdos commented Jul 14, 2021

Hi!

I'm using Shake256 in a setting where all input data is known at compile-time, a case where the hash value could be computed at compile-time too.

I've been using tiny-keccak before (I'm not sure why anymore, exactly), and I started toying with it to support const fn hashing. I've bounced on some hurdles, which is why I made that issue.

This week I realized I could probably start the same discussion here: how painful would const fn-hashing be to implement? I feel like it would probably not work due to the Digest family of traits (trait fns cannot be const afaik), but I'd nevertheless would want to discuss!

Best regards,

Ruben

@newpavlov
Copy link
Member

It will depend on progress of impl const, which, unfortunately, does not even has an accepted RFC. In theory we may add inherent const methods, but I would prefer not to go this direction. Also before constifying implementations I would prefer to have const_eval_select. Without it we would be unable to add intrinsics or assembly based implementations without breaking backward compatibility.

As a stopgap solution I would use build scripts to compute hashes over data. Maybe procedural macros could work as well?

@rubdos
Copy link
Author

rubdos commented Jul 14, 2021

It will depend on progress of impl const, which, unfortunately, does not even has an accepted RFC. In theory we may add inherent const methods, but I would prefer not to go this direction. Also before constifying implementations I would prefer to have const_eval_select. Without it we would be unable to add intrinsics or assembly based implementations without breaking backward compatibility.

Thanks for documenting what needs to be in place!

As a stopgap solution I would use build scripts to compute hashes over data. Maybe procedural macros could work as well?

I already have a build script in place, so it might make sense to do it in a build script indeed. It's generated code. It would be a bit cleaner without it though.

What do you say, leave this issue open for now? I might get my hands dirty and make a tiny-keccak fork (say, const-keccak) to have a base implementation without any traits.

@tarcieri
Copy link
Member

There are already a few const fn implementations of hash functions, FWIW:

@rubdos
Copy link
Author

rubdos commented Jul 14, 2021

I was tempted to use sha2-const, but I'm kind-of in love with Keccak and sponges... :'-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants