This is one of the things on my hash library todo list. By simply adding another optional argument of "number of bits in last byte", then do a shift on the padding byte and xor it to the last byte, and change the total bit count. I assume this would be the most simple method of modification of any code to support this where the input is always in bytes.
–
Richie FrameOct 5 '13 at 6:37

@Richie Frame: If I may suggest you, define one argument which is a length in bits. When generating bit strings, I am shifting machine words, not bytes. When finalizing, length is in bits, on previous calls length is in blocks natural for a hashing algorithm. Shifting really is obligation of a caller.
–
beroalOct 5 '13 at 16:08

The argument would be handled internally by the code that performs the hash, it does not care if you are generating individual bits, bytes, or words. If you are generating words then truncating, the number of bits you truncated $t$ is passed as the argument $-t$ $mod$ $8$ to the library. Having the argument be the total bitlength may cause problems where the input and argument vary by more than 7, unless the library performs the final truncation.
–
Richie FrameOct 6 '13 at 8:55

I should not that if the message is not passed to the library as a byte array (such as an array of uInt64) my method would no longer work, the application of my code requires input as a string or byte array, so that would not be a problem, but may be on other platforms where a $char$ is not 8-bits
–
Richie FrameOct 6 '13 at 9:03

1 Answer
1

Such libraries most certainly do exist; see here and here for two examples.

A hash implementation that can handle odd-sized bit strings is called "bit-oriented"; most implementations don't bother with it (just because the requirement just doesn't come up that often), however, a few do.