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
A priori, hasher code like this should really run without an alloc or std dependency, so in particular Vec should not be used anywhere. It may be unavoidable if the standard is bad of course, but things like an XoF mode clearly never need Vec. There is also a lot of redundant hashing.
An expander trait could look like this for example:
A priori, hasher code like this should really run without an alloc or std dependency, so in particular
Vec
should not be used anywhere. It may be unavoidable if the standard is bad of course, but things like an XoF mode clearly never need Vec. There is also a lot of redundant hashing.An expander trait could look like this for example:
As this trait is internal,
construct_dst_prime
should really be some setup method, thus avoiding theAtomicRefCell
, so maybe:Also,
MAX_DST_LENGTH = 256
is enforced by the "I2OSP(len(DST), 1)" in the standard, but where does this DST shortening logic? I'm only seeing "ABORT .. if len(DST) > 256" in https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/16/The text was updated successfully, but these errors were encountered: