ShaToHex can treat a 0x00 byte in a hash as a 'end-of-hash' #42
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Telodendria/Cytoplasm#42
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Functions like
Sha256
can generate bytestreams with a 0-byte with them(e.g: the stringzJ9hc5zKoul4d0QPaxW2eTG0E76qvh3hoGow3mrL6bk=
provides the hash 0x7c557e7b00
f0a38e788871f6cd962138dfc51463b1e078cdd6787e745e764b5a, which does have a NULL byte in it.ShaToHex
may then process it as an 'end-of-hash', causing the string to end, generating a rather short7c557e7b
.A solution to that may be to allocate metadata(for the size/generated hash) alongside, then shift out the metadata to return a pointer towards the generated hash, which could be reversed to get back the original metadata too. However, such method wouldn't be
Free
able directly (which may be excepted), and there may be some scenarios where a value passed toShaToHex
may just be from a function that isn'tSha1
/Sha256
(though rare), and that may not produce such behaviour.I'll need to think more about if doing that is desirable, instead of making a specific structure dedicated for storing raw SHA hashes.
That's a very good observation. Wouldn't it be easier if we just pass the length (or type as a constant, like
SHA_SHA1
orSHA_SHA256
as a parameter toShaToHex()
? Something like this:ShaToHex(hash, SHA_SHA256)
ifhash
is a SHA-256.